2.6.23-rc3-mm1
Subsystems (21)
PATCH 1/2 sysctl: Properly register the irda binary sysctl numbers.
In reply to Andrew MortonGrumble. These numbers should have been in sysctl.h from the beginning if we ever expected anyone to use them. Oh well put them there now so we can find them and make maintenance easier.
--- include/linux/sysctl.h | 20 ++++++++++++++++++++ net/irda/irsysctl.c | 34 ++++++++++++++-------------------- 2 files changed, 34 insertions(+), 20 deletions(-)
include/linux/sysctl.h +20 -0
@@ -238,6 +238,7 @@ enumNET_LLC =18 ,NET_NETFILTER =19 ,NET_DCCP =20 , + NET_IRDA=412, };/* /proc/sys/kernel/random */
@@ -795,6 +796,25 @@ enum { NET_BRIDGE_NF_FILTER_PPPOE_TAGGED = 5, }; +/* proc/sys/net/irda */ +enum { +NET_IRDA_DISCOVERY =1 , +NET_IRDA_DEVNAME =2 , +NET_IRDA_DEBUG =3 , +NET_IRDA_FAST_POLL =4 , +NET_IRDA_DISCOVERY_SLOTS =5 , +NET_IRDA_DISCOVERY_TIMEOUT =6 , +NET_IRDA_SLOT_TIMEOUT =7 , +NET_IRDA_MAX_BAUD_RATE =8 , +NET_IRDA_MIN_TX_TURN_TIME =9 , +NET_IRDA_MAX_TX_DATA_SIZE =10 , +NET_IRDA_MAX_TX_WINDOW =11 , +NET_IRDA_MAX_NOREPLY_TIME =12 , +NET_IRDA_WARN_NOREPLY_TIME =13 , +NET_IRDA_LAP_KEEPALIVE_TIME =14 , +}; + +/* CTL_FS names: */ enum {
net/irda/irsysctl.c +14 -20
@@ -31,12 +31,6 @@#include <net/irda/irda.h> /* irda_debug */ #include <net/irda/irias_object.h> -#define NET_IRDA 412/* Random number */ -enum {DISCOVERY =1 ,DEVNAME ,DEBUG ,FAST_POLL ,DISCOVERY_SLOTS , -DISCOVERY_TIMEOUT ,SLOT_TIMEOUT ,MAX_BAUD_RATE ,MIN_TX_TURN_TIME , -MAX_TX_DATA_SIZE ,MAX_TX_WINDOW ,MAX_NOREPLY_TIME ,WARN_NOREPLY_TIME , -LAP_KEEPALIVE_TIME }; -extern int sysctl_discovery;extern int sysctl_discovery_slots;extern int sysctl_discovery_timeout;
@@ -94,7 +88,7 @@ static int do_devname(ctl_table *table, int write, struct file *filp,/* One file */ static ctl_table irda_table[] = { { - .ctl_name =DISCOVERY , + .ctl_name =NET_IRDA_DISCOVERY , .procname ="discovery" , .data = &sysctl_discovery, .maxlen =sizeof (int ),
@@ -102,7 +96,7 @@ static ctl_table irda_table[] = { .proc_handler = &proc_dointvec }, { - .ctl_name = DEVNAME, + .ctl_name = NET_IRDA_DEVNAME, .procname = "devname", .data = sysctl_devname, .maxlen = 65,
@@ -112,7 +106,7 @@ static ctl_table irda_table[] = { },#ifdef CONFIG_IRDA_DEBUG { - .ctl_name = DEBUG, + .ctl_name = NET_IRDA_DEBUG, .procname = "debug", .data = &irda_debug, .maxlen = sizeof(int),
@@ -122,7 +116,7 @@ static ctl_table irda_table[] = {#endif #ifdef CONFIG_IRDA_FAST_RR { - .ctl_name = FAST_POLL, + .ctl_name = NET_IRDA_FAST_POLL, .procname = "fast_poll_increase", .data = &sysctl_fast_poll_increase, .maxlen = sizeof(int),
@@ -131,7 +125,7 @@ static ctl_table irda_table[] = { },#endif { - .ctl_name = DISCOVERY_SLOTS, + .ctl_name = NET_IRDA_DISCOVERY_SLOTS, .procname = "discovery_slots", .data = &sysctl_discovery_slots, .maxlen = sizeof(int),
@@ -142,7 +136,7 @@ static ctl_table irda_table[] = { .extra2 = &max_discovery_slots }, { - .ctl_name = DISCOVERY_TIMEOUT, + .ctl_name = NET_IRDA_DISCOVERY_TIMEOUT, .procname = "discovery_timeout", .data = &sysctl_discovery_timeout, .maxlen = sizeof(int),
@@ -150,7 +144,7 @@ static ctl_table irda_table[] = { .proc_handler = &proc_dointvec }, { - .ctl_name = SLOT_TIMEOUT, + .ctl_name = NET_IRDA_SLOT_TIMEOUT, .procname = "slot_timeout", .data = &sysctl_slot_timeout, .maxlen = sizeof(int),
@@ -161,7 +155,7 @@ static ctl_table irda_table[] = { .extra2 = &max_slot_timeout }, { - .ctl_name = MAX_BAUD_RATE, + .ctl_name = NET_IRDA_MAX_BAUD_RATE, .procname = "max_baud_rate", .data = &sysctl_max_baud_rate, .maxlen = sizeof(int),
@@ -172,7 +166,7 @@ static ctl_table irda_table[] = { .extra2 = &max_max_baud_rate }, { - .ctl_name = MIN_TX_TURN_TIME, + .ctl_name = NET_IRDA_MIN_TX_TURN_TIME, .procname = "min_tx_turn_time", .data = &sysctl_min_tx_turn_time, .maxlen = sizeof(int),
@@ -183,7 +177,7 @@ static ctl_table irda_table[] = { .extra2 = &max_min_tx_turn_time }, { - .ctl_name = MAX_TX_DATA_SIZE, + .ctl_name = NET_IRDA_MAX_TX_DATA_SIZE, .procname = "max_tx_data_size", .data = &sysctl_max_tx_data_size, .maxlen = sizeof(int),
@@ -194,7 +188,7 @@ static ctl_table irda_table[] = { .extra2 = &max_max_tx_data_size }, { - .ctl_name = MAX_TX_WINDOW, + .ctl_name = NET_IRDA_MAX_TX_WINDOW, .procname = "max_tx_window", .data = &sysctl_max_tx_window, .maxlen = sizeof(int),
@@ -205,7 +199,7 @@ static ctl_table irda_table[] = { .extra2 = &max_max_tx_window }, { - .ctl_name = MAX_NOREPLY_TIME, + .ctl_name = NET_IRDA_MAX_NOREPLY_TIME, .procname = "max_noreply_time", .data = &sysctl_max_noreply_time, .maxlen = sizeof(int),
@@ -216,7 +210,7 @@ static ctl_table irda_table[] = { .extra2 = &max_max_noreply_time }, { - .ctl_name = WARN_NOREPLY_TIME, + .ctl_name = NET_IRDA_WARN_NOREPLY_TIME, .procname = "warn_noreply_time", .data = &sysctl_warn_noreply_time, .maxlen = sizeof(int),
@@ -227,7 +221,7 @@ static ctl_table irda_table[] = { .extra2 = &max_warn_noreply_time }, { - .ctl_name = LAP_KEEPALIVE_TIME, + .ctl_name = NET_IRDA_LAP_KEEPALIVE_TIME, .procname = "lap_keepalive_time", .data = &sysctl_lap_keepalive_time, .maxlen = sizeof(int),
Signature · 1 line
1.5.1.1.181.g2de0
PATCH 2/2 sysctl: For irda update sysctl_checks list of binary paths.
It turns out that the net/irda code didn't register any of it's binary paths in the global sysctl.h header file so I missed them completely when making an authoritative list of binary sysctl paths in the kernel. So add them to the list of valid binary sysctl paths.
--- kernel/sysctl_check.c | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-)
kernel/sysctl_check.c +19 -0
@@ -702,6 +702,24 @@ static struct trans_ctl_table trans_net_dccp_table[] = { {} }; +static struct trans_ctl_table trans_net_irda_table[] = { + {NET_IRDA_DISCOVERY ,"discovery" }, + {NET_IRDA_DEVNAME ,"devname" }, + {NET_IRDA_DEBUG ,"debug" }, + {NET_IRDA_FAST_POLL ,"fast_poll_increase" }, + {NET_IRDA_DISCOVERY_SLOTS ,"discovery_slots" }, + {NET_IRDA_DISCOVERY_TIMEOUT ,"discovery_timeout" }, + {NET_IRDA_SLOT_TIMEOUT ,"slot_timeout" }, + {NET_IRDA_MAX_BAUD_RATE ,"max_baud_rate" }, + {NET_IRDA_MIN_TX_TURN_TIME ,"min_tx_turn_time" }, + {NET_IRDA_MAX_TX_DATA_SIZE ,"max_tx_data_size" }, + {NET_IRDA_MAX_TX_WINDOW ,"max_tx_window" }, + {NET_IRDA_MAX_NOREPLY_TIME ,"max_noreply_time" }, + {NET_IRDA_WARN_NOREPLY_TIME ,"warn_noreply_time" }, + {NET_IRDA_LAP_KEEPALIVE_TIME ,"lap_keepalive_time" }, + {} +}; +static struct trans_ctl_table trans_net_table[] = { {NET_CORE ,"core" , trans_net_core_table },/* NET_ETHER not used */
@@ -723,6 +741,7 @@ static struct trans_ctl_table trans_net_table[] = { { NET_LLC, "llc", trans_net_llc_table }, { NET_NETFILTER, "netfilter", trans_net_netfilter_table }, { NET_DCCP, "dccp", trans_net_dccp_table }, + { NET_IRDA, "irda", trans_net_irda_table }, { 2089, "nf_conntrack_max" }, {} };
Signature · 1 line
1.5.1.1.181.g2de0
Re: [PATCH 2/2] sysctl: For irda update sysctl_checks list of binary paths.
Quoted 8 lines · Eric W. Biederman
It turns out that the net/irda code didn't register any of it's binary paths in the global
sysctl.hheader file so I missed them completely when making an authoritative list of binary sysctl paths in the kernel. So add them to the list of valid binary sysctl paths.Signed-off-by Eric W. Biederman <[email protected]>
Quoted 44 lines
--- kernel/sysctl_check.c | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-)kernel/sysctl_check.c +19
-0@@ -702,6 +702,24 @@ static struct trans_ctl_table trans_net_dccp_table[] = { {} }; +static struct trans_ctl_table trans_net_irda_table[] = { + {NET_IRDA_DISCOVERY ,"discovery" }, + {NET_IRDA_DEVNAME ,"devname" }, + {NET_IRDA_DEBUG ,"debug" }, + {NET_IRDA_FAST_POLL ,"fast_poll_increase" }, + {NET_IRDA_DISCOVERY_SLOTS ,"discovery_slots" }, + {NET_IRDA_DISCOVERY_TIMEOUT ,"discovery_timeout" }, + {NET_IRDA_SLOT_TIMEOUT ,"slot_timeout" }, + {NET_IRDA_MAX_BAUD_RATE ,"max_baud_rate" }, + {NET_IRDA_MIN_TX_TURN_TIME ,"min_tx_turn_time" }, + {NET_IRDA_MAX_TX_DATA_SIZE ,"max_tx_data_size" }, + {NET_IRDA_MAX_TX_WINDOW ,"max_tx_window" }, + {NET_IRDA_MAX_NOREPLY_TIME ,"max_noreply_time" }, + {NET_IRDA_WARN_NOREPLY_TIME ,"warn_noreply_time" }, + {NET_IRDA_LAP_KEEPALIVE_TIME ,"lap_keepalive_time" }, + {} +}; +static struct trans_ctl_table trans_net_table[] = { {NET_CORE ,"core" , trans_net_core_table },/* NET_ETHER not used */ @@ -723,6 +741,7 @@ static struct trans_ctl_table trans_net_table[] = { { NET_LLC, "llc", trans_net_llc_table }, { NET_NETFILTER, "netfilter", trans_net_netfilter_table }, { NET_DCCP, "dccp", trans_net_dccp_table }, + { NET_IRDA, "irda", trans_net_irda_table }, { 2089, "nf_conntrack_max" }, {} };Signature · 1 line
1.5.1.1.181.g2de0
Re: [PATCH 1/2] sysctl: Properly register the irda binary sysctl numbers.
In reply to Eric W. BiedermanQuoted 6 lines · Eric W. Biederman
Grumble. These numbers should have been in
sysctl.hfrom the beginning if we ever expected anyone to use them. Oh well put them there now so we can find them and make maintenance easier.Signed-off-by Eric W. Biederman <[email protected]>
Applied both patches, and now all I get from irda at boot time now is this:
[ 292.062000] irda_init() [ 292.063000] NET: Registered protocol family 23 [ 292.069000] IrCOMM protocol (Dag Brattli) [ 292.221000] PPP generic driver version 2.4.2
in other words, business as usual. Thanks.
Feel free to stick this on both patches:
Re: [PATCH 1/2] sysctl: Properly register the irda binary sysctl numbers.
Quoted 15 lines · [email protected] writes:
Quoted 6 lines · Eric W. Biederman
Grumble. These numbers should have been in
sysctl.hfrom the beginning if we ever expected anyone to use them. Oh well put them there now so we can find them and make maintenance easier.Signed-off-by Eric W. Biederman <[email protected]>Applied both patches, and now all I get from irda at boot time now is this:
[ 292.062000] irda_init() [ 292.063000] NET: Registered protocol family 23 [ 292.069000] IrCOMM protocol (Dag Brattli) [ 292.221000] PPP generic driver version 2.4.2
Quoted 5 lines
in other words, business as usual. Thanks.
Feel free to stick this on both patches:
Tested-by Valdis Kletnieks <[email protected]>
Thanks.
It's good to have confirmation that my sysctl_check routine didn't find something else wrong.
Eric
Re: [PATCH 1/2] sysctl: Properly register the irda binary sysctl numbers.
Quoted 2 lines · Eric W. Biederman
It's good to have confirmation that my
sysctl_checkroutine didn't find something else wrong.
If I understand the code, anything it whinges about is either an outright bug or it's a round of ammo already chambered. ;)
As far as "something else wrong", I'm still seeing these in -rc3-mm1, but they've been reported before against -rc2-mm2, I think:
[ 0.628000] sysctl table check failed: /kernel/ostype .1.1 Missing strategy [ 0.628000] sysctl table check failed: /kernel/osrelease .1.2 Missing strategy [ 0.628000] sysctl table check failed: /kernel/version .1.4 Missing strategy [ 0.628000] sysctl table check failed: /kernel/hostname .1.7 Missing strategy [ 0.628000] sysctl table check failed: /kernel/domainname .1.8 Missing strategy [ 0.628000] sysctl table check failed: /kernel/shmmax .1.34 Missing strategy [ 0.628000] sysctl table check failed: /kernel/shmall .1.41 Missing strategy [ 0.628000] sysctl table check failed: /kernel/shmmni .1.45 Missing strategy [ 0.628000] sysctl table check failed: /kernel/msgmax .1.35 Missing strategy [ 0.628000] sysctl table check failed: /kernel/msgmni .1.42 Missing strategy [ 0.628000] sysctl table check failed: /kernel/msgmnb .1.36 Missing strategy [ 0.628000] sysctl table check failed: /kernel/sem .1.43 Missing strategy
And this isn't on an allyesconfig or allmodconfig. There may well be sysctl code I didn't hit - my /lib/modules/2.6.23-rc3-mm1 is only about 10M, and the Fedora kernels are weighing in at about 75M of /lib/modules a pop.
Re: [PATCH 1/2] sysctl: Properly register the irda binary sysctl numbers.
Quoted 7 lines · [email protected] writes:
Quoted 2 lines · Eric W. Biederman
It's good to have confirmation that my
sysctl_checkroutine didn't find something else wrong.If I understand the code, anything it whinges about is either an outright bug or it's a round of ammo already chambered. ;)
Pretty much. The heuristics aren't prefect but they are pretty good.
Quoted 2 lines
As far as "something else wrong", I'm still seeing these in -rc3-mm1, but they've been reported before against -rc2-mm2, I think:
Interesting. No I haven't seen this one. This appears to be one of those silly little corner cases I failed to account for in my checks. It looks like you don't have CONFIG_SYSCTL_SYSCALL defined, and it appears utsname_syscall and ipcdata_syscall both become NULL pointers if they aren't needed. So the complaint is a false positive.
Quoted 13 lines
[ 0.628000] sysctl table check failed: /kernel/ostype .1.1 Missing strategy [ 0.628000] sysctl table check failed: /kernel/osrelease .1.2 Missing strategy [ 0.628000] sysctl table check failed: /kernel/version .1.4 Missing strategy [ 0.628000] sysctl table check failed: /kernel/hostname .1.7 Missing strategy [ 0.628000] sysctl table check failed: /kernel/domainname .1.8 Missing strategy [ 0.628000] sysctl table check failed: /kernel/shmmax .1.34 Missing strategy [ 0.628000] sysctl table check failed: /kernel/shmall .1.41 Missing strategy [ 0.628000] sysctl table check failed: /kernel/shmmni .1.45 Missing strategy [ 0.628000] sysctl table check failed: /kernel/msgmax .1.35 Missing strategy [ 0.628000] sysctl table check failed: /kernel/msgmni .1.42 Missing strategy [ 0.628000] sysctl table check failed: /kernel/msgmnb .1.36 Missing strategy [ 0.628000] sysctl table check failed: /kernel/sem .1.43 Missing strategy
Quoted 4 lines
And this isn't on an allyesconfig or allmodconfig. There may well be sysctl code I didn't hit - my
/lib/modules/2.6.23-rc3-mm1is only about 10M, and the Fedora kernels are weighing in at about 75M of/lib/modulesa pop.
Yes. Thank you. I figure as long as we are reasonably close people we should catch most if not all things before this is merged into Linus's tree.
Patch in a moment.
Eric
Re: [PATCH 1/2] sysctl: Properly register the irda binary sysctl numbers.
Quoted 3 lines · Eric W. Biederman
It looks like you don't have
CONFIG_SYSCTL_SYSCALLdefined, and it appearsutsname_syscallandipcdata_syscallboth become NULL pointers if they aren't needed. So the complaint is a false positive.
Yep. Nothing I actually use needs SYSCTL_SYSCALL, so I turned it off to see what breaks...
Re: [PATCH 1/2] sysctl: Properly register the irda binary sysctl numbers.
Quoted 8 lines · [email protected] writes:
Quoted 3 lines · Eric W. Biederman
It looks like you don't have
CONFIG_SYSCTL_SYSCALLdefined, and it appearsutsname_syscallandipcdata_syscallboth become NULL pointers if they aren't needed. So the complaint is a false positive.Yep. Nothing I actually use needs
SYSCTL_SYSCALL, so I turned it off to see what breaks...
Other then glibc (which uses it to see if we are on a SMP system, and has a fallback to /proc/sys) I only found 5 other applications binaries when I was looking hard.
Eric
PATCH 1/1 sysctl: Update sysctl_check to handle compiled out code.
In reply to [email protected]Currently sysctl_check_table will complain if a strategy routine is missing when we have sys_sysctl compiled out, or a proc_handler is missing when we have procfs compiled out. At least some of the custom handlers actually expand to NULL when this is the case so the warning is actually a problem.
Quoted 14 lines · [email protected] writes:
As far as "something else wrong", I'm still seeing these in -rc3-mm1
[ 0.628000] sysctl table check failed: /kernel/ostype .1.1 Missing strategy [ 0.628000] sysctl table check failed: /kernel/osrelease .1.2 Missing strategy [ 0.628000] sysctl table check failed: /kernel/version .1.4 Missing strategy [ 0.628000] sysctl table check failed: /kernel/hostname .1.7 Missing strategy [ 0.628000] sysctl table check failed: /kernel/domainname .1.8 Missing strategy [ 0.628000] sysctl table check failed: /kernel/shmmax .1.34 Missing strategy [ 0.628000] sysctl table check failed: /kernel/shmall .1.41 Missing strategy [ 0.628000] sysctl table check failed: /kernel/shmmni .1.45 Missing strategy [ 0.628000] sysctl table check failed: /kernel/msgmax .1.35 Missing strategy [ 0.628000] sysctl table check failed: /kernel/msgmni .1.42 Missing strategy [ 0.628000] sysctl table check failed: /kernel/msgmnb .1.36 Missing strategy [ 0.628000] sysctl table check failed: /kernel/sem .1.43 Missing strategy
So don't worry about missing strategy routines, or missing proc_handler routines when they will never be called.
--- kernel/sysctl_check.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)
kernel/sysctl_check.c +4 -0
@@ -1552,14 +1552,18 @@ int sysctl_check_table(struct ctl_table *table)set_fail (&fail, table,"No max" ); } } +#ifdef CONFIG_SYSCTL_SYSCALL if (table->ctl_name && !table->strategy)set_fail (&fail, table,"Missing strategy" ); +#endif #if 0 if (!table->ctl_name && table->strategy)set_fail (&fail, table,"Strategy without ctl_name" );#endif +#ifdef CONFIG_PROC_FS if (table->procname && !table->proc_handler)set_fail (&fail, table,"No proc_handler" ); +#endif #if 0 if (!table->procname && table->proc_handler)set_fail (&fail, table,"proc_handler without procname" );
Signature · 1 line
1.5.3.rc6.17.g1911
Re: [PATCH] sysctl: Update sysctl_check to handle compiled out code.
Quoted 4 lines · Eric W. Biederman
So don't worry about missing strategy routines, or missing
proc_handlerroutines when they will never be called.Signed-off-by Eric W. Biederman <[email protected]>
I'm not seeing the false-positive msgs after applying this patch...
Re: [PATCH 1/2] sysctl: Properly register the irda binary sysctl numbers.
In reply to Eric W. BiedermanHi Eric,
Quoted 4 lines · Eric W. Biederman
Grumble. These numbers should have been in
sysctl.hfrom the beginning if we ever expected anyone to use them. Oh well put them there now so we can find them and make maintenance easier.
Thanks for that, I should have taken care of it earlier...
Quoted 1 line
Signed-off-by Eric W. Biederman <[email protected]>
Quoted 189 lines
--- include/linux/sysctl.h | 20 ++++++++++++++++++++ net/irda/irsysctl.c | 34 ++++++++++++++-------------------- 2 files changed, 34 insertions(+), 20 deletions(-)include/linux/sysctl.h +20
-0@@ -238,6 +238,7 @@ enumNET_LLC =18 ,NET_NETFILTER =19 ,NET_DCCP =20 , + NET_IRDA=412, };/* /proc/sys/kernel/random */ @@ -795,6 +796,25 @@ enum { NET_BRIDGE_NF_FILTER_PPPOE_TAGGED = 5, }; +/* proc/sys/net/irda */ +enum { +NET_IRDA_DISCOVERY =1 , +NET_IRDA_DEVNAME =2 , +NET_IRDA_DEBUG =3 , +NET_IRDA_FAST_POLL =4 , +NET_IRDA_DISCOVERY_SLOTS =5 , +NET_IRDA_DISCOVERY_TIMEOUT =6 , +NET_IRDA_SLOT_TIMEOUT =7 , +NET_IRDA_MAX_BAUD_RATE =8 , +NET_IRDA_MIN_TX_TURN_TIME =9 , +NET_IRDA_MAX_TX_DATA_SIZE =10 , +NET_IRDA_MAX_TX_WINDOW =11 , +NET_IRDA_MAX_NOREPLY_TIME =12 , +NET_IRDA_WARN_NOREPLY_TIME =13 , +NET_IRDA_LAP_KEEPALIVE_TIME =14 , +}; + +/* CTL_FS names: */ enum {net/irda/irsysctl.c +14
-20@@ -31,12 +31,6 @@#include <net/irda/irda.h> /* irda_debug */ #include <net/irda/irias_object.h> -#define NET_IRDA 412/* Random number */ -enum {DISCOVERY =1 ,DEVNAME ,DEBUG ,FAST_POLL ,DISCOVERY_SLOTS , -DISCOVERY_TIMEOUT ,SLOT_TIMEOUT ,MAX_BAUD_RATE ,MIN_TX_TURN_TIME , -MAX_TX_DATA_SIZE ,MAX_TX_WINDOW ,MAX_NOREPLY_TIME ,WARN_NOREPLY_TIME , -LAP_KEEPALIVE_TIME }; -extern int sysctl_discovery;extern int sysctl_discovery_slots;extern int sysctl_discovery_timeout;@@ -94,7 +88,7 @@ static int do_devname(ctl_table *table, int write, struct file *filp,/* One file */ static ctl_table irda_table[] = { { - .ctl_name =DISCOVERY , + .ctl_name =NET_IRDA_DISCOVERY , .procname ="discovery" , .data = &sysctl_discovery, .maxlen =sizeof (int ),@@ -102,7 +96,7 @@ static ctl_table irda_table[] = { .proc_handler = &proc_dointvec }, { - .ctl_name = DEVNAME, + .ctl_name = NET_IRDA_DEVNAME, .procname = "devname", .data = sysctl_devname, .maxlen = 65,@@ -112,7 +106,7 @@ static ctl_table irda_table[] = { },#ifdef CONFIG_IRDA_DEBUG { - .ctl_name = DEBUG, + .ctl_name = NET_IRDA_DEBUG, .procname = "debug", .data = &irda_debug, .maxlen = sizeof(int),@@ -122,7 +116,7 @@ static ctl_table irda_table[] = {#endif #ifdef CONFIG_IRDA_FAST_RR { - .ctl_name = FAST_POLL, + .ctl_name = NET_IRDA_FAST_POLL, .procname = "fast_poll_increase", .data = &sysctl_fast_poll_increase, .maxlen = sizeof(int),@@ -131,7 +125,7 @@ static ctl_table irda_table[] = { },#endif { - .ctl_name = DISCOVERY_SLOTS, + .ctl_name = NET_IRDA_DISCOVERY_SLOTS, .procname = "discovery_slots", .data = &sysctl_discovery_slots, .maxlen = sizeof(int),@@ -142,7 +136,7 @@ static ctl_table irda_table[] = { .extra2 = &max_discovery_slots }, { - .ctl_name = DISCOVERY_TIMEOUT, + .ctl_name = NET_IRDA_DISCOVERY_TIMEOUT, .procname = "discovery_timeout", .data = &sysctl_discovery_timeout, .maxlen = sizeof(int),@@ -150,7 +144,7 @@ static ctl_table irda_table[] = { .proc_handler = &proc_dointvec }, { - .ctl_name = SLOT_TIMEOUT, + .ctl_name = NET_IRDA_SLOT_TIMEOUT, .procname = "slot_timeout", .data = &sysctl_slot_timeout, .maxlen = sizeof(int),@@ -161,7 +155,7 @@ static ctl_table irda_table[] = { .extra2 = &max_slot_timeout }, { - .ctl_name = MAX_BAUD_RATE, + .ctl_name = NET_IRDA_MAX_BAUD_RATE, .procname = "max_baud_rate", .data = &sysctl_max_baud_rate, .maxlen = sizeof(int),@@ -172,7 +166,7 @@ static ctl_table irda_table[] = { .extra2 = &max_max_baud_rate }, { - .ctl_name = MIN_TX_TURN_TIME, + .ctl_name = NET_IRDA_MIN_TX_TURN_TIME, .procname = "min_tx_turn_time", .data = &sysctl_min_tx_turn_time, .maxlen = sizeof(int),@@ -183,7 +177,7 @@ static ctl_table irda_table[] = { .extra2 = &max_min_tx_turn_time }, { - .ctl_name = MAX_TX_DATA_SIZE, + .ctl_name = NET_IRDA_MAX_TX_DATA_SIZE, .procname = "max_tx_data_size", .data = &sysctl_max_tx_data_size, .maxlen = sizeof(int),@@ -194,7 +188,7 @@ static ctl_table irda_table[] = { .extra2 = &max_max_tx_data_size }, { - .ctl_name = MAX_TX_WINDOW, + .ctl_name = NET_IRDA_MAX_TX_WINDOW, .procname = "max_tx_window", .data = &sysctl_max_tx_window, .maxlen = sizeof(int),@@ -205,7 +199,7 @@ static ctl_table irda_table[] = { .extra2 = &max_max_tx_window }, { - .ctl_name = MAX_NOREPLY_TIME, + .ctl_name = NET_IRDA_MAX_NOREPLY_TIME, .procname = "max_noreply_time", .data = &sysctl_max_noreply_time, .maxlen = sizeof(int),@@ -216,7 +210,7 @@ static ctl_table irda_table[] = { .extra2 = &max_max_noreply_time }, { - .ctl_name = WARN_NOREPLY_TIME, + .ctl_name = NET_IRDA_WARN_NOREPLY_TIME, .procname = "warn_noreply_time", .data = &sysctl_warn_noreply_time, .maxlen = sizeof(int),@@ -227,7 +221,7 @@ static ctl_table irda_table[] = { .extra2 = &max_warn_noreply_time }, { - .ctl_name = LAP_KEEPALIVE_TIME, + .ctl_name = NET_IRDA_LAP_KEEPALIVE_TIME, .procname = "lap_keepalive_time", .data = &sysctl_lap_keepalive_time, .maxlen = sizeof(int),Signature · 1 line
1.5.1.1.181.g2de0
Am 22.08.2007 11:06 schrieb Andrew Morton:
Quoted 1 line
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
After applying Matthew Wilcox' patch to include/linux/isa.h this compiles and boots on my Intel/openSUSE 10.2 test machine but throws out the following messages I don't remember ever seeing with other kernels:
- on console early during boot, also in SuSE's /var/log/boot.msg:
your system time is not correct:
Wed Jul 13 13:15:31 UTC 1910
setting system time to:
Tue Jul 24 00:00:00 UTC 2007
- later, dto. on console and in /var/log/boot.msg:
FATAL: Error inserting processor (/lib/modules/2.6.23-rc3-mm1-testing/kernel/drivers/acpi/processor.ko): Input/output error
WARNING: Error inserting processor (/lib/modules/2.6.23-rc3-mm1-testing/kernel/drivers/acpi/processor.ko): Input/output error
FATAL: Error inserting thermal (/lib/modules/2.6.23-rc3-mm1-testing/kernel/drivers/acpi/thermal.ko): Unknown symbol in module, or unknown parameter (see dmesg)
- apparently corresponding to that, in dmesg:
<4>[ 7.691865] thermal: Unknown symbol acpi_processor_set_thermal_limit
- from fsck during boot:
/dev/system/root: Superblock last mount time is in the future. FIXED. /dev/system/root: Superblock last write time is in the future. FIXED.
- in /var/log/warn:
Aug 25 00:44:00 xenon powersaved[5356]: WARNING (CpufreqManagement:51) No capability cpufreq_control Aug 25 00:44:00 xenon powersaved[5356]: WARNING (CpufreqManagement:51) No capability cpufreq_control
And the SUSE startup sequence displays "failed" for the acpid daemon. So it seems there is some strangeness wrt to system time and power management. I don't have the time to bisect this right now, but wanted to let you know anyway.
Apart from that, the kernel seems to work fine.
HTH
Signature · 4 lines
Tilman Schmidt E-Mail: [email protected] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
Quoted 4 lines · On Sat, 25 Aug 2007 01:27:25 +0200 Tilman Schmidt <[email protected]> wrote:
Am 22.08.2007 11:06 schrieb Andrew Morton:
Quoted 1 line
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
After applying Matthew Wilcox' patch to
include/linux/isa.h
which patch is that?
Quoted 10 lines
this compiles
and boots on my Intel/openSUSE 10.2 test machine but throws out the following messages I don't remember ever seeing with other kernels:- on console early during boot, also in SuSE's
/var/log/boot.msg:your system time is not correct:
Wed Jul 13 13:15:31 UTC 1910
setting system time to:
Tue Jul 24 00:00:00 UTC 2007
What architecture?
if x86_64 then perhaps something went wrong with the old x86_64 dynticks leftovers which were in rc3-mm1. I've just merged a shiny fresh new series so perhaps things there got fixed. Please retest next -mm.
Suitable cc's added.
Quoted 9 lines
- later, dto. on console and in
/var/log/boot.msg:FATAL: Error inserting processor (
/lib/modules/2.6.23-rc3-mm1-testing/kernel/drivers/acpi/processor.ko): Input/output error
WARNING: Error inserting processor (/lib/modules/2.6.23-rc3-mm1-testing/kernel/drivers/acpi/processor.ko): Input/output error
FATAL: Error inserting thermal (/lib/modules/2.6.23-rc3-mm1-testing/kernel/drivers/acpi/thermal.ko): Unknown symbol in module, or unknown parameter (see dmesg)- apparently corresponding to that, in dmesg:
<4>[ 7.691865] thermal: Unknown symbol acpi_processor_set_thermal_limit
acpi cc's added
Quoted 4 lines
- from fsck during boot:
/dev/system/root: Superblock last mount time is in the future. FIXED./dev/system/root: Superblock last write time is in the future. FIXED.
Presumably related to the time problem.
Quoted 4 lines
- in
/var/log/warn:Aug 25 00:44:00 xenon powersaved[5356]: WARNING (CpufreqManagement:51) No capability cpufreq_control Aug 25 00:44:00 xenon powersaved[5356]: WARNING (CpufreqManagement:51) No capability cpufreq_control
Dunno, there're some significant-looking cpufreq changes in there, such as cpufreq-allow-ondemand-and-conservative-cpufreq-governors-to-be-used-as-default.patch. Maybe we went and chose a different governor for you?
Perhaps it would be helpful if you could do a
diff -u dmesg-2.6.23-rc3 dmesg-2.6.26-rc3-mm1
?
Quoted 6 lines
And the SUSE startup sequence displays "failed" for the acpid daemon. So it seems there is some strangeness wrt to system time and power management. I don't have the time to bisect this right now, but wanted to let you know anyway.
Apart from that, the kernel seems to work fine.
OK, thanks.
Quoted 5 lines
Quoted 4 lines
- in
/var/log/warn:Aug 25 00:44:00 xenon powersaved[5356]: WARNING(CpufreqManagement:51) No capability
cpufreq_control
Quoted 9 lines
Quoted 1 line
Aug 25 00:44:00 xenon powersaved[5356]: WARNING(CpufreqManagement:51) No capability
cpufreq_controlDunno, there're some significant-looking cpufreq changes in there, such as cpufreq-allow-ondemand-and-conservative-cpufreq-governors-to-be -used-as-default.patch.
Maybe we went and chose a different governor for you?
This is probably not related to cpufreq changes itself. Looks like it is coming due to
Quoted 6 lines
Quoted 1 line
FATAL: Error inserting processor
(
/lib/modules/2.6.23-rc3-mm1-testing/kernel/drivers/acpi/processor.ko): Input/output errorQuoted 1 line
WARNING: Error inserting processor
(
/lib/modules/2.6.23-rc3-mm1-testing/kernel/drivers/acpi/processor.ko): Input/output error
Not sure why this is failing though. Don't recall any significant changes in processor.ko recently apart from CPUIDLE stuff.
Thanks,
Venki
Quoted 33 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Pallipadi, Venkatesh
Sent: Friday, August 24, 2007 5:14 PM
To: Andrew Morton; Tilman Schmidt
Cc: [email protected]; Thomas Gleixner; john stultz; Andi Kleen; Len Brown; [email protected]; Dave Jones; Thomas Renninger
Subject: RE: 2.6.23-rc3-mm1Quoted 4 lines
Quoted 3 lines
- in
/var/log/warn:Aug 25 00:44:00 xenon powersaved[5356]: WARNING(CpufreqManagement:51) No capability
cpufreq_controlQuoted 9 lines
Quoted 1 line
Aug 25 00:44:00 xenon powersaved[5356]: WARNING(CpufreqManagement:51) No capability
cpufreq_controlDunno, there're some significant-looking cpufreq changes in there, such as cpufreq-allow-ondemand-and-conservative-cpufreq-governors-to-be -used-as-default.patch.
Maybe we went and chose a different governor for you?This is probably not related to cpufreq changes itself. Looks like it is
coming due toQuoted 1 line
Quoted 1 line
FATAL: Error inserting processor
Quoted 9 lines
Quoted 5 lines
(
/lib/modules/2.6.23-rc3-mm1-testing/kernel/drivers/acpi/processor.ko): Input/output errorQuoted 1 line
WARNING: Error inserting processor
(
/lib/modules/2.6.23-rc3-mm1-testing/kernel/drivers/acpi/processor.ko): Input/output errorNot sure why this is failing though. Don't recall any significant changes in processor.ko recently apart from CPUIDLE stuff.
This is indeed related to CPUIDLE.
Tilman: Can you configure CONFIG_CPU_IDLE in your config (under Power Management option) and double check that the frequency part works after that.
Andrew: Adam Belay sent a recent patchset on linux-pm and linux-acpi and one of the patches of that addresses this issue (CPUIDLE: load ACPI properly when CPUIDLE is disabled). Those patches should come to mm soon through acpi-test.
Thanks,
Venki
Am 25.08.2007 02:38 schrieb Pallipadi, Venkatesh:
Quoted 9 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
FATAL: Error inserting processor (
/lib/modules/2.6.23-rc3-mm1-testing/kernel/drivers/acpi/processor.ko): Input/output error
WARNING: Error inserting processor (/lib/modules/2.6.23-rc3-mm1-testing/kernel/drivers/acpi/processor.ko): Input/output errorThis is indeed related to CPUIDLE.
Tilman: Can you configure
CONFIG_CPU_IDLEin your config (under Power Management option) and double check that the frequency part works after that.
Strangely enough, I do not see that option in "make xconfig". The "Power Management" subtree ends with "CPU Frequency scaling". In "make menuconfig" the option is there, though.
After activating it, these two errors are indeed gone, and the "thermal: Unknown symbol acpi_processor_set_thermal_limit" one as well.
HTH
T.
Signature · 4 lines
Tilman Schmidt E-Mail: [email protected] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
Quoted 7 lines · On Sun, 26 Aug 2007 01:26:21 +0200 Tilman Schmidt wrote:
Am 25.08.2007 02:38 schrieb Pallipadi, Venkatesh:
Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
FATAL: Error inserting processor (
/lib/modules/2.6.23-rc3-mm1-testing/kernel/drivers/acpi/processor.ko): Input/output error
WARNING: Error inserting processor (/lib/modules/2.6.23-rc3-mm1-testing/kernel/drivers/acpi/processor.ko): Input/output errorThis is indeed related to CPUIDLE.
Quoted 7 lines
Quoted 3 lines
Tilman: Can you configure
CONFIG_CPU_IDLEin your config (under Power Management option) and double check that the frequency part works after that.Strangely enough, I do not see that option in "make xconfig". The "Power Management" subtree ends with "CPU Frequency scaling". In "make menuconfig" the option is there, though.
That sounds strange. Please share your .config file.
Quoted 3 lines
After activating it, these two errors are indeed gone, and the "thermal: Unknown symbol
acpi_processor_set_thermal_limit" one as well.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
Am 26.08.2007 01:57 schrieb Randy Dunlap:
Quoted 8 lines · On Sun, 26 Aug 2007 01:26:21 +0200 Tilman Schmidt wrote:
Quoted 7 lines
Am 25.08.2007 02:38 schrieb Pallipadi, Venkatesh:
Quoted 4 lines
Tilman: Can you configure
CONFIG_CPU_IDLEin your config (under Power Management option) and double check that the frequency part works after that.
Quoted 5 lines
Quoted 3 lines
Strangely enough, I do not see that option in "make xconfig". The "Power Management" subtree ends with "CPU Frequency scaling". In "make menuconfig" the option is there, though.
That sounds strange. Please share your .config file.
I'm sorry but I cannot reproduce the phenomenon anymore. After setting CONFIG_CPU_IDLE with "make menuconfig", when I ran "make xconfig" again it showed the option too. Moving .config.old back to .config doesn't make it disappear again. So it seems "make menuconfig" has elliminated whatever caused this.
If you still want to have a look, both .config and .config.old are available at http://gollum.phnxsoft.com/~ts/2.6.23-rc3-mm1/ .
Signature · 4 lines
Tilman Schmidt E-Mail: [email protected] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
Quoted 9 lines · Andrew Morton
Quoted 5 lines
FATAL: Error inserting processor (
/lib/modules/2.6.23-rc3-mm1-testing/kernel/drivers/acpi/processor.ko): Input/output error
WARNING: Error inserting processor (/lib/modules/2.6.23-rc3-mm1-testing/kernel/drivers/acpi/processor.ko): Input/output errorAug 25 00:44:00 xenon powersaved[5356]: WARNING (CpufreqManagement:51) No capability cpufreq_control Aug 25 00:44:00 xenon powersaved[5356]: WARNING (CpufreqManagement:51) No capability cpufreq_controlDunno, there're some significant-looking cpufreq changes in there, such as cpufreq-allow-ondemand-and-conservative-cpufreq-governors-to-be-used-as-default.patch. Maybe we went and chose a different governor for you?
More likely, he was using a cpufreq driver that required acpi functionality, and because processor.ko went boom, the house of cards came tumbling down.
I long for the olde days when acpi changes didn't end up with finger pointing at cpufreq.
Dave
Signature · 1 line
http://www.codemonkey.org.uk
Quoted 20 lines · Andrew Morton
Quoted 4 lines · On Sat, 25 Aug 2007 01:27:25 +0200 Tilman Schmidt <[email protected]> wrote:
Am 22.08.2007 11:06 schrieb Andrew Morton:
Quoted 1 line
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
After applying Matthew Wilcox' patch to
include/linux/isa.hwhich patch is that?
Quoted 10 lines
this compiles
and boots on my Intel/openSUSE 10.2 test machine but throws out the following messages I don't remember ever seeing with other kernels:- on console early during boot, also in SuSE's
/var/log/boot.msg:your system time is not correct:
Wed Jul 13 13:15:31 UTC 1910
setting system time to:
Tue Jul 24 00:00:00 UTC 2007
Hrmm. I'm not super familiar w/ SuSE's init scripts, but I'm guessing that's the ntpdate call. And "Tuesday Jul 24th"? Sounds about a month off, is this just stale info?
Quoted 6 lines
What architecture?
if
x86_64then perhaps something went wrong with the oldx86_64dynticks leftovers which were in rc3-mm1. I've just merged a shiny fresh new series so perhaps things there got fixed. Please retest next -mm.
[snip]
Quoted 6 lines
Quoted 4 lines
- from fsck during boot:
/dev/system/root: Superblock last mount time is in the future. FIXED./dev/system/root: Superblock last write time is in the future. FIXED.Presumably related to the time problem.
Does this show up before or after the above date stuff? Does the issue go away using an older kernel (I want to eliminate easy stuff like CMOS batteries giving up)?
Also you're not using Linus' CMOS corrupting suspend/resume debugging trick, right (I'm forgetting the CONFIG name).
thanks
-john
Am 25.08.2007 02:21 schrieb john stultz:
Quoted 11 lines
Quoted 8 lines
Quoted 6 lines · Tilman Schmidt
- on console early during boot, also in SuSE's
/var/log/boot.msg:your system time is not correct:
Wed Jul 13 13:15:31 UTC 1910
setting system time to:
Tue Jul 24 00:00:00 UTC 2007Hrmm. I'm not super familiar w/ SuSE's init scripts, but I'm guessing that's the ntpdate call.
Nope. The ntpdate call comes much later, and finally sets the system clock correctly so that there are no lasting effects of all this.
Quoted 2 lines
And "Tuesday Jul 24th"? Sounds about a month
off, is this just stale info?
I have no idea where that might come from.
Quoted 4 lines
Quoted 2 lines
Quoted 2 lines
/dev/system/root: Superblock last mount time is in the future. FIXED./dev/system/root: Superblock last write time is in the future. FIXED.Does this show up before or after the above date stuff?
After the "your system time is not correct" messages, and before the regular "Try to get initial date and time via NTP" message accompanying the ntpdate call.
Quoted 2 lines
Does the issue go away using an older kernel (I want to eliminate easy stuff like CMOS batteries giving up)?
It does. Booting 2.6.23-rc3 after that, the system comes up with none of these messages.
Quoted 2 lines
Also you're not using Linus' CMOS corrupting suspend/resume debugging trick, right (I'm forgetting the CONFIG name).
PM_TRACE? No. The entire PM_DEBUG branch is turned off.
Signature · 4 lines
Tilman Schmidt E-Mail: [email protected] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
Am 25.08.2007 02:07 schrieb Andrew Morton:
Quoted 9 lines
Quoted 4 lines · On Sat, 25 Aug 2007 01:27:25 +0200 Tilman Schmidt <[email protected]> wrote:
Am 22.08.2007 11:06 schrieb Andrew Morton:
Quoted 1 line
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
After applying Matthew Wilcox' patch to
include/linux/isa.hwhich patch is that?
The one allowing drivers/scsi/advansys.c to compile with CONFIG_ISA=n:
Date: Wed, 22 Aug 2007 10:28:02 -0600
From: Matthew Wilcox <[email protected]>
Subject: Re: drivers/scsi/advansys.c - ld error ( Re: 2.6.23-rc3-mm1 )
Message-ID: <[email protected]>
When CONFIG_ISA is disabled, the isa_driver support will not be compiled in. Define stubs so that we don't get link-time errors.
Quoted 4 lines
Quoted 4 lines
this compiles
and boots on my Intel/openSUSE 10.2 test machine but throws out the following messages I don't remember ever seeing with other kernels:
Quoted 8 lines
Quoted 6 lines
- on console early during boot, also in SuSE's
/var/log/boot.msg:your system time is not correct:
Wed Jul 13 13:15:31 UTC 1910
setting system time to:
Tue Jul 24 00:00:00 UTC 2007What architecture?
i386. The machine is a Pentium D 940 which would be x86_64 capable, but I'm still running 32 bit kernels on it.
Quoted 3 lines
if
x86_64then perhaps something went wrong with the oldx86_64dynticks leftovers which were in rc3-mm1. I've just merged a shiny fresh new series so perhaps things there got fixed. Please retest next -mm.
Will do that anyway.
Quoted 3 lines
Perhaps it would be helpful if you could do a
diff -u dmesg-2.6.23-rc3 dmesg-2.6.26-rc3-mm1
I hope the attached helps. I created it by taking /var/log/boot.msg of the two systems, removing everything after "Kernel logging stopped", editing out the printk timestamps and then running diff -u on them, so it should be more or less the dmesg diff. I did not edit out any of the differences because I'm lazy. (And also because I wasn't so sure what would or wouldn't be interesting for you.)
Signature · 4 lines
Tilman Schmidt E-Mail: [email protected] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
tmp/bootmsg-2.6.23-rc3-mm1 renamed from tmp/bootmsg-2.6.23-rc3 +154 -103
@@ -1,10 +1,10 @@ -Inspecting /boot/System.map-2.6.23-rc3-testing -Loaded 27522 symbols from /boot/System.map-2.6.23-rc3-testing. +Inspecting /boot/System.map-2.6.23-rc3-mm1-testing +Loaded 28663 symbols from /boot/System.map-2.6.23-rc3-mm1-testing. Symbols match kernel version 2.6.23. No module symbols loaded - kernel modules not enabled. klogd 1.4.1, log source = ksyslog started. -<5>Linux version 2.6.23-rc3-testing (ts@xenon) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #1 SMP PREEMPT Tue Aug 14 15:27:26 CEST 2007 +<5>Linux version 2.6.23-rc3-mm1-testing (ts@xenon) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #1 SMP PREEMPT Thu Aug 23 00:02:51 CEST 2007 <6>BIOS-provided physical RAM map: <4> BIOS-e820: 0000000000000000 - 000000000008f000 (usable) <4> BIOS-e820: 000000000008f000 - 00000000000a0000 (reserved)
@@ -25,6 +25,7 @@ <5>896MB LOWMEM available. <6>found SMP MP-table at 000fe200 <7>Entering add_active_range(0, 0, 255744) 0 entries of 256 used +<7>sizeof(struct page) = 56 <4>Zone PFN ranges: <4> DMA 0 -> 4096 <4> Normal 4096 -> 229376
@@ -33,6 +34,7 @@ <4>early_node_map[1] active PFN ranges <4> 0: 0 -> 255744 <7>On node 0 totalpages: 255744 +<7>Node 0 memmap at 0xc1000000 size 14336000 first pfn 0xc1000000 <7> DMA zone: 56 pages used for memmap <7> DMA zone: 0 pages reserved <7> DMA zone: 4040 pages, LIFO batch:0
@@ -82,16 +84,16 @@ <4>swsusp: Registered nosave memory region: 000000000008f000 - 00000000000a0000 <4>swsusp: Registered nosave memory region: 00000000000a0000 - 00000000000e0000 <4>swsusp: Registered nosave memory region: 00000000000e0000 - 0000000000100000 -<4>Built 1 zonelists in Zone order. Total pages: 252248 +<4>Built 1 zonelists in Zone order, mobility grouping on. Total pages: 252248 <5>Kernel command line: root=/dev/system/root video=matroxfb:vesa:0x31b resume=/dev/system/swap splash=verbose <7>mapped APIC to ffffb000 (fee00000) <7>mapped IOAPIC to ffffa000 (fec00000) <6>Enabling fast FPU save and restore... done. <6>Enabling unmasked SIMD FPU exception support... done. <6>Initializing CPU#0 -<4>CPU 0 irqstacks, hard=c0451000 soft=c0449000 +<4>CPU 0 irqstacks, hard=c04d0000 soft=c04c8000 <4>PID hash table entries: 4096 (order: 12, 16384 bytes) -<4>Detected 3197.068 MHz processor. +<4>Detected 3196.982 MHz processor. <4>Console: colour VGA+ 80x25 <6>console [tty0] enabled <4>Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
@@ -188,21 +190,21 @@ <4>--------------------------------- <6>Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) <6>Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) -<6>Memory: 993044k/1022976k available (2040k kernel code, 28100k reserved, 1042k data, 252k init, 104484k highmem) +<6>Memory: 992396k/1022976k available (2110k kernel code, 28776k reserved, 1467k data, 260k init, 104484k highmem) <4>virtual kernel memory layout: <4> fixmap : 0xfff4c000 - 0xfffff000 ( 716 kB) <4> pkmap : 0xff800000 - 0xffc00000 (4096 kB) <4> vmalloc : 0xf8800000 - 0xff7fe000 ( 111 MB) <4> lowmem : 0xc0000000 - 0xf8000000 ( 896 MB) -<4> .init : 0xc0407000 - 0xc0446000 ( 252 kB) -<4> .data : 0xc02fe179 - 0xc0402ce4 (1042 kB) -<4> .text : 0xc0100000 - 0xc02fe179 (2040 kB) +<4> .init : 0xc0483000 - 0xc04c4000 ( 260 kB) +<4> .data : 0xc030f81f - 0xc047e4c4 (1467 kB) +<4> .text : 0xc0100000 - 0xc030f81f (2110 kB) <4>Checking if this processor honours the WP bit even in supervisor mode... Ok. -<6>SLUB: Genslabs=22, HWalign=64, Order=0-1, MinObjects=4, CPUs=2, Nodes=1 -<6>hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 -<6>hpet0: 3 64-bit timers, 14318180 Hz -<4>Calibrating delay using timer specific routine.. 6399.65 BogoMIPS (lpj=3199825) -<6>Security Framework v1.0.0 initialized +<6>SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=16, CPUs=2, Nodes=1 +<4>Calibrating delay using timer specific routine.. 6399.03 BogoMIPS (lpj=3199517) +<6>kswapd reclaim order set to 3 +<6>Security Framework initialized +<6>Capability LSM initialized <4>Mount-cache hash table entries: 512 <7>CPU: After generic identify, caps: bfebfbff 20100000 00000000 00000000 0000e4bd 00000000 00000001 00000000 <4>monitor/mwait feature present.
@@ -223,9 +225,9 @@ <4>CPU0: Intel(R) Pentium(R) D CPU 3.20GHz stepping 04 <4>lockdep: not fixing up alternatives. <4>Booting processor 1/1 eip 3000 -<4>CPU 1 irqstacks, hard=c0452000 soft=c044a000 +<4>CPU 1 irqstacks, hard=c04d1000 soft=c04c9000 <6>Initializing CPU#1 -<4>Calibrating delay using timer specific routine.. 6393.68 BogoMIPS (lpj=3196844) +<4>Calibrating delay using timer specific routine.. 6392.76 BogoMIPS (lpj=3196383) <7>CPU: After generic identify, caps: bfebfbff 20100000 00000000 00000000 0000e4bd 00000000 00000001 00000000 <4>monitor/mwait feature present. <6>CPU: Trace cache: 12K uops, L1 D cache: 16K
@@ -238,23 +240,27 @@ <6>CPU1: Intel P4/Xeon Extended MCE MSRs (24) available <6>CPU1: Thermal monitoring enabled <4>CPU1: Intel(R) Pentium(R) D CPU 3.20GHz stepping 04 -<6>Total of 2 processors activated (12793.33 BogoMIPS). +<6>Total of 2 processors activated (12791.80 BogoMIPS). <4>ENABLING IO-APIC IRQs <6>..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 -<6>checking TSC synchronization [CPU#0 -> CPU#1]: passed. +<6>checking TSC synchronization [CPU#0 -> CPU#1]: +<4>Measured 32 cycles TSC warp between CPUs, turning off TSC clock. +<4>Marking TSC unstable due to: check_tsc_sync_source failed. <6>Brought up 2 CPUs <6>Booting paravirtualized kernel on bare hardware <6>NET: Registered protocol family 16 <6>ACPI: bus type pci registered -<3>PCI: BIOS Bug: MCFG area at f0000000 is not E820-reserved -<3>PCI: Not using MMCONFIG. <6>PCI: Using configuration type 1 <4>Setting up standard PCI resources <7>ACPI: EC: Look up EC in DSDT <6>ACPI: Interpreter enabled <6>ACPI: (supports S0 S3) <6>ACPI: Using IOAPIC for interrupt routing +<5>PCI: MCFG configuration 0: base 4026531840 segment 0 buses 0 - 127 +<5>PCI: MCFG area at f0000000 reserved in ACPI motherboard resources +<6>PCI: Using MMCONFIG <6>ACPI: PCI Root Bridge [PCI0] (0000:00) +<7>PCI: Probing PCI hardware (bus 00) <4>PCI quirk: region 0400-047f claimed by ICH6 ACPI/GPIO/TCO <4>PCI quirk: region 0500-053f claimed by ICH6 GPIO <6>PCI: Transparent bridge - 0000:00:1e.0
@@ -285,7 +291,9 @@ <6>NetLabel: protocols = UNLABELED CIPSOv4 <6>NetLabel: unlabeled traffic allowed by default <4>ACPI: RTC can wake from S4 -<6>Time: tsc clocksource has been installed. +<6>Time: hpet clocksource has been installed. +<6>Switched to high resolution mode on CPU 0 +<6>Switched to high resolution mode on CPU 1 <6>pnp: 00:01: iomem range 0xf0000000-0xf7ffffff has been reserved <6>pnp: 00:01: iomem range 0xfed13000-0xfed13fff has been reserved <6>pnp: 00:01: iomem range 0xfed14000-0xfed17fff has been reserved
@@ -340,15 +348,11 @@ <6>TCP bind hash table entries: 65536 (order: 9, 2359296 bytes) <6>TCP: Hash tables configured (established 65536 bind 65536) <6>TCP reno registered -<6>checking if image is initramfs...<6>Switched to high resolution mode on CPU 1 -<6>Switched to high resolution mode on CPU 0 -<4> it is -<6>Freeing initrd memory: 7369k freed +<6>checking if image is initramfs... it is +<6>Freeing initrd memory: 7423k freed <6>Machine check exception polling timer started. -<6>apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac) -<5>apm: disabled - APM is not SMP safe. <6>audit: initializing netlink socket (disabled) -<5>audit(1187997798.852:1): initialized +<5>audit(2418234223.871:1): initialized <4>highmem bounce pool size: 64 pages <4>Total HugeTLB memory allocated, 0 <5>VFS: Disk quotas dquot_6.5.1
@@ -363,22 +367,27 @@ <4>assign_interrupt_mode Found MSI capability <7>Allocate Port Service[0000:00:1c.0:pcie00] <7>Allocate Port Service[0000:00:1c.0:pcie02] +<7>Allocate Port Service[0000:00:1c.0:pcie03] <7>PCI: Setting latency timer of device 0000:00:1c.1 to 64 <4>assign_interrupt_mode Found MSI capability <7>Allocate Port Service[0000:00:1c.1:pcie00] <7>Allocate Port Service[0000:00:1c.1:pcie02] +<7>Allocate Port Service[0000:00:1c.1:pcie03] <7>PCI: Setting latency timer of device 0000:00:1c.2 to 64 <4>assign_interrupt_mode Found MSI capability <7>Allocate Port Service[0000:00:1c.2:pcie00] <7>Allocate Port Service[0000:00:1c.2:pcie02] +<7>Allocate Port Service[0000:00:1c.2:pcie03] <7>PCI: Setting latency timer of device 0000:00:1c.3 to 64 <4>assign_interrupt_mode Found MSI capability <7>Allocate Port Service[0000:00:1c.3:pcie00] <7>Allocate Port Service[0000:00:1c.3:pcie02] +<7>Allocate Port Service[0000:00:1c.3:pcie03] <7>PCI: Setting latency timer of device 0000:00:1c.4 to 64 <4>assign_interrupt_mode Found MSI capability <7>Allocate Port Service[0000:00:1c.4:pcie00] <7>Allocate Port Service[0000:00:1c.4:pcie02] +<7>Allocate Port Service[0000:00:1c.4:pcie03] <6>ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 19 (level, low) -> IRQ 19 <6>matroxfb: Matrox G550 detected <6>PInS memtype = 5
@@ -390,7 +399,7 @@ <4>fb0: MATROX frame buffer device <6>matroxfb_crtc2: secondary head of fb0 was registered as fb1 <6>Real Time Clock Driver v1.12ac -<7>hpet_resources: 0xfed00000 is busy +<4>hpet_acpi_add: no address or irqs in _CRS <6>Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled <6>serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A <6>00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
@@ -407,18 +416,15 @@ <4>PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp <6>serio: i8042 KBD port at 0x60,0x64 irq 1 <6>mice: PS/2 mouse device common for all mice -<6>input: AT Translated Set 2 keyboard as /class/input/input0 -<6>input: PC Speaker as /class/input/input1 +<6>input: PC Speaker as /class/input/input0 <6>NET: Registered protocol family 1 <6>Starting balanced_irq <4>Using IPI No-Shortcut mode -<6>Freeing unused kernel memory: 252k freed -<4>Write protecting the kernel read-only data: 814k +<6>Freeing unused kernel memory: 260k freed +<4>Write protecting the kernel read-only data: 1215k +<6>input: AT Translated Set 2 keyboard as /class/input/input1 <5>SCSI subsystem initialized -<6>ACPI: Processor [CPU0] (supports 8 throttling states) -<6>ACPI: Processor [CPU1] (supports 8 throttling states) -<4>ACPI Exception (processor_core-0790): AE_NOT_FOUND, Processor Device is not present [20070126] -<4>ACPI Exception (processor_core-0790): AE_NOT_FOUND, Processor Device is not present [20070126] +<4>thermal: Unknown symbol acpi_processor_set_thermal_limit <7>libata version 2.21 loaded. <7>ahci 0000:00:1f.2: version 2.3 <6>ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 19 (level, low) -> IRQ 19
@@ -431,12 +437,12 @@ <6>scsi3 : ahci <6>scsi4 : ahci <6>scsi5 : ahci -<6>ata1: SATA max UDMA/133 cmd 0xf887c100 ctl 0x00000000 bmdma 0x00000000 irq 218 -<6>ata2: SATA max UDMA/133 cmd 0xf887c180 ctl 0x00000000 bmdma 0x00000000 irq 218 -<6>ata3: SATA max UDMA/133 cmd 0xf887c200 ctl 0x00000000 bmdma 0x00000000 irq 218 -<6>ata4: SATA max UDMA/133 cmd 0xf887c280 ctl 0x00000000 bmdma 0x00000000 irq 218 -<6>ata5: SATA max UDMA/133 cmd 0xf887c300 ctl 0x00000000 bmdma 0x00000000 irq 218 -<6>ata6: SATA max UDMA/133 cmd 0xf887c380 ctl 0x00000000 bmdma 0x00000000 irq 218 +<6>ata1: SATA max UDMA/133 cmd 0xf883c100 ctl 0x00000000 bmdma 0x00000000 irq 218 +<6>ata2: SATA max UDMA/133 cmd 0xf883c180 ctl 0x00000000 bmdma 0x00000000 irq 218 +<6>ata3: SATA max UDMA/133 cmd 0xf883c200 ctl 0x00000000 bmdma 0x00000000 irq 218 +<6>ata4: SATA max UDMA/133 cmd 0xf883c280 ctl 0x00000000 bmdma 0x00000000 irq 218 +<6>ata5: SATA max UDMA/133 cmd 0xf883c300 ctl 0x00000000 bmdma 0x00000000 irq 218 +<6>ata6: SATA max UDMA/133 cmd 0xf883c380 ctl 0x00000000 bmdma 0x00000000 irq 218 <6>ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) <6>ata1.00: ATA-7: ST380811AS, 3.AAE, max UDMA/133 <6>ata1.00: 156301488 sectors, multi 0: LBA48 NCQ (depth 31/32)
@@ -465,12 +471,12 @@ <5>sd 1:0:0:0: [sdb] Write Protect is off <7>sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 <5>sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA +<5>sd 0:0:0:0: Attached scsi generic sg0 type 0 <5>sd 1:0:0:0: [sdb] 156301488 512-byte hardware sectors (80026 MB) <5>sd 1:0:0:0: [sdb] Write Protect is off <7>sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 <5>sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA -<6> sdb:<5>sd 0:0:0:0: Attached scsi generic sg0 type 0 -<4> sdb1 +<6> sdb: sdb1 <5>sd 1:0:0:0: [sdb] Attached SCSI disk <5>sd 1:0:0:0: Attached scsi generic sg1 type 0 <6>ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 17 (level, low) -> IRQ 16
@@ -517,94 +523,139 @@ <5>st 8:0:12:0: Attached scsi tape st0 <6>st 8:0:12:0: st0: try direct i/o: yes (alignment 512 B) <6>Linux agpgart interface v0.102 +<6>rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0 +<4>rtc_cmos: probe of 00:03 failed with error -16 +<6>agpgart: suspend/resume problematic: resume with 3D/DRI active may lockup X.Org +<4>on some chipset/BIOS combos (see DEBUG_AGP_PM in intel-agp.c) <6>agpgart: Detected an Intel 965Q Chipset. <6>agpgart: Unknown page table size, assuming 512KB <6>agpgart: Detected 7676K stolen memory. <6>agpgart: AGP aperture is 256M @ 0x40000000 -<6>rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0 -<4>rtc_cmos: probe of 00:03 failed with error -16 <6>ACPI: PCI Interrupt 0000:00:1f.3[B] -> GSI 21 (level, low) -> IRQ 22 <6>usbcore: registered new interface driver usbfs <6>usbcore: registered new interface driver hub <6>usbcore: registered new device driver usb <6>ACPI: PCI Interrupt 0000:07:03.0[A] -> GSI 19 (level, low) -> IRQ 19 -<6>ACPI: PCI Interrupt 0000:00:1a.7[C] -> GSI 18 (level, low) -> IRQ 18 -<7>PCI: Setting latency timer of device 0000:00:1a.7 to 64 -<6>ehci_hcd 0000:00:1a.7: EHCI Host Controller -<6>ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1 -<5>firewire_ohci: Added fw-ohci device 0000:07:03.0, OHCI version 1.10 -<6>ehci_hcd 0000:00:1a.7: debug port 1 -<7>PCI: cache line size of 128 is not supported by device 0000:00:1a.7 -<6>ehci_hcd 0000:00:1a.7: irq 18, io mem 0x52c25c00 -<6>ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 -<6>usb usb1: configuration #1 chosen from 1 choice -<6>hub 1-0:1.0: USB hub found -<6>hub 1-0:1.0: 4 ports detected <6>USB Universal Host Controller Interface driver v3.0 -<6>ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 23 -<7>PCI: Setting latency timer of device 0000:00:1d.7 to 64 -<6>ehci_hcd 0000:00:1d.7: EHCI Host Controller -<6>ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 2 -<6>ehci_hcd 0000:00:1d.7: debug port 1 -<7>PCI: cache line size of 128 is not supported by device 0000:00:1d.7 -<6>ehci_hcd 0000:00:1d.7: irq 23, io mem 0x52c25800 -<6>ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 -<6>usb usb2: configuration #1 chosen from 1 choice -<6>hub 2-0:1.0: USB hub found -<6>hub 2-0:1.0: 6 ports detected <6>ACPI: PCI Interrupt 0000:00:1a.0[A] -> GSI 16 (level, low) -> IRQ 17 <7>PCI: Setting latency timer of device 0000:00:1a.0 to 64 <6>uhci_hcd 0000:00:1a.0: UHCI Host Controller -<6>uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 3 +<6>uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 1 <6>uhci_hcd 0000:00:1a.0: irq 17, io base 0x000030c0 -<6>usb usb3: configuration #1 chosen from 1 choice -<6>hub 3-0:1.0: USB hub found -<6>hub 3-0:1.0: 2 ports detected +<6>usb usb1: configuration #1 chosen from 1 choice +<6>hub 1-0:1.0: USB hub found +<6>hub 1-0:1.0: 2 ports detected +<5>firewire_ohci: Added fw-ohci device 0000:07:03.0, OHCI version 1.10 +<6>usb usb1: new device found, idVendor=0000, idProduct=0000 +<6>usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1 +<6>usb usb1: Product: UHCI Host Controller +<6>usb usb1: Manufacturer: Linux 2.6.23-rc3-mm1-testing uhci_hcd +<6>usb usb1: SerialNumber: 0000:00:1a.0 <6>ACPI: PCI Interrupt 0000:00:1a.1[B] -> GSI 21 (level, low) -> IRQ 22 <7>PCI: Setting latency timer of device 0000:00:1a.1 to 64 <6>uhci_hcd 0000:00:1a.1: UHCI Host Controller -<6>uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4 +<6>uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 2 <6>uhci_hcd 0000:00:1a.1: irq 22, io base 0x000030a0 -<6>usb usb4: configuration #1 chosen from 1 choice -<6>hub 4-0:1.0: USB hub found -<6>hub 4-0:1.0: 2 ports detected -<5>firewire_core: created new fw device fw0 (0 config rom retries, S400) +<6>usb usb2: configuration #1 chosen from 1 choice +<6>hub 2-0:1.0: USB hub found +<6>hub 2-0:1.0: 2 ports detected +<6>usb usb2: new device found, idVendor=0000, idProduct=0000 +<6>usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1 +<6>usb usb2: Product: UHCI Host Controller +<6>usb usb2: Manufacturer: Linux 2.6.23-rc3-mm1-testing uhci_hcd +<6>usb usb2: SerialNumber: 0000:00:1a.1 +<6>ACPI: PCI Interrupt 0000:00:1a.7[C] -> GSI 18 (level, low) -> IRQ 18 +<7>PCI: Setting latency timer of device 0000:00:1a.7 to 64 +<6>ehci_hcd 0000:00:1a.7: EHCI Host Controller +<6>ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 3 +<6>ehci_hcd 0000:00:1a.7: debug port 1 +<7>PCI: cache line size of 128 is not supported by device 0000:00:1a.7 +<6>ehci_hcd 0000:00:1a.7: irq 18, io mem 0x52c25c00 +<6>ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 +<6>usb usb3: configuration #1 chosen from 1 choice +<6>hub 3-0:1.0: USB hub found +<6>hub 3-0:1.0: 4 ports detected +<6>usb usb3: new device found, idVendor=0000, idProduct=0000 +<6>usb usb3: new device strings: Mfr=3, Product=2, SerialNumber=1 +<6>usb usb3: Product: EHCI Host Controller +<6>usb usb3: Manufacturer: Linux 2.6.23-rc3-mm1-testing ehci_hcd +<6>usb usb3: SerialNumber: 0000:00:1a.7 <6>ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 23 <7>PCI: Setting latency timer of device 0000:00:1d.0 to 64 <6>uhci_hcd 0000:00:1d.0: UHCI Host Controller -<6>uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 5 +<6>uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 4 <6>uhci_hcd 0000:00:1d.0: irq 23, io base 0x00003080 -<6>usb usb5: configuration #1 chosen from 1 choice -<6>hub 5-0:1.0: USB hub found -<6>hub 5-0:1.0: 2 ports detected -<6>ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 21 -<7>PCI: Setting latency timer of device 0000:00:1b.0 to 64 -<7>ALSA sound/pci/hda/hda_codec.c:2331: autoconfig: line_outs=1 (0xd/0x0/0x0/0x0/0x0) -<7>ALSA sound/pci/hda/hda_codec.c:2335: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) -<7>ALSA sound/pci/hda/hda_codec.c:2339: hp_outs=1 (0xa/0x0/0x0/0x0/0x0) -<7>ALSA sound/pci/hda/hda_codec.c:2347: inputs: mic=0xe, fmic=0xb, line=0xf, fline=0x0, cd=0x0, aux=0x0 -<7>ALSA sound/pci/hda/patch_sigmatel.c:1297: dac_nids=3 (0x2/0x5/0x4/0x0/0x0) +<6>usb usb4: configuration #1 chosen from 1 choice +<6>hub 4-0:1.0: USB hub found +<6>hub 4-0:1.0: 2 ports detected +<5>firewire_core: created new fw device fw0 (0 config rom retries, S400) +<6>usb usb4: new device found, idVendor=0000, idProduct=0000 +<6>usb usb4: new device strings: Mfr=3, Product=2, SerialNumber=1 +<6>usb usb4: Product: UHCI Host Controller +<6>usb usb4: Manufacturer: Linux 2.6.23-rc3-mm1-testing uhci_hcd +<6>usb usb4: SerialNumber: 0000:00:1d.0 <6>ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 19 <7>PCI: Setting latency timer of device 0000:00:1d.1 to 64 <6>uhci_hcd 0000:00:1d.1: UHCI Host Controller -<6>uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 6 +<6>uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 5 <6>uhci_hcd 0000:00:1d.1: irq 19, io base 0x00003060 -<6>usb usb6: configuration #1 chosen from 1 choice -<6>hub 6-0:1.0: USB hub found -<6>hub 6-0:1.0: 2 ports detected +<6>usb usb5: configuration #1 chosen from 1 choice +<6>hub 5-0:1.0: USB hub found +<6>hub 5-0:1.0: 2 ports detected +<6>usb usb5: new device found, idVendor=0000, idProduct=0000 +<6>usb usb5: new device strings: Mfr=3, Product=2, SerialNumber=1 +<6>usb usb5: Product: UHCI Host Controller +<6>usb usb5: Manufacturer: Linux 2.6.23-rc3-mm1-testing uhci_hcd +<6>usb usb5: SerialNumber: 0000:00:1d.1 <6>ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 18 <7>PCI: Setting latency timer of device 0000:00:1d.2 to 64 <6>uhci_hcd 0000:00:1d.2: UHCI Host Controller -<6>uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 7 +<6>uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 6 <6>uhci_hcd 0000:00:1d.2: irq 18, io base 0x00003040 +<6>usb usb6: configuration #1 chosen from 1 choice +<6>hub 6-0:1.0: USB hub found +<6>hub 6-0:1.0: 2 ports detected +<6>usb usb6: new device found, idVendor=0000, idProduct=0000 +<6>usb usb6: new device strings: Mfr=3, Product=2, SerialNumber=1 +<6>usb usb6: Product: UHCI Host Controller +<6>usb usb6: Manufacturer: Linux 2.6.23-rc3-mm1-testing uhci_hcd +<6>usb usb6: SerialNumber: 0000:00:1d.2 +<6>ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 23 +<7>PCI: Setting latency timer of device 0000:00:1d.7 to 64 +<6>ehci_hcd 0000:00:1d.7: EHCI Host Controller +<6>ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 7 +<6>ehci_hcd 0000:00:1d.7: debug port 1 +<7>PCI: cache line size of 128 is not supported by device 0000:00:1d.7 +<6>ehci_hcd 0000:00:1d.7: irq 23, io mem 0x52c25800 +<6>ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 +<6>usb 5-2: new low speed USB device using uhci_hcd and address 2 <6>usb usb7: configuration #1 chosen from 1 choice <6>hub 7-0:1.0: USB hub found -<6>hub 7-0:1.0: 2 ports detected -<6>usb 6-2: new low speed USB device using uhci_hcd and address 2 -<6>usb 6-2: configuration #1 chosen from 1 choice +<6>hub 7-0:1.0: 6 ports detected +<6>usb usb7: new device found, idVendor=0000, idProduct=0000 +<6>usb usb7: new device strings: Mfr=3, Product=2, SerialNumber=1 +<6>usb usb7: Product: EHCI Host Controller +<6>usb usb7: Manufacturer: Linux 2.6.23-rc3-mm1-testing ehci_hcd +<6>usb usb7: SerialNumber: 0000:00:1d.7 +<6>ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 21 +<7>PCI: Setting latency timer of device 0000:00:1b.0 to 64 +<7>ALSA sound/pci/hda/hda_codec.c:2735: autoconfig: line_outs=1 (0xd/0x0/0x0/0x0/0x0) +<7>ALSA sound/pci/hda/hda_codec.c:2739: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) +<7>ALSA sound/pci/hda/hda_codec.c:2743: hp_outs=1 (0xa/0x0/0x0/0x0/0x0) +<7>ALSA sound/pci/hda/hda_codec.c:2751: inputs: mic=0xe, fmic=0xb, line=0xf, fline=0x0, cd=0x0, aux=0x0 +<7>ALSA sound/pci/hda/patch_sigmatel.c:1344: dac_nids=3 (0x2/0x5/0x4/0x0/0x0) <6>Adding 2097144k swap on /dev/system/swap. Priority:-1 extents:1 across:2097144k -<6>usb 7-1: new full speed USB device using uhci_hcd and address 2 -<6>usb 7-1: configuration #1 chosen from 1 choice +<6>usb 5-2: new low speed USB device using uhci_hcd and address 3 +<6>usb 5-2: configuration #1 chosen from 1 choice +<6>usb 5-2: new device found, idVendor=413c, idProduct=3010 +<6>usb 5-2: new device strings: Mfr=0, Product=0, SerialNumber=0 +<6>usb 6-1: new full speed USB device using uhci_hcd and address 2 +<6>usb 6-1: configuration #1 chosen from 1 choice +<6>usb 6-1: new device found, idVendor=0681, idProduct=0002 +<6>usb 6-1: new device strings: Mfr=1, Product=2, SerialNumber=3 +<6>usb 6-1: Product: Sinus 45 AB isdn +<6>usb 6-1: Manufacturer: Siemens AG +<6>usb 6-1: SerialNumber: 002F970BE0 <6>usbcore: registered new interface driver hiddev <6>input: HID 413c:3010 as /class/input/input2 <6>input: USB HID v1.00 Mouse [HID 413c:3010] on usb-0000:00:1d.1-2
@@ -617,9 +668,10 @@ <7>gigaset: Register driver capabilities to LL <7>bas_gigaset: gigaset_probe: Check if device matches .. (Vendor: 0x681, Product: 0x2) <7>bas_gigaset: gigaset_probe: wrong alternate setting 0 - trying to switch -<6>usb 7-1: gigaset_probe: Device matched (Vendor: 0x681, Product: 0x2) +<6>usb 6-1: gigaset_probe: Device matched (Vendor: 0x681, Product: 0x2) <7>bas_gigaset: -------> 0x34 (0) <7>gigaset: scheduling START +<7>bas_gigaset: <-------3: 0x11 (0 [0x00 0x00]) <7>gigaset: connection state 0, event -110 <7>gigaset: unblocking all channels <7>gigaset: blocking all channels
@@ -630,7 +682,6 @@ <7>gigaset: connection state 0, event -27 <6>usbcore: registered new interface driver bas_gigaset <6>bas_gigaset: Tilman Schmidt <[email protected]>, Hansjoerg Lipp <[email protected]>, Stefan Eilers -<7>bas_gigaset: <-------3: 0x11 (0 [0x00 0x00]) <6>bas_gigaset: USB Driver for Gigaset 307x <7>bas_gigaset: <-------3: 0x11 (0 [0x00 0x00]) <7>gigaset: scheduling timeout
Quoted 13 lines · On Sat, 25 Aug 2007 02:47:59 +0200 Tilman Schmidt <[email protected]> wrote:
Am 25.08.2007 02:07 schrieb Andrew Morton:
Quoted 9 lines
Quoted 4 lines · On Sat, 25 Aug 2007 01:27:25 +0200 Tilman Schmidt <[email protected]> wrote:
Am 22.08.2007 11:06 schrieb Andrew Morton:
Quoted 1 line
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
After applying Matthew Wilcox' patch to
include/linux/isa.hwhich patch is that?
The one allowing
drivers/scsi/advansys.cto compile withCONFIG_ISA=n:
Quoted 7 lines
Date: Wed, 22 Aug 2007 10:28:02 -0600
From: Matthew Wilcox <[email protected]>
Subject: Re:drivers/scsi/advansys.c- ld error ( Re: 2.6.23-rc3-mm1 )
Message-ID: <[email protected]>When
CONFIG_ISAis disabled, theisa_driversupport will not be compiled in. Define stubs so that we don't get link-time errors.
oh, OK, I have that.
Quoted 11 lines
Quoted 11 lines
Quoted 10 lines
this compiles
and boots on my Intel/openSUSE 10.2 test machine but throws out the following messages I don't remember ever seeing with other kernels:- on console early during boot, also in SuSE's
/var/log/boot.msg:your system time is not correct:
Wed Jul 13 13:15:31 UTC 1910
setting system time to:
Tue Jul 24 00:00:00 UTC 2007
Quoted 4 lines
Quoted 1 line
What architecture?
i386. The machine is a Pentium D 940 which would be
x86_64capable, but I'm still running 32 bit kernels on it.
OK.
Quoted 5 lines
Quoted 3 lines
if
x86_64then perhaps something went wrong with the oldx86_64dynticks leftovers which were in rc3-mm1. I've just merged a shiny fresh new series so perhaps things there got fixed. Please retest next -mm.Will do that anyway.
It looks like you'll need to :(
Quoted 11 lines
Quoted 3 lines
Perhaps it would be helpful if you could do a
diff -u dmesg-2.6.23-rc3 dmesg-2.6.26-rc3-mm1I hope the attached helps. I created it by taking
/var/log/boot.msgof the two systems, removing everything after "Kernel logging stopped", editing out the printk timestamps and then running diff -u on them, so it should be more or less the dmesg diff. I did not edit out any of the differences because I'm lazy. (And also because I wasn't so sure what would or wouldn't be interesting for you.)
--- /tmp/bootmsg-2.6.23-rc3 2007-08-25 02:25:54.000000000 +0200
tmp/bootmsg-2.6.23-rc3-mm1 line 248
Quoted 10 lines
+++
/tmp/bootmsg-2.6.23-rc3-mm12007-08-25 02:26:08.000000000 +0200tmp/bootmsg-2.6.23-rc3-mm1 renamed from tmp/bootmsg-2.6.23-rc3 +3
-1@@ -1,10 +1,10 @@ <6>..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 -<6>checking TSC synchronization [CPU#0 -> CPU#1]: passed. +<6>checking TSC synchronization [CPU#0 -> CPU#1]: +<4>Measured 32 cycles TSC warp between CPUs, turning off TSC clock. +<4>Marking TSC unstable due to: check_tsc_sync_source failed.
looky here.
Quoted 6 lines
<6>Brought up 2 CPUs
<6>Booting paravirtualized kernel on bare hardware <6>NET: Registered protocol family 16
<6>ACPI: bus type pci registered
-<3>PCI: BIOS Bug: MCFG area atf0000000is not E820-reserved -<3>PCI: Not using MMCONFIG.
hm, I wonder if that's related.
Quoted 9 lines
<6>PCI: Using configuration type 1
<4>Setting up standard PCI resources
<7>ACPI: EC: Look up EC in DSDT
<6>ACPI: Interpreter enabled
<6>ACPI: (supports S0 S3)
<6>ACPI: Using IOAPIC for interrupt routing
+<5>PCI: MCFG configuration 0: base 4026531840 segment 0 buses 0 - 127 +<5>PCI: MCFG area atf0000000reserved in ACPI motherboard resources +<6>PCI: Using MMCONFIG
we're using mmconfig
tmp/bootmsg-2.6.23-rc3-mm1 line 296
Quoted 13 lines
<6>ACPI: PCI Root Bridge [PCI0] (0000:00)
+<7>PCI: Probing PCI hardware (bus 00)
<4>PCI quirk: region 0400-047f claimed by ICH6 ACPI/GPIO/TCO <4>PCI quirk: region 0500-053f claimed by ICH6 GPIO <6>PCI: Transparent bridge - 0000:00:1e.0tmp/bootmsg-2.6.23-rc3-mm1 renamed from tmp/bootmsg-2.6.23-rc3 +3
-1@@ -285,7 +291,9 @@ <6>NetLabel: protocols = UNLABELED CIPSOv4 <6>NetLabel: unlabeled traffic allowed by default <4>ACPI: RTC can wake from S4 -<6>Time: tsc clocksource has been installed. +<6>Time: hpet clocksource has been installed. +<6>Switched to high resolution mode on CPU 0 +<6>Switched to high resolution mode on CPU 1
No longer using tsc, using hpet instead. Slower.
tmp/bootmsg-2.6.23-rc3-mm1 line 402
Quoted 2 lines
tmp/bootmsg-2.6.23-rc3-mm1 renamed from tmp/bootmsg-2.6.23-rc3 +1
-1-<7>hpet_resources: 0xfed00000 is busy +<4>hpet_acpi_add: no address or irqs in _CRS
oh boy
tmp/bootmsg-2.6.23-rc3-mm1 line 427
Quoted 1 line
tmp/bootmsg-2.6.23-rc3-mm1 renamed from tmp/bootmsg-2.6.23-rc3 +1
-0+<4>thermal: Unknown symbol acpi_processor_set_thermal_limit
I think there are acpi fixes in Len's latest tree which will fix this.
tmp/bootmsg-2.6.23-rc3-mm1 line 525
Quoted 11 lines
tmp/bootmsg-2.6.23-rc3-mm1 renamed from tmp/bootmsg-2.6.23-rc3 +4
-2<6>Linux agpgart interface v0.102 +<6>rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0 +<4>rtc_cmos: probe of 00:03 failed with error -16 +<6>agpgart: suspend/resume problematic: resume with 3D/DRI active may lockup X.Org +<4>on some chipset/BIOS combos (see DEBUG_AGP_PM in intel-agp.c) <6>agpgart: Detected an Intel 965Q Chipset. <6>agpgart: Unknown page table size, assuming 512KB <6>agpgart: Detected 7676K stolen memory. <6>agpgart: AGP aperture is 256M @ 0x40000000 -<6>rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0 -<4>rtc_cmos: probe of 00:03 failed with error -16
I wonder if that was supposed to happen. It's also happening in 2.6.23-rc3 base.
I don't see anything there which would cause you to lose the clock setting, but there are obviously a few things going wrong in the time-management area here. Please explicity retest this stuff as the code evolves and kepp us informed of the problems.
Thanks.
Quoted 12 lines · Andrew Morton
Quoted 11 lines
<6>Linux agpgart interface v0.102
+<6>rtc_cmos 00:03: rtc core: registeredrtc_cmosas rtc0 +<4>rtc_cmos: probe of 00:03 failed with error -16
+<6>agpgart: suspend/resume problematic: resume with 3D/DRI active may lockup X.Org +<4>on some chipset/BIOS combos (seeDEBUG_AGP_PMinintel-agp.c)
<6>agpgart: Detected an Intel 965Q Chipset.
<6>agpgart: Unknown page table size, assuming 512KB
<6>agpgart: Detected 7676K stolen memory.
<6>agpgart: AGP aperture is 256M @0x40000000
-<6>rtc_cmos 00:03: rtc core: registeredrtc_cmosas rtc0 -<4>rtc_cmos: probe of 00:03 failed with error -16
Quoted 2 lines
I wonder if that was supposed to happen. It's also happening in 2.6.23-rc3 base.
EBUSY. I've seen this happen when you have both CONFIG_RTC and CONFIG_RTC_DRV_CMOS set.
Dave
Signature · 1 line
http://www.codemonkey.org.uk
Hello,
Quoted 14 lines · On Sat, 25 Aug 2007 00:28:09 -0400 Dave Jones <[email protected]> wrote:
Quoted 12 lines · Andrew Morton
Quoted 11 lines
<6>Linux agpgart interface v0.102
+<6>rtc_cmos 00:03: rtc core: registeredrtc_cmosas rtc0 +<4>rtc_cmos: probe of 00:03 failed with error -16 +<6>agpgart: suspend/resume problematic: resume with 3D/DRI active may lockup X.Org +<4>on some chipset/BIOS combos (seeDEBUG_AGP_PMinintel-agp.c) <6>agpgart: Detected an Intel 965Q Chipset.
<6>agpgart: Unknown page table size, assuming 512KB <6>agpgart: Detected 7676K stolen memory.
<6>agpgart: AGP aperture is 256M @0x40000000
-<6>rtc_cmos 00:03: rtc core: registeredrtc_cmosas rtc0 -<4>rtc_cmos: probe of 00:03 failed with error -16
Quoted 5 lines
Quoted 2 lines
I wonder if that was supposed to happen. It's also happening in 2.6.23-rc3 base.
EBUSY. I've seen this happen when you have both
CONFIG_RTCandCONFIG_RTC_DRV_CMOSset.
This one is becoming quite worth an entry in a FAQ, it pops up one every month ;)
There was a discussion about preventing both being set at the same time when configuring, but I don't remember how it ends...
Paul
Am 25.08.2007 09:55 schrieb Paul Rolland:
Quoted 11 lines
Quoted 8 lines · On Sat, 25 Aug 2007 00:28:09 -0400 Dave Jones <[email protected]> wrote:
Quoted 5 lines · Andrew Morton
Quoted 2 lines
-<6>rtc_cmos 00:03: rtc core: registered
rtc_cmosas rtc0 -<4>rtc_cmos: probe of 00:03 failed with error -16I wonder if that was supposed to happen. It's also happening in 2.6.23-rc3 base.
Quoted 7 lines
Quoted 2 lines
EBUSY. I've seen this happen when you have both
CONFIG_RTCandCONFIG_RTC_DRV_CMOSset.This one is becoming quite worth an entry in a FAQ, it pops up one every month ;)
There was a discussion about preventing both being set at the same time when configuring, but I don't remember how it ends...
I must have missed that discussion. I have:CONFIG_RTC=yCONFIG_RTC_DRV_CMOS=m
because both of these options claim in their help texts that you should select them if you want to access the PC RTC.
Signature · 4 lines
Tilman Schmidt E-Mail: [email protected] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
Clock trouble retest results with 2.6.23-rc4-mm1 (was: 2.6.23-rc3-mm1)
In reply to Andrew MortonAm 25.08.2007 05:30 schrieb Andrew Morton:
Quoted 8 lines · On Sat, 25 Aug 2007 02:47:59 +0200 Tilman Schmidt <[email protected]> wrote:
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
- on console early during boot, also in SuSE's
/var/log/boot.msg:your system time is not correct:
Wed Jul 13 13:15:31 UTC 1910
setting system time to:
Tue Jul 24 00:00:00 UTC 2007
With 2.6.23-rc4-mm1 this doesn't happen anymore, so whatever it was seems to be fixed.
Quoted 2 lines
Quoted 2 lines
tmp/bootmsg-2.6.23-rc3-mm1 renamed from tmp/bootmsg-2.6.23-rc3 +0
-0
[...]
Quoted 5 lines
Quoted 5 lines
<6>..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
-<6>checking TSC synchronization [CPU#0 -> CPU#1]: passed. +<6>checking TSC synchronization [CPU#0 -> CPU#1]:
+<4>Measured 32 cycles TSC warp between CPUs, turning off TSC clock. +<4>Marking TSC unstable due to:check_tsc_sync_sourcefailed.
This still happens identically with 2.6.23-rc4-mm1. Mainline kernels like my TSC, -mm kernels don't.
Quoted 4 lines
Quoted 2 lines
-<7>hpet_resources:
0xfed00000is busy
+<4>hpet_acpi_add: no address or irqs in_CRSoh boy
2.6.23-rc4-mm1 reverts to mainline behaviour here. (ie. "busy" instead of "no address or irqs") Dunno if that's good or bad.
Quoted 3 lines
Quoted 1 line
+<4>thermal: Unknown symbol
acpi_processor_set_thermal_limitI think there are acpi fixes in Len's latest tree which will fix this.
Gone in 2.6.23-rc4-mm1.
HTH
Tilman
Signature · 4 lines
Tilman Schmidt E-Mail: [email protected] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
X freezes kernel during exit [Re: 2.6.23-rc3-mm1]
In reply to Andrew MortonAndrew Morton napsal(a):
Quoted 1 line
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
Hi,
I've found a regression against 2.6.23-rc2-mm2. X server shutdown freezes (untainted) kernel hardly. Nothing on netconsole, X output follows:
X Window System Version 1.3.0
Release Date: 19 April 2007
X Protocol Version 11, Revision 0, Release 1.3
Build Operating System: Fedora Core 7 Red Hat, Inc.
Current Operating System: Linux bellona 2.6.23-rc3-mm1 #315 SMP Wed Aug 22 21:43:06 CEST 2007 i686
Build Date: 11 June 2007
Build ID: xorg-x11-server 1.3.0.0-9.fc7
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sun Aug 26 14:22:43 2007 (==) Using config file: "/etc/X11/xorg.conf"
(WW) RADEON: No matching Device section for instance (BusID PCI:1:0:1) found (**) RADEON(0): RADEONPreInit
(II) Module already built-in
(II) Module already built-in
(II) Module already built-in
(**) RADEON(0): RADEONScreenInit f0000000 0
(**) RADEON(0): Map: 0xf0000000, 0x04000000
(**) RADEON(0): RADEONSave
(**) RADEON(0): RADEONSaveMode(0x8240870)
(**) RADEON(0): Read: 0x0000000c 0x00030065 0x00000000
(**) RADEON(0): Read: rd=12, fd=101, pd=3
(**) RADEON(0): RADEONSaveMode returns 0x8240870
(**) RADEON(0): DRI New memory map param
(**) RADEON(0): RADEONInitMemoryMap() :
(**) RADEON(0): mem_size : 0x04000000 (**) RADEON(0): MC_FB_LOCATION : 0xf3fff000 (**) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 (**) RADEON(0): RADEONModeInit() 1280x1024 108.00 1280 1328 1440 1688 1024 1025 1028 1066 (24,32) +H +V 1280x1024 108.00 1280 1328 1440 1688 1024 1025 1028 1066 (24,32) +H +V
(**) RADEON(0): Pitch = 10485920 bytes (virtualX = 1280, displayWidth = 1280) (**) RADEON(0): dc=10800, of=21600, fd=96, pd=2
(**) RADEON(0): RADEONInit returns 0x8241220
(**) RADEON(0): RADEONRestoreMode()
(**) RADEON(0): RADEONRestoreMode(0x8241220)
(**) RADEON(0): RADEONRestoreMemMapRegisters() :
(**) RADEON(0): MC_FB_LOCATION : 0xf3fff000 (**) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 (**) RADEON(0): Map Changed ! Applying ... (**) RADEON(0): Map applied, resetting engine ...
(**) RADEON(0): Updating display base addresses...
(**) RADEON(0): Memory map updated.
(**) RADEON(0): Programming CRTC1, offset: 0x00000000 (**) RADEON(0): Wrote: 0x0000000c 0x00010060 0x00000000 (0x0000a400) (**) RADEON(0): Wrote: rd=12, fd=96, pd=1
(**) RADEON(0): GRPH_BUFFER_CNTL from 20205c5c to 20125c5c (**) RADEON(0): RADEONSaveScreen(0)
(**) RADEON(0): Setting up initial surfaces
(**) RADEON(0): Initializing fb layer
(**) RADEON(0): Setting up accel memmap
(**) RADEON(0): Initializing backing store
(**) RADEON(0): DRI Finishing init !
(**) RADEON(0): EngineRestore (32/32)
(**) RADEON(0): GRPH_BUFFER_CNTL from 20205c5c to 20125c5c (**) RADEON(0): Setting up final surfaces
(**) RADEON(0): Initializing Acceleration
(**) RADEON(0): EngineInit (32/32)
(**) RADEON(0): Pitch for acceleration = 160
(**) RADEON(0): EngineRestore (32/32)
(**) RADEON(0): Initializing DPMS
(**) RADEON(0): Initializing Cursor
(**) RADEON(0): Initializing color map
(**) RADEON(0): Initializing DGA
(**) RADEON(0): Initializing Xv
(**) RADEON(0): RADEONScreenInit finished
(**) RADEON(0): RADEONSaveScreen(2)
(**) RADEON(0): RADEONCloseScreen
(**) RADEON(0): RADEONDRIStop
(**) RADEON(0): EngineRestore (32/32)
(**) RADEON(0): RADEONDisplayPowerManagementSet(0,0x0) (**) RADEON(0): RADEONRestore
(**) RADEON(0): RADEONRestoreMode()
(**) RADEON(0): RADEONRestoreMode(0x8240870)
(**) RADEON(0): RADEONRestoreMemMapRegisters() :
(**) RADEON(0): MC_FB_LOCATION : 0x1fff0000 (**) RADEON(0): MC_AGP_LOCATION : 0x27ff2000 (**) RADEON(0): Map Changed ! Applying ... (**) RADEON(0): Map applied, resetting engine ...
(**) RADEON(0): Updating display base addresses...
(**) RADEON(0): Memory map updated.
(**) RADEON(0): Programming CRTC1, offset: 0x00000000 (**) RADEON(0): Wrote: 0x0000000c 0x00030065 0x00000000 (0x0000a400) (**) RADEON(0): Wrote: rd=12, fd=101, pd=3
(**) RADEON(0): Disposing accel...
(**) RADEON(0): Disposing cusor info
(**) RADEON(0): Disposing DGA
(**) RADEON(0): Unmapping memory
(**) RADEON(0): RADEONDRICloseScreen
the only difference is, that 2.6.23-rc2-mm2 writes further
FreeFontPath: FPE "/usr/share/X11/fonts/misc:unscaled" refcount is 2, should be 1; fixing.
and exits succesfully (note that these messages are taken on remote host, X runned remotely).
Both vesa and radeon + Option "NoAccel" "true" works obviously fine.
regards,
Signature · 2 lines
Jiri Slaby ([email protected]) Faculty of Informatics, Masaryk University
Re: X freezes kernel during exit [Re: 2.6.23-rc3-mm1]
Does this went through to your boxes? Any progress, clue, idea?
Jiri Slaby napsal(a):
Quoted 117 lines
Andrew Morton napsal(a):
Quoted 1 line
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
Hi,
I've found a regression against 2.6.23-rc2-mm2. X server shutdown freezes (untainted) kernel hardly. Nothing on netconsole, X output follows:
X Window System Version 1.3.0
Release Date: 19 April 2007
X Protocol Version 11, Revision 0, Release 1.3
Build Operating System: Fedora Core 7 Red Hat, Inc.
Current Operating System: Linux bellona 2.6.23-rc3-mm1 #315 SMP Wed Aug 22 21:43:06 CEST 2007 i686
Build Date: 11 June 2007
Build ID: xorg-x11-server 1.3.0.0-9.fc7
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sun Aug 26 14:22:43 2007 (==) Using config file: "/etc/X11/xorg.conf"
(WW) RADEON: No matching Device section for instance (BusID PCI:1:0:1) found (**) RADEON(0): RADEONPreInit
(II) Module already built-in
(II) Module already built-in
(II) Module already built-in
(**) RADEON(0): RADEONScreenInitf00000000
(**) RADEON(0): Map:0xf0000000,0x04000000
(**) RADEON(0): RADEONSave
(**) RADEON(0): RADEONSaveMode(0x8240870)
(**) RADEON(0): Read:0x0000000c0x000300650x00000000
(**) RADEON(0): Read: rd=12, fd=101, pd=3
(**) RADEON(0): RADEONSaveMode returns0x8240870
(**) RADEON(0): DRI New memory map param
(**) RADEON(0):RADEONInitMemoryMap():(**) RADEON(0): mem_size : 0x04000000 (**) RADEON(0): MC_FB_LOCATION : 0xf3fff000 (**) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 (**) RADEON(0): RADEONModeInit() 1280x1024 108.00 1280 1328 1440 1688 1024 1025 1028 1066 (24,32) +H +V 1280x1024 108.00 1280 1328 1440 1688 1024 1025 1028 1066 (24,32) +H +V(**) RADEON(0): Pitch = 10485920 bytes (virtualX = 1280, displayWidth = 1280) (**) RADEON(0): dc=10800, of=21600, fd=96, pd=2
(**) RADEON(0): RADEONInit returns0x8241220
(**) RADEON(0):RADEONRestoreMode()
(**) RADEON(0): RADEONRestoreMode(0x8241220)
(**) RADEON(0):RADEONRestoreMemMapRegisters():(**) RADEON(0): MC_FB_LOCATION : 0xf3fff000 (**) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 (**) RADEON(0): Map Changed ! Applying ... (**) RADEON(0): Map applied, resetting engine ...(**) RADEON(0): Updating display base addresses...
(**) RADEON(0): Memory map updated.
(**) RADEON(0): Programming CRTC1, offset:0x00000000(**) RADEON(0): Wrote:0x0000000c0x000100600x00000000(0x0000a400) (**) RADEON(0): Wrote: rd=12, fd=96, pd=1
(**) RADEON(0):GRPH_BUFFER_CNTLfrom20205c5cto20125c5c(**) RADEON(0): RADEONSaveScreen(0)
(**) RADEON(0): Setting up initial surfaces
(**) RADEON(0): Initializing fb layer
(**) RADEON(0): Setting up accel memmap
(**) RADEON(0): Initializing backing store
(**) RADEON(0): DRI Finishing init !
(**) RADEON(0): EngineRestore (32/32)
(**) RADEON(0):GRPH_BUFFER_CNTLfrom20205c5cto20125c5c(**) RADEON(0): Setting up final surfaces
(**) RADEON(0): Initializing Acceleration
(**) RADEON(0): EngineInit (32/32)
(**) RADEON(0): Pitch for acceleration = 160
(**) RADEON(0): EngineRestore (32/32)
(**) RADEON(0): Initializing DPMS
(**) RADEON(0): Initializing Cursor
(**) RADEON(0): Initializing color map
(**) RADEON(0): Initializing DGA
(**) RADEON(0): Initializing Xv
(**) RADEON(0): RADEONScreenInit finished
(**) RADEON(0): RADEONSaveScreen(2)
(**) RADEON(0): RADEONCloseScreen
(**) RADEON(0): RADEONDRIStop
(**) RADEON(0): EngineRestore (32/32)
(**) RADEON(0):RADEONDisplayPowerManagementSet(0,0x0)(**) RADEON(0): RADEONRestore
(**) RADEON(0):RADEONRestoreMode()
(**) RADEON(0): RADEONRestoreMode(0x8240870)
(**) RADEON(0):RADEONRestoreMemMapRegisters():(**) RADEON(0): MC_FB_LOCATION : 0x1fff0000 (**) RADEON(0): MC_AGP_LOCATION : 0x27ff2000 (**) RADEON(0): Map Changed ! Applying ... (**) RADEON(0): Map applied, resetting engine ...(**) RADEON(0): Updating display base addresses...
(**) RADEON(0): Memory map updated.
(**) RADEON(0): Programming CRTC1, offset:0x00000000(**) RADEON(0): Wrote:0x0000000c0x000300650x00000000(0x0000a400) (**) RADEON(0): Wrote: rd=12, fd=101, pd=3
(**) RADEON(0): Disposing accel...
(**) RADEON(0): Disposing cusor info
(**) RADEON(0): Disposing DGA
(**) RADEON(0): Unmapping memory
(**) RADEON(0): RADEONDRICloseScreenthe only difference is, that 2.6.23-rc2-mm2 writes further
FreeFontPath: FPE "/usr/share/X11/fonts/misc:unscaled" refcount is 2, should be 1; fixing.
and exits succesfully (note that these messages are taken on remote host, X runned remotely).
Both vesa and radeon + Option "NoAccel" "true" works obviously fine.
regards,
Signature · 2 lines
Jiri Slaby ([email protected]) Faculty of Informatics, Masaryk University
Re: X freezes kernel during exit [Re: 2.6.23-rc3-mm1]
Quoted 117 lines · Jiri Slaby
Does this went through to your boxes? Any progress, clue, idea?
Jiri Slaby napsal(a):
Quoted 114 lines
Andrew Morton napsal(a):
Quoted 1 line
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
Hi,
I've found a regression against 2.6.23-rc2-mm2. X server shutdown freezes (untainted) kernel hardly. Nothing on netconsole, X output follows:
X Window System Version 1.3.0
Release Date: 19 April 2007
X Protocol Version 11, Revision 0, Release 1.3
Build Operating System: Fedora Core 7 Red Hat, Inc.
Current Operating System: Linux bellona 2.6.23-rc3-mm1 #315 SMP Wed Aug 22 21:43:06 CEST 2007 i686
Build Date: 11 June 2007
Build ID: xorg-x11-server 1.3.0.0-9.fc7
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sun Aug 26 14:22:43 2007 (==) Using config file: "/etc/X11/xorg.conf"
(WW) RADEON: No matching Device section for instance (BusID PCI:1:0:1) found (**) RADEON(0): RADEONPreInit
(II) Module already built-in
(II) Module already built-in
(II) Module already built-in
(**) RADEON(0): RADEONScreenInitf00000000
(**) RADEON(0): Map:0xf0000000,0x04000000
(**) RADEON(0): RADEONSave
(**) RADEON(0): RADEONSaveMode(0x8240870)
(**) RADEON(0): Read:0x0000000c0x000300650x00000000
(**) RADEON(0): Read: rd=12, fd=101, pd=3
(**) RADEON(0): RADEONSaveMode returns0x8240870
(**) RADEON(0): DRI New memory map param
(**) RADEON(0):RADEONInitMemoryMap():(**) RADEON(0): mem_size : 0x04000000 (**) RADEON(0): MC_FB_LOCATION : 0xf3fff000 (**) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 (**) RADEON(0): RADEONModeInit() 1280x1024 108.00 1280 1328 1440 1688 1024 1025 1028 1066 (24,32) +H +V 1280x1024 108.00 1280 1328 1440 1688 1024 1025 1028 1066 (24,32) +H +V(**) RADEON(0): Pitch = 10485920 bytes (virtualX = 1280, displayWidth = 1280) (**) RADEON(0): dc=10800, of=21600, fd=96, pd=2
(**) RADEON(0): RADEONInit returns0x8241220
(**) RADEON(0):RADEONRestoreMode()
(**) RADEON(0): RADEONRestoreMode(0x8241220)
(**) RADEON(0):RADEONRestoreMemMapRegisters():(**) RADEON(0): MC_FB_LOCATION : 0xf3fff000 (**) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 (**) RADEON(0): Map Changed ! Applying ... (**) RADEON(0): Map applied, resetting engine ...(**) RADEON(0): Updating display base addresses...
(**) RADEON(0): Memory map updated.
(**) RADEON(0): Programming CRTC1, offset:0x00000000(**) RADEON(0): Wrote:0x0000000c0x000100600x00000000(0x0000a400) (**) RADEON(0): Wrote: rd=12, fd=96, pd=1
(**) RADEON(0):GRPH_BUFFER_CNTLfrom20205c5cto20125c5c(**) RADEON(0): RADEONSaveScreen(0)
(**) RADEON(0): Setting up initial surfaces
(**) RADEON(0): Initializing fb layer
(**) RADEON(0): Setting up accel memmap
(**) RADEON(0): Initializing backing store
(**) RADEON(0): DRI Finishing init !
(**) RADEON(0): EngineRestore (32/32)
(**) RADEON(0):GRPH_BUFFER_CNTLfrom20205c5cto20125c5c(**) RADEON(0): Setting up final surfaces
(**) RADEON(0): Initializing Acceleration
(**) RADEON(0): EngineInit (32/32)
(**) RADEON(0): Pitch for acceleration = 160
(**) RADEON(0): EngineRestore (32/32)
(**) RADEON(0): Initializing DPMS
(**) RADEON(0): Initializing Cursor
(**) RADEON(0): Initializing color map
(**) RADEON(0): Initializing DGA
(**) RADEON(0): Initializing Xv
(**) RADEON(0): RADEONScreenInit finished
(**) RADEON(0): RADEONSaveScreen(2)
(**) RADEON(0): RADEONCloseScreen
(**) RADEON(0): RADEONDRIStop
(**) RADEON(0): EngineRestore (32/32)
(**) RADEON(0):RADEONDisplayPowerManagementSet(0,0x0)(**) RADEON(0): RADEONRestore
(**) RADEON(0):RADEONRestoreMode()
(**) RADEON(0): RADEONRestoreMode(0x8240870)
(**) RADEON(0):RADEONRestoreMemMapRegisters():(**) RADEON(0): MC_FB_LOCATION : 0x1fff0000 (**) RADEON(0): MC_AGP_LOCATION : 0x27ff2000 (**) RADEON(0): Map Changed ! Applying ... (**) RADEON(0): Map applied, resetting engine ...(**) RADEON(0): Updating display base addresses...
(**) RADEON(0): Memory map updated.
(**) RADEON(0): Programming CRTC1, offset:0x00000000(**) RADEON(0): Wrote:0x0000000c0x000300650x00000000(0x0000a400) (**) RADEON(0): Wrote: rd=12, fd=101, pd=3
(**) RADEON(0): Disposing accel...
(**) RADEON(0): Disposing cusor info
(**) RADEON(0): Disposing DGA
(**) RADEON(0): Unmapping memory
(**) RADEON(0): RADEONDRICloseScreenthe only difference is, that 2.6.23-rc2-mm2 writes further
FreeFontPath: FPE "/usr/share/X11/fonts/misc:unscaled" refcount is 2, should be 1; fixing.
and exits succesfully (note that these messages are taken on remote host, X runned remotely).
Both vesa and radeon + Option "NoAccel" "true" works obviously fine.
Also intel on integrated i915 causes this (NoAccell has no effect in this case). Note that also 2.6.23-rc4-mm1 is affected by this behaviour.
I have a trace for you:
http://www.fi.muni.cz/~xslaby/sklad/panics/x-freeze.png
(this is the only what I'm able to grab so far)
regards,
Signature · 2 lines
Jiri Slaby ([email protected]) Faculty of Informatics, Masaryk University
Re: X freezes kernel during exit [Re: 2.6.23-rc3-mm1]
Quoted 117 lines · On Sun, 09 Sep 2007 13:44:56 +0200 Jiri Slaby <[email protected]> wrote:
Quoted 116 lines · Jiri Slaby
Does this went through to your boxes? Any progress, clue, idea?
Jiri Slaby napsal(a):
Quoted 113 lines
Andrew Morton napsal(a):
Quoted 1 line
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
Hi,
I've found a regression against 2.6.23-rc2-mm2. X server shutdown freezes (untainted) kernel hardly. Nothing on netconsole, X output follows:
X Window System Version 1.3.0
Release Date: 19 April 2007
X Protocol Version 11, Revision 0, Release 1.3
Build Operating System: Fedora Core 7 Red Hat, Inc.
Current Operating System: Linux bellona 2.6.23-rc3-mm1 #315 SMP Wed Aug 22 21:43:06 CEST 2007 i686
Build Date: 11 June 2007
Build ID: xorg-x11-server 1.3.0.0-9.fc7
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sun Aug 26 14:22:43 2007 (==) Using config file: "/etc/X11/xorg.conf"
(WW) RADEON: No matching Device section for instance (BusID PCI:1:0:1) found (**) RADEON(0): RADEONPreInit
(II) Module already built-in
(II) Module already built-in
(II) Module already built-in
(**) RADEON(0): RADEONScreenInitf00000000
(**) RADEON(0): Map:0xf0000000,0x04000000
(**) RADEON(0): RADEONSave
(**) RADEON(0): RADEONSaveMode(0x8240870)
(**) RADEON(0): Read:0x0000000c0x000300650x00000000
(**) RADEON(0): Read: rd=12, fd=101, pd=3
(**) RADEON(0): RADEONSaveMode returns0x8240870
(**) RADEON(0): DRI New memory map param
(**) RADEON(0):RADEONInitMemoryMap():(**) RADEON(0): mem_size : 0x04000000 (**) RADEON(0): MC_FB_LOCATION : 0xf3fff000 (**) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 (**) RADEON(0): RADEONModeInit() 1280x1024 108.00 1280 1328 1440 1688 1024 1025 1028 1066 (24,32) +H +V 1280x1024 108.00 1280 1328 1440 1688 1024 1025 1028 1066 (24,32) +H +V(**) RADEON(0): Pitch = 10485920 bytes (virtualX = 1280, displayWidth = 1280) (**) RADEON(0): dc=10800, of=21600, fd=96, pd=2
(**) RADEON(0): RADEONInit returns0x8241220
(**) RADEON(0):RADEONRestoreMode()
(**) RADEON(0): RADEONRestoreMode(0x8241220)
(**) RADEON(0):RADEONRestoreMemMapRegisters():(**) RADEON(0): MC_FB_LOCATION : 0xf3fff000 (**) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 (**) RADEON(0): Map Changed ! Applying ... (**) RADEON(0): Map applied, resetting engine ...(**) RADEON(0): Updating display base addresses...
(**) RADEON(0): Memory map updated.
(**) RADEON(0): Programming CRTC1, offset:0x00000000(**) RADEON(0): Wrote:0x0000000c0x000100600x00000000(0x0000a400) (**) RADEON(0): Wrote: rd=12, fd=96, pd=1
(**) RADEON(0):GRPH_BUFFER_CNTLfrom20205c5cto20125c5c(**) RADEON(0): RADEONSaveScreen(0)
(**) RADEON(0): Setting up initial surfaces
(**) RADEON(0): Initializing fb layer
(**) RADEON(0): Setting up accel memmap
(**) RADEON(0): Initializing backing store
(**) RADEON(0): DRI Finishing init !
(**) RADEON(0): EngineRestore (32/32)
(**) RADEON(0):GRPH_BUFFER_CNTLfrom20205c5cto20125c5c(**) RADEON(0): Setting up final surfaces
(**) RADEON(0): Initializing Acceleration
(**) RADEON(0): EngineInit (32/32)
(**) RADEON(0): Pitch for acceleration = 160
(**) RADEON(0): EngineRestore (32/32)
(**) RADEON(0): Initializing DPMS
(**) RADEON(0): Initializing Cursor
(**) RADEON(0): Initializing color map
(**) RADEON(0): Initializing DGA
(**) RADEON(0): Initializing Xv
(**) RADEON(0): RADEONScreenInit finished
(**) RADEON(0): RADEONSaveScreen(2)
(**) RADEON(0): RADEONCloseScreen
(**) RADEON(0): RADEONDRIStop
(**) RADEON(0): EngineRestore (32/32)
(**) RADEON(0):RADEONDisplayPowerManagementSet(0,0x0)(**) RADEON(0): RADEONRestore
(**) RADEON(0):RADEONRestoreMode()
(**) RADEON(0): RADEONRestoreMode(0x8240870)
(**) RADEON(0):RADEONRestoreMemMapRegisters():(**) RADEON(0): MC_FB_LOCATION : 0x1fff0000 (**) RADEON(0): MC_AGP_LOCATION : 0x27ff2000 (**) RADEON(0): Map Changed ! Applying ... (**) RADEON(0): Map applied, resetting engine ...(**) RADEON(0): Updating display base addresses...
(**) RADEON(0): Memory map updated.
(**) RADEON(0): Programming CRTC1, offset:0x00000000(**) RADEON(0): Wrote:0x0000000c0x000300650x00000000(0x0000a400) (**) RADEON(0): Wrote: rd=12, fd=101, pd=3
(**) RADEON(0): Disposing accel...
(**) RADEON(0): Disposing cusor info
(**) RADEON(0): Disposing DGA
(**) RADEON(0): Unmapping memory
(**) RADEON(0): RADEONDRICloseScreenthe only difference is, that 2.6.23-rc2-mm2 writes further
FreeFontPath: FPE "/usr/share/X11/fonts/misc:unscaled" refcount is 2, should be 1; fixing.
and exits succesfully (note that these messages are taken on remote host, X runned remotely).
Quoted 8 lines
Quoted 1 line
Quoted 1 line
Both vesa and radeon + Option "NoAccel" "true" works obviously fine.
Also intel on integrated i915 causes this (NoAccell has no effect in this case). Note that also 2.6.23-rc4-mm1 is affected by this behaviour.
I have a trace for you:
http://www.fi.muni.cz/~xslaby/sklad/panics/x-freeze.png
(this is the only what I'm able to grab so far)
afacit everything on that call trace is good. I guess it's possible that one of the higher-level loops has gone infinite (eg, the one in agp_remove_controller()).
Are you able to get netconsole working, and run sysrq-P and sysrq-T ten or so times, see if it's always stuck in the same place on the same CPU?
Re: X freezes kernel during exit [Re: 2.6.23-rc3-mm1]
Removed [email protected] (dead e-mail)
Quoted 5 lines · Andrew Morton
Quoted 3 lines · On Sun, 09 Sep 2007 13:44:56 +0200 Jiri Slaby <[email protected]> wrote:
Quoted 2 lines · Jiri Slaby
Does this went through to your boxes? Any progress, clue, idea?
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Jiri Slaby napsal(a):
Quoted 6 lines
Andrew Morton napsal(a):
Quoted 1 line
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
Hi,
I've found a regression against 2.6.23-rc2-mm2. X server shutdown freezes (untainted) kernel hardly. Nothing on netconsole, X output follows:
--------------------------------^^^
sorry, both netconsole and my usb devices (including my keyboard -- no numlock led switch) are dead. The trace I've taken appears on the screen after a while.
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
X Window System Version 1.3.0
Release Date: 19 April 2007
X Protocol Version 11, Revision 0, Release 1.3
Build Operating System: Fedora Core 7 Red Hat, Inc.
Current Operating System: Linux bellona 2.6.23-rc3-mm1 #315 SMP Wed Aug 22
[...]
Quoted 20 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
(**) RADEON(0): RADEONDRICloseScreen
the only difference is, that 2.6.23-rc2-mm2 writes further
FreeFontPath: FPE "/usr/share/X11/fonts/misc:unscaled" refcount is 2, should be 1; fixing.
and exits succesfully (note that these messages are taken on remote host, X runned remotely).
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Both vesa and radeon + Option "NoAccel" "true" works obviously fine.
Also intel on integrated i915 causes this (NoAccell has no effect in this case). Note that also 2.6.23-rc4-mm1 is affected by this behaviour.
I have a trace for you:
http://www.fi.muni.cz/~xslaby/sklad/panics/x-freeze.png
(this is the only what I'm able to grab so far)
Quoted 3 lines
afacit everything on that call trace is good. I guess it's possible that one of the higher-level loops has gone infinite (eg, the one in
agp_remove_controller()).
There is no loop in this function. Anyway, going to track this whole issue down. Hold on.
Quoted 3 lines
Are you able to get netconsole working, and run sysrq-P and sysrq-T ten or so times, see if it's always stuck in the same place on the same CPU?
thanks so far,
Signature · 2 lines
Jiri Slaby ([email protected]) Faculty of Informatics, Masaryk University
Re: X freezes kernel during exit [Re: 2.6.23-rc3-mm1]
In reply to Andrew MortonQuoted 127 lines · Andrew Morton
Quoted 117 lines · On Sun, 09 Sep 2007 13:44:56 +0200 Jiri Slaby <[email protected]> wrote:
Quoted 116 lines · Jiri Slaby
Does this went through to your boxes? Any progress, clue, idea?
Jiri Slaby napsal(a):
Quoted 113 lines
Andrew Morton napsal(a):
Quoted 1 line
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
Hi,
I've found a regression against 2.6.23-rc2-mm2. X server shutdown freezes (untainted) kernel hardly. Nothing on netconsole, X output follows:
X Window System Version 1.3.0
Release Date: 19 April 2007
X Protocol Version 11, Revision 0, Release 1.3
Build Operating System: Fedora Core 7 Red Hat, Inc.
Current Operating System: Linux bellona 2.6.23-rc3-mm1 #315 SMP Wed Aug 22 21:43:06 CEST 2007 i686
Build Date: 11 June 2007
Build ID: xorg-x11-server 1.3.0.0-9.fc7
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sun Aug 26 14:22:43 2007 (==) Using config file: "/etc/X11/xorg.conf"
(WW) RADEON: No matching Device section for instance (BusID PCI:1:0:1) found (**) RADEON(0): RADEONPreInit
(II) Module already built-in
(II) Module already built-in
(II) Module already built-in
(**) RADEON(0): RADEONScreenInitf00000000
(**) RADEON(0): Map:0xf0000000,0x04000000
(**) RADEON(0): RADEONSave
(**) RADEON(0): RADEONSaveMode(0x8240870)
(**) RADEON(0): Read:0x0000000c0x000300650x00000000
(**) RADEON(0): Read: rd=12, fd=101, pd=3
(**) RADEON(0): RADEONSaveMode returns0x8240870
(**) RADEON(0): DRI New memory map param
(**) RADEON(0):RADEONInitMemoryMap():(**) RADEON(0): mem_size : 0x04000000 (**) RADEON(0): MC_FB_LOCATION : 0xf3fff000 (**) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 (**) RADEON(0): RADEONModeInit() 1280x1024 108.00 1280 1328 1440 1688 1024 1025 1028 1066 (24,32) +H +V 1280x1024 108.00 1280 1328 1440 1688 1024 1025 1028 1066 (24,32) +H +V(**) RADEON(0): Pitch = 10485920 bytes (virtualX = 1280, displayWidth = 1280) (**) RADEON(0): dc=10800, of=21600, fd=96, pd=2
(**) RADEON(0): RADEONInit returns0x8241220
(**) RADEON(0):RADEONRestoreMode()
(**) RADEON(0): RADEONRestoreMode(0x8241220)
(**) RADEON(0):RADEONRestoreMemMapRegisters():(**) RADEON(0): MC_FB_LOCATION : 0xf3fff000 (**) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 (**) RADEON(0): Map Changed ! Applying ... (**) RADEON(0): Map applied, resetting engine ...(**) RADEON(0): Updating display base addresses...
(**) RADEON(0): Memory map updated.
(**) RADEON(0): Programming CRTC1, offset:0x00000000(**) RADEON(0): Wrote:0x0000000c0x000100600x00000000(0x0000a400) (**) RADEON(0): Wrote: rd=12, fd=96, pd=1
(**) RADEON(0):GRPH_BUFFER_CNTLfrom20205c5cto20125c5c(**) RADEON(0): RADEONSaveScreen(0)
(**) RADEON(0): Setting up initial surfaces
(**) RADEON(0): Initializing fb layer
(**) RADEON(0): Setting up accel memmap
(**) RADEON(0): Initializing backing store
(**) RADEON(0): DRI Finishing init !
(**) RADEON(0): EngineRestore (32/32)
(**) RADEON(0):GRPH_BUFFER_CNTLfrom20205c5cto20125c5c(**) RADEON(0): Setting up final surfaces
(**) RADEON(0): Initializing Acceleration
(**) RADEON(0): EngineInit (32/32)
(**) RADEON(0): Pitch for acceleration = 160
(**) RADEON(0): EngineRestore (32/32)
(**) RADEON(0): Initializing DPMS
(**) RADEON(0): Initializing Cursor
(**) RADEON(0): Initializing color map
(**) RADEON(0): Initializing DGA
(**) RADEON(0): Initializing Xv
(**) RADEON(0): RADEONScreenInit finished
(**) RADEON(0): RADEONSaveScreen(2)
(**) RADEON(0): RADEONCloseScreen
(**) RADEON(0): RADEONDRIStop
(**) RADEON(0): EngineRestore (32/32)
(**) RADEON(0):RADEONDisplayPowerManagementSet(0,0x0)(**) RADEON(0): RADEONRestore
(**) RADEON(0):RADEONRestoreMode()
(**) RADEON(0): RADEONRestoreMode(0x8240870)
(**) RADEON(0):RADEONRestoreMemMapRegisters():(**) RADEON(0): MC_FB_LOCATION : 0x1fff0000 (**) RADEON(0): MC_AGP_LOCATION : 0x27ff2000 (**) RADEON(0): Map Changed ! Applying ... (**) RADEON(0): Map applied, resetting engine ...(**) RADEON(0): Updating display base addresses...
(**) RADEON(0): Memory map updated.
(**) RADEON(0): Programming CRTC1, offset:0x00000000(**) RADEON(0): Wrote:0x0000000c0x000300650x00000000(0x0000a400) (**) RADEON(0): Wrote: rd=12, fd=101, pd=3
(**) RADEON(0): Disposing accel...
(**) RADEON(0): Disposing cusor info
(**) RADEON(0): Disposing DGA
(**) RADEON(0): Unmapping memory
(**) RADEON(0): RADEONDRICloseScreenthe only difference is, that 2.6.23-rc2-mm2 writes further
FreeFontPath: FPE "/usr/share/X11/fonts/misc:unscaled" refcount is 2, should be 1; fixing.
and exits succesfully (note that these messages are taken on remote host, X runned remotely).
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Both vesa and radeon + Option "NoAccel" "true" works obviously fine.
Also intel on integrated i915 causes this (NoAccell has no effect in this case). Note that also 2.6.23-rc4-mm1 is affected by this behaviour.
I have a trace for you:
http://www.fi.muni.cz/~xslaby/sklad/panics/x-freeze.png
(this is the only what I'm able to grab so far)
Quoted 7 lines
afacit everything on that call trace is good. I guess it's possible that one of the higher-level loops has gone infinite (eg, the one in
agp_remove_controller()).Are you able to get netconsole working, and run sysrq-P and sysrq-T ten or so times, see if it's always stuck in the same place on the same CPU?
Hm, I suspect Andi's x86_64-mm-cpa-clflush.patch or something like that. It loops in flush_kernel_map in list_for_each_entry on the first CPU. The a->l list is somehow corrupted I guess.
regards,
Signature · 2 lines
Jiri Slaby ([email protected]) Faculty of Informatics, Masaryk University
Re: X freezes kernel during exit [Re: 2.6.23-rc3-mm1]
Quoted 3 lines
Hm, I suspect Andi's x86_64-mm-cpa-clflush.patch or something like that. It loops in
flush_kernel_mapinlist_for_each_entryon the first CPU. Thea->llist is somehow corrupted I guess.
Does it still happen with the latest version
ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/cpa-clflush
?
(you might need to replace the other cpa-* patches too because they depend on each other)
-Andi
Re: X freezes kernel during exit [Re: 2.6.23-rc3-mm1]
Quoted 5 lines · Andi Kleen
Quoted 3 lines
Hm, I suspect Andi's x86_64-mm-cpa-clflush.patch or something like that. It loops in
flush_kernel_mapinlist_for_each_entryon the first CPU. Thea->llist is somehow corrupted I guess.Does it still happen with the latest version
I think so :)
$ diff -u x86_64-mm-cpa-clflush.patch cpa-clflush |wc -l 0
Quoted 6 lines
ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/cpa-clflush
?
(you might need to replace the other cpa-* patches too because they depend on each other)
And are there any changes against the -rc4-mm1 in those patches?
BTW it is reproducible for me on two different machines (i386-x86_64, radeon-intel), don't you have the problem too?
regards,
Signature · 2 lines
Jiri Slaby ([email protected]) Faculty of Informatics, Masaryk University
Re: X freezes kernel during exit [Re: 2.6.23-rc3-mm1]
Quoted 2 lines · Jiri Slaby
BTW it is reproducible for me on two different machines (i386-x86_64, radeon-intel), don't you have the problem too?
No problems here with a radeon, no.
Does your CPU have clflush or not in /proc/cpuinfo?
-Andi
Re: X freezes kernel during exit [Re: 2.6.23-rc3-mm1]
Quoted 7 lines · Andi Kleen
Quoted 2 lines · Jiri Slaby
BTW it is reproducible for me on two different machines (i386-x86_64, radeon-intel), don't you have the problem too?
No problems here with a radeon, no.
Does your CPU have clflush or not in
/proc/cpuinfo?
yes:
processor : 0vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz
stepping : 11
cpu MHz : 2992.543
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fpu : yesfpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 5991.99
clflush size : 64cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz
stepping : 11
cpu MHz : 2992.543
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fpu : yesfpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 5985.42
clflush size : 64cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
Signature · 2 lines
Jiri Slaby ([email protected]) Faculty of Informatics, Masaryk University
Re: X freezes kernel during exit [Re: 2.6.23-rc3-mm1]
In reply to Andi KleenQuoted 7 lines · Andi Kleen
Quoted 2 lines · Jiri Slaby
BTW it is reproducible for me on two different machines (i386-x86_64, radeon-intel), don't you have the problem too?
No problems here with a radeon, no.
Does your CPU have clflush or not in
/proc/cpuinfo?
BTW this is how my flush_kernel_map looks like:
static void flush_kernel_map(void *arg)
{
struct flush_arg *a = (struct flush_arg *)arg;
struct page *pg;
unsigned int xx = 0;
/* When clflush is available use it because it is
much cheaper than WBINVD. */
printk("%s: 1\n", __func__);
if (a->full_flush || !cpu_has_clflush)
asm volatile("wbinvd" ::: "memory");
else list_for_each_entry(pg, &a->l, lru) {
printk("%s: %10u 1a\n", __func__, xx++);
if (PageFlush(pg))
clflush_cache_range(page_address(pg), PAGE_SIZE);
}
printk("%s: 2\n", __func__);
__flush_tlb_all();
printk("%s: 3\n", __func__);
}It outputs 1a in the infinite loop with incrementing xx. But only in this case, some global_flush_tlb are OK. e.g.:
Sep 10 01:39:19 localhost kernel: agpgart: Detected an Intel G33 Chipset. Sep 10 01:39:19 localhost kernel: global_flush_tlb: 1 Sep 10 01:39:19 localhost kernel: flush_kernel_map: 1 Sep 10 01:39:19 localhost kernel: flush_kernel_map: 0 1a Sep 10 01:39:19 localhost kernel: flush_kernel_map: 1 1a Sep 10 01:39:19 localhost kernel: flush_kernel_map: 2 Sep 10 01:39:19 localhost kernel: flush_kernel_map: 3 Sep 10 01:39:19 localhost kernel: flush_kernel_map: 1 Sep 10 01:39:19 localhost kernel: flush_kernel_map: 0 1a Sep 10 01:39:19 localhost kernel: flush_kernel_map: 1 1a Sep 10 01:39:19 localhost kernel: flush_kernel_map: 2 Sep 10 01:39:19 localhost kernel: flush_kernel_map: 3 Sep 10 01:39:19 localhost kernel: global_flush_tlb: 2 Sep 10 01:39:19 localhost kernel: global_flush_tlb: 3 Sep 10 01:39:19 localhost kernel: agpgart: Detected 6140K stolen memory.
It seems, that the list is broken only on X shutdown. How can be deferred-pages list inited in some bad manner, when list_replace_init is called on it? Weird.
Signature · 2 lines
Jiri Slaby ([email protected]) Faculty of Informatics, Masaryk University
Re: X freezes kernel during exit [Re: 2.6.23-rc3-mm1]
Quoted 10 lines · Jiri Slaby
Quoted 7 lines · Andi Kleen
Quoted 2 lines · Jiri Slaby
BTW it is reproducible for me on two different machines (i386-x86_64, radeon-intel), don't you have the problem too?
No problems here with a radeon, no.
Does your CPU have clflush or not in
/proc/cpuinfo?BTW this is how my
flush_kernel_maplooks like:
Can you stick a printk into change_page_attr to log in which order it changes pages (including their addresses and the pgattr)?
-Andi
Re: X freezes kernel during exit [Re: 2.6.23-rc3-mm1]
Quoted 5 lines · Andi Kleen
Quoted 4 lines · Jiri Slaby
Quoted 3 lines · Andi Kleen
Quoted 2 lines · Jiri Slaby
BTW it is reproducible for me on two different machines (i386-x86_64, radeon-intel), don't you have the problem too?
Quoted 7 lines
Quoted 4 lines
Quoted 3 lines
No problems here with a radeon, no.
Does your CPU have clflush or not in
/proc/cpuinfo?BTW this is how my
flush_kernel_maplooks like:Can you stick a printk into
change_page_attrto log in which order it changes pages (including their addresses and the pgattr)?
printk("%s: %p %p %.16lx %d\n", __func__, page, page_address(page), pgprot_val(prot), numpages);
http://www.fi.muni.cz/~xslaby/sklad/panics/x-freeze_chpa.png
What other info needed?
Signature · 2 lines
Jiri Slaby ([email protected]) Faculty of Informatics, Masaryk University
Re: X freezes kernel during exit [Re: 2.6.23-rc3-mm1]
Quoted 2 lines
What other info needed?
I'm seeing this on my 965gm chipset with Andi's clflush patches on x86 32-bit, it looks like an interaction with the agp code which does a big bunch of change page attr to allocate the AGP aperture backed memory..
I think the code might have worked in a previous iteration on my 64-bit 965G machine at home but I'm on the road and won't be back anytime soon..
I'll see what I can figure out from my laptop...
Dave.
Re: X freezes kernel during exit [Re: 2.6.23-rc3-mm1]
In reply to Jiri SlabyQuoted 49 lines · Jiri Slaby
Quoted 6 lines · Andi Kleen
Quoted 2 lines · Jiri Slaby
BTW it is reproducible for me on two different machines (i386-x86_64, radeon-intel), don't you have the problem too?
No problems here with a radeon, no.
Does your CPU have clflush or not in
/proc/cpuinfo?BTW this is how my
flush_kernel_maplooks like:static void
flush_kernel_map(void *arg){ struct flush_arg *a = (struct flush_arg *)arg; struct page *pg; unsigned int xx = 0; /* When clflush is available use it because it is much cheaper than WBINVD. */ printk("%s: 1\n", __func__); if (a->full_flush || !cpu_has_clflush) asm volatile("wbinvd" ::: "memory"); else list_for_each_entry(pg, &a->l, lru) { printk("%s: %10u 1a\n", __func__, xx++); if (PageFlush(pg)) clflush_cache_range(page_address(pg), PAGE_SIZE); } printk("%s: 2\n", __func__); __flush_tlb_all(); printk("%s: 3\n", __func__); }It outputs 1a in the infinite loop with incrementing xx. But only in this case, some
global_flush_tlbare OK. e.g.:Sep 10 01:39:19 localhost kernel: agpgart: Detected an Intel G33 Chipset. Sep 10 01:39:19 localhost kernel: global_flush_tlb: 1 Sep 10 01:39:19 localhost kernel: flush_kernel_map: 1 Sep 10 01:39:19 localhost kernel: flush_kernel_map: 0 1a Sep 10 01:39:19 localhost kernel: flush_kernel_map: 1 1a Sep 10 01:39:19 localhost kernel: flush_kernel_map: 2 Sep 10 01:39:19 localhost kernel: flush_kernel_map: 3 Sep 10 01:39:19 localhost kernel: flush_kernel_map: 1 Sep 10 01:39:19 localhost kernel: flush_kernel_map: 0 1a Sep 10 01:39:19 localhost kernel: flush_kernel_map: 1 1a Sep 10 01:39:19 localhost kernel: flush_kernel_map: 2 Sep 10 01:39:19 localhost kernel: flush_kernel_map: 3 Sep 10 01:39:19 localhost kernel: global_flush_tlb: 2 Sep 10 01:39:19 localhost kernel: global_flush_tlb: 3 Sep 10 01:39:19 localhost kernel: agpgart: Detected 6140K stolen memory.
Quoted 2 lines
It seems, that the list is broken only on X shutdown. How can be deferred-pages list inited in some bad manner, when
list_replace_initis called on it? Weird.
Ok, here comes a BUG with trace:
set status page addr 0x00033000list_add corruption. next->prev should be prev (ffffffff8068ae70), but was ffffffff80697a50. (next=ffff81000117fbd0).
------------[ cut here ]------------ kernel BUG at /home/l/latest/xxx/lib/list_debug.c:27! invalid opcode: 0000 [1] SMP last sysfs file: /devices/pci0000:00/0000:00:02.0/enable CPU 0 Modules linked in: ipv6 floppy sr_mod rtc_cmos rtc_core cdrom ehci_hcd rtc_lib usbhid Pid: 1639, comm: X Not tainted 2.6.23-rc4-mm1_64 #23 RIP: 0010:[<ffffffff80332f49>] [<ffffffff80332f49>] __list_add+0x39/0x60 RSP: 0018:ffff81000547bd48 EFLAGS: 00010296 RAX: 0000000000000079 RBX: ffff81000117a380 RCX: ffffffff8068b450 RDX: ffff81000317d6a0 RSI: 0000000000000001 RDI: ffffffff8068b420 RBP: ffff81000547bd48 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000006da2 R13: ffff810006c10d10 R14: ffff810006da2000 R15: 8000000000000163 FS: 00007f7a05258710(0000) GS:ffffffff806d1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000a33040 CR3: 0000000004a43000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process X (pid: 1639, threadinfo ffff81000547a000, task ffff81000317d6a0) Stack: ffff81000547bd58 ffffffff80332f7c ffff81000547bdc8 ffffffff80225c56 ffffffff80225cb5 8000000000000163 ffffffff806830e8 ffffffff806830a0 ffffffff806830a0 ffff810006da2000 ffff81000547bda8 0000000000006da2 Call Trace: [<ffffffff80332f7c>] list_add+0xc/0x10 [<ffffffff80225c56>] __change_page_attr+0x376/0x390 [<ffffffff80225cb5>] change_page_attr_addr+0x45/0x140 [<ffffffff80225d16>] change_page_attr_addr+0xa6/0x140 [<ffffffff80225de3>] change_page_attr+0x33/0x40 [<ffffffff80387b64>] agp_generic_destroy_page+0x44/0x70 [<ffffffff80388645>] agp_free_memory+0x65/0xd0 [<ffffffff80386d49>] agp_free_memory_wrap+0x39/0x60 [<ffffffff803873fb>] agp_release+0xdb/0x1c0 [<ffffffff80299551>] __fput+0xd1/0x1b0 [<ffffffff802996b6>] fput+0x16/0x20 [<ffffffff802964e6>] filp_close+0x56/0x90 [<ffffffff80297bed>] sys_close+0xad/0x110 [<ffffffff8020bd0e>] system_call+0x7e/0x83
INFO: lockdep is turned off.
Code: 0f 0b eb fe 0f 1f 00 48 89 f1 4c 89 c2 48 89 c6 48 c7 c7 e8 RIP [<ffffffff80332f49>] __list_add+0x39/0x60 RSP <ffff81000547bd48>
regards,
Signature · 2 lines
Jiri Slaby ([email protected]) Faculty of Informatics, Masaryk University
PATCH 1/1 make "struct menu_governor" static (again)
In reply to Andrew MortonQuoted 7 lines · Andrew Morton
...
Changes since 2.6.23-rc2-mm2:
...
git-acpi.patch
...
git trees
...
"struct menu_governor" needlessly again became global.
---cb33b296204127cf50df54b84b2d79e152fb924b
drivers/cpuidle/governors/menu.c +1 -1
@@ -117,7 +117,7 @@ static int menu_enable_device(struct cpuidle_device *dev)return 0 ; } -struct cpuidle_governor menu_governor = { +static struct cpuidle_governor menu_governor = { .name ="menu" , .rating =20 , .enable = menu_enable_device,
Re: [-mm patch] make "struct menu_governor" static (again)
This is already fixed in the most recent ACPI CPUIDLE tree.
Thanks,
Adam
Quoted 29 lines · Adrian Bunk
Quoted 7 lines · Andrew Morton
...
Changes since 2.6.23-rc2-mm2:
...
git-acpi.patch
...
git trees
..."struct
menu_governor" needlessly again became global.Signed-off-by Adrian Bunk <[email protected]>---
cb33b296204127cf50df54b84b2d79e152fb924bdrivers/cpuidle/governors/menu.c +1
-1@@ -117,7 +117,7 @@ static int menu_enable_device(struct cpuidle_device *dev)return 0 ; } -struct cpuidle_governor menu_governor = { +static struct cpuidle_governor menu_governor = { .name ="menu" , .rating =20 , .enable = menu_enable_device,
PATCH 1/1 remove parport_device_num()
In reply to Andrew MortonQuoted 7 lines · Andrew Morton
...
Changes since 2.6.23-rc2-mm2:
...
+sysctl-parport-remove-binary-paths.patch
...
More sysctl work
...
parport_device_num() is no longer used.
---
Documentation/parport-lowlevel.txt | 29 +++-------------------------- drivers/parport/daisy.c | 29 ----------------------------- include/linux/parport.h | 1 - 3 files changed, 3 insertions(+), 56 deletions(-)
0066510df2b5d4972cfd6a4450af8b82c763adfd
Documentation/parport-lowlevel.txt +3 -26
@@ -25,7 +25,6 @@ Global functions: parport_open parport_close parport_device_id - parport_device_num parport_device_coords parport_find_class parport_find_device
@@ -735,7 +734,7 @@ NULL is returned. SEE ALSO -parport_register_device, parport_device_num +parport_register_device parport_close - unregister device for particular device number -------------
@@ -787,29 +786,7 @@ Many devices have ill-formed IEEE 1284 Device IDs. SEE ALSO -parport_find_class, parport_find_device, parport_device_num - -parport_device_num - convert device coordinates to device number ------------------- - -SYNOPSIS - -#include <linux/parport.h> - -int parport_device_num (int parport, int mux, int daisy); - -DESCRIPTION - -Convert between device coordinates (port, multiplexor, daisy chain -address) and device number (zero-based). - -RETURN VALUE - -Device number, or -1 if no device at given coordinates. - -SEE ALSO - -parport_device_coords, parport_open, parport_device_id +parport_find_class, parport_find_device parport_device_coords - convert device number to device coordinates ------------------
@@ -833,7 +810,7 @@ Zero on success, in which case the coordinates are (*parport, *mux, SEE ALSO -parport_device_num, parport_open, parport_device_id +parport_open, parport_device_id parport_find_class - find a device by its class ------------------
drivers/parport/daisy.c +0 -29
@@ -275,35 +275,6 @@ void parport_close(struct pardevice *dev)parport_unregister_device (dev); } -/** -* parport_device_num - convert device coordinates -* @parport: parallel port number -* @mux: multiplexor port number (-1 for no multiplexor) -* @daisy: daisy chain address (-1 for no daisy chain address) -* -* This tries to locate a device on the given parallel port, -* multiplexor port and daisy chain address, and returns its -* device number or %-ENXIO if no device with those coordinates -* exists. -**/ - -int parport_device_num (int parport,int mux,int daisy) -{ -int res = -ENXIO ; -struct daisydev *dev; - -spin_lock (&topology_lock); - dev = topology; -while (dev && dev->port->portnum != parport && - dev->port->muxport != mux && dev->daisy != daisy) - dev = dev->next; -if (dev) - res = dev->devnum; -spin_unlock (&topology_lock); - -return res; -} -/* Send a daisy-chain-style CPP command packet. */ static int cpp_daisy (struct parport *port,int cmd) {
include/linux/parport.h +0 -1
@@ -510,7 +510,6 @@ extern struct pardevice *parport_open (int devnum, const char *name, int flags, void *handle);extern void parport_close (struct pardevice *dev);extern ssize_t parport_device_id (int devnum,char *buffer,size_t len); -extern int parport_device_num (int parport,int mux,int daisy);extern void parport_daisy_deselect_all (struct parport *port);extern int parport_daisy_select (struct parport *port,int daisy,int mode);
PATCH 1/1 unexport noautodma
In reply to Andrew MortonQuoted 7 lines · Andrew Morton
...
Changes since 2.6.23-rc2-mm2:
...
+ide-ide-remove-hwif-autodma-and-drive-autodma.patch
...
IDE tree updates
...
noautodma can now be unexported.
---957dc7601c050cb14a7afc842db0c2d62aaf3509
drivers/ide/ide.c +0 -2
@@ -100,8 +100,6 @@ static int ide_scan_direction; /* THIS was formerly 2.2.x pci=reverse */int noautodma =0 ; -EXPORT_SYMBOL (noautodma); -#ifdef CONFIG_BLK_DEV_IDEACPI int ide_noacpi =0 ;int ide_noacpitfs =1 ;
PATCH 1/1 mousedev.c:mixdev_open_devices() bugfix
In reply to Andrew MortonQuoted 7 lines · Andrew Morton
...
Changes since 2.6.23-rc2-mm2:
...
git-input.patch
...
git trees
...
This patch fixes an obvious bug in mixdev_open_devices().
---bb574366744163ff84609843ee43e84a39f57d5a
drivers/input/mousedev.c +1 -1
@@ -461,7 +461,7 @@ static void mixdev_open_devices(void)list_for_each_entry (mousedev, &mousedev_mix_list, mixdev_node) {if (!mousedev->mixdev_open) { -if (mousedev_open_device (mousedev)); +if (mousedev_open_device (mousedev))continue ; mousedev->mixdev_open =1 ;
PATCH 1/1 make do_restart_poll() static
In reply to Andrew MortonQuoted 7 lines · Andrew Morton
...
Changes since 2.6.23-rc2-mm2:
...
+use-erestart_restartblock-if-poll-is-interrupted-by-a-signal.patch
...
The infamous misc
...
do_restart_poll() can become static.
---59cd2d11f5f0189973bb280c59262eb50984cb88
fs/select.c +1 -1
@@ -711,7 +711,7 @@ out_fds:return err; } -long do_restart_poll (struct restart_block *restart_block) +static long do_restart_poll (struct restart_block *restart_block) {struct pollfd __user *ufds = (struct pollfd __user *)restart_block->arg0;int nfds = restart_block->arg1;
PATCH 1/1 unexport snd_ctl_elem_{read,write}
In reply to Andrew MortonQuoted 7 lines · Andrew Morton
...
Changes since 2.6.23-rc2-mm2:
...
git-alsa.patch
...
git trees
...
snd_ctl_elem_{read,write} no longer have any modular users.
---
sound/core/control.c | 4 ---- 1 file changed, 4 deletions(-)
23e15051dde57c569e4c9aff1339aaf64185ea71
sound/core/control.c +0 -4
@@ -716,8 +716,6 @@ int snd_ctl_elem_read(struct snd_card *card, struct snd_ctl_elem_value *control)return result; } -EXPORT_SYMBOL (snd_ctl_elem_read); -static int snd_ctl_elem_read_user (struct snd_card *card,struct snd_ctl_elem_value __user *_control) {
@@ -781,8 +779,6 @@ int snd_ctl_elem_write(struct snd_card *card, struct snd_ctl_file *file,return result; } -EXPORT_SYMBOL (snd_ctl_elem_write); -static int snd_ctl_elem_write_user (struct snd_ctl_file *file,struct snd_ctl_elem_value __user *_control) {
PATCH 1/1 iwl-base.c bugfixes
In reply to Andrew MortonQuoted 7 lines · Andrew Morton
...
Changes since 2.6.23-rc2-mm2:
...
git-wireless.patch
...
git trees
...
This patch fixes two obvious bugs.
---
drivers/net/wireless/iwl-base.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
600ffdc11b25ac0aee15271d1b2ce99a367efa31
drivers/net/wireless/iwl-base.c +2 -2
@@ -343,7 +343,7 @@ int iwl_tx_queue_init(struct iwl_priv *priv,* command is very huge the system will not have two scan at the * same time */ len =sizeof (struct iwl_cmd ) * slots_num; -if (txq_id ==IWL_CMD_QUEUE_NUM ); +if (txq_id ==IWL_CMD_QUEUE_NUM ) len +=IWL_MAX_SCAN_SIZE ; txq->cmd =pci_alloc_consistent (dev, len, &txq->dma_addr_cmd);if (!txq->cmd)
@@ -390,7 +390,7 @@ void iwl_tx_queue_free(struct iwl_priv *priv, struct iwl_tx_queue *txq)iwl_hw_txq_free_tfd (priv, txq); len =sizeof (struct iwl_cmd ) * q->n_window; -if (q->id ==IWL_CMD_QUEUE_NUM ); +if (q->id ==IWL_CMD_QUEUE_NUM ) len +=IWL_MAX_SCAN_SIZE ;pci_free_consistent (dev, len, txq->cmd, txq->dma_addr_cmd);
Re: [-mm patch] iwl-base.c bugfixes
Quoted 35 lines · Adrian Bunk
Quoted 7 lines · Andrew Morton
...
Changes since 2.6.23-rc2-mm2:
...
git-wireless.patch
...
git trees
...This patch fixes two obvious bugs.
Signed-off-by Adrian Bunk <[email protected]>---
drivers/net/wireless/iwl-base.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
600ffdc11b25ac0aee15271d1b2ce99a367efa31drivers/net/wireless/iwl-base.c +1
-1@@ -343,7 +343,7 @@ int iwl_tx_queue_init(struct iwl_priv *priv,* command is very huge the system will not have two scan at the * same time */ len =sizeof (struct iwl_cmd ) * slots_num; -if (txq_id ==IWL_CMD_QUEUE_NUM ); +if (txq_id ==IWL_CMD_QUEUE_NUM ) len +=IWL_MAX_SCAN_SIZE ; txq->cmd =pci_alloc_consistent (dev, len, &txq->dma_addr_cmd);if (!txq->cmd)
drivers/net/wireless/iwl-base.c void iwl_tx_queue_free(struct iwl_priv *priv, struct iwl_tx_queue *txq) · line 396
Quoted 8 lines
drivers/net/wireless/iwl-base.c +1
-1@@ -390,7 +390,7 @@ void iwl_tx_queue_free(struct iwl_priv *priv, struct iwl_tx_queue *txq)iwl_hw_txq_free_tfd (priv, txq); len =sizeof (struct iwl_cmd ) * q->n_window; -if (q->id ==IWL_CMD_QUEUE_NUM ); +if (q->id ==IWL_CMD_QUEUE_NUM ) len +=IWL_MAX_SCAN_SIZE ;pci_free_consistent (dev, len, txq->cmd, txq->dma_addr_cmd);
Shame on me.
Thanks
Quoted 4 lines
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH 1/1 unexport sys_{open,read}
In reply to Andrew MortonQuoted 7 lines · Andrew Morton
...
Changes since 2.6.23-rc2-mm2:
...
git-alsa.patch
...
git trees
...
sys_{open,read} can finally be unexported.
---
fs/open.c | 1 - fs/read_write.c | 1 - 2 files changed, 2 deletions(-)
6f6884f9ee675f2e804c6c58ca46337f9765dd0d
fs/open.c +0 -1
@@ -1057,7 +1057,6 @@ asmlinkage long sys_open(const char __user *filename, int flags, int mode)prevent_tail_call (ret);return ret; } -EXPORT_SYMBOL_GPL (sys_open);asmlinkage long sys_openat (int dfd,const char __user *filename,int flags,int mode)
fs/read_write.c +0 -1
@@ -370,7 +370,6 @@ asmlinkage ssize_t sys_read(unsigned int fd, char __user * buf, size_t count)return ret; } -EXPORT_SYMBOL_GPL (sys_read); asmlinkage ssize_t sys_write(unsigned int fd, const char __user * buf, size_t count) {
Re: [-mm patch] unexport sys_{open,read}
Quoted 11 lines · On Mon, 27 Aug 2007 23:27:23 +0200 Adrian Bunk <[email protected]> wrote:
Quoted 7 lines · Andrew Morton
...
Changes since 2.6.23-rc2-mm2:
...
git-alsa.patch
...
git trees
...sys_{open,read} can finally be unexported.
isn't sys_close in the same boat?
Re: [-mm patch] unexport sys_{open,read}
Quoted 12 lines · Arjan van de Ven
Quoted 9 lines · On Mon, 27 Aug 2007 23:27:23 +0200 Adrian Bunk <[email protected]> wrote:
Quoted 7 lines · Andrew Morton
...
Changes since 2.6.23-rc2-mm2:
...
git-alsa.patch
...
git trees
...
Quoted 4 lines
Quoted 2 lines
sys_{open,read} can finally be unexported.
isn't
sys_closein the same boat?
Still used in fs/binfmt_misc.c ...
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed2.6.23-rc3-mm1: m32r defconfig compile error
In reply to Andrew MortonQuoted 7 lines · Andrew Morton
...
Changes since 2.6.23-rc2-mm2:
...
git-m32r.patch
...
git trees
...
<-- snip -->
...
AS arch/m32r/kernel/entry.o/home/bunk/linux/kernel-2.6/linux-2.6.23-rc3-mm1/arch/m32r/kernel/entry.S: Assembler messages:/home/bunk/linux/kernel-2.6/linux-2.6.23-rc3-mm1/arch/m32r/kernel/entry.S:358: Error: bad instruction `addi r0,#(((((0)+(64))+(32))+(32)))' make[2]: *** [arch/m32r/kernel/entry.o] Error 1
<-- snip -->
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedRe: 2.6.23-rc3-mm1: m32r defconfig compile error
From: Adrian Bunk <[email protected]>
Subject: 2.6.23-rc3-mm1: m32r defconfig compile error
Date: Mon, 27 Aug 2007 23:27:48 +0200
Quoted 17 lines · Andrew Morton
Quoted 7 lines
...
Changes since 2.6.23-rc2-mm2:
...
git-m32r.patch
...
git trees
...<-- snip -->
...
ASarch/m32r/kernel/entry.o/home/bunk/linux/kernel-2.6/linux-2.6.23-rc3-mm1/arch/m32r/kernel/entry.S: Assembler messages:/home/bunk/linux/kernel-2.6/linux-2.6.23-rc3-mm1/arch/m32r/kernel/entry.S:358: Error: bad instruction `addi r0,#(((((0)+(64))+(32))+(32)))' make[2]: *** [arch/m32r/kernel/entry.o] Error 1
Quoted 5 lines
<-- snip -->
cu
Adrian
Hello, Adrian,
Thank you for the report.
M32700UT/OPSPUT Users,
Please apply this patch to build an m32r 2.6.23-rc3-mm1 kernel.
This patch has also included to my m32r kernel development git repository.
git://www.linux-m32r.org/git/takata/linux-2.6_dev.git linux-m32r
Thanks,
-- Takata
[PATCH 2.6.23-rc3-mm1] m32r: build fix of entry.S
This patch is required to fix build errors for the modification:
m32r: Simplify ei_handler code
commit f6c7546d53a4288501dcdd96d5297214697e7237
--- arch/m32r/kernel/entry.S | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
arch/m32r/kernel/entry.S +2 -2
@@ -355,7 +355,7 @@ ENTRY(ei_handler) lduh r0, @(low(M32R_INT0ICU_ISTS),r0) ; bit10-6 : ISN slli r0, #21 srli r0, #27 ; ISN - addi r0, #(M32R_INT0ICU_IRQ_BASE) + add3 r0, r0, #(M32R_INT0ICU_IRQ_BASE) bra check_end .fillinsn 4:
@@ -367,7 +367,7 @@ ENTRY(ei_handler) lduh r0, @(low(M32R_INT2ICU_ISTS),r0) ; bit10-6 : ISN slli r0, #21 srli r0, #27 ; ISN - addi r0, #(M32R_INT2ICU_IRQ_BASE) + add3 r0, r0, #(M32R_INT2ICU_IRQ_BASE) ; bra check_end .fillinsn 5:
Signature · 5 lines
1.5.2.4 -- Hirokazu Takata <[email protected]> Linux/M32R Project: http://www.linux-m32r.org/
PATCH 1/1 remove unwind exports
In reply to Andrew MortonQuoted 7 lines · Andrew Morton
...
Changes since 2.6.23-rc2-mm2:
...
+x86_64-mm-unwinder.patch
...
x86 tree updates
...
This patch removes the unused unwind exports.
---
kernel/unwind.c | 4 ---- 1 file changed, 4 deletions(-)
844ccf670a8204df45b89407bb0e5867f03d0f71
kernel/unwind.c +0 -4
@@ -1243,7 +1243,6 @@ int unwind(struct unwind_frame_info *frame)#undef CASES#undef FRAME_REG } -EXPORT_SYMBOL (unwind); int unwind_init_frame_info(struct unwind_frame_info *info, struct task_struct *tsk,
@@ -1255,7 +1254,6 @@ int unwind_init_frame_info(struct unwind_frame_info *info,return 0 ; } -EXPORT_SYMBOL (unwind_init_frame_info);/* * Prepare to unwind a blocked task.
@@ -1269,7 +1267,6 @@ int unwind_init_blocked(struct unwind_frame_info *info,return 0 ; } -EXPORT_SYMBOL (unwind_init_blocked);/* * Prepare to unwind the currently running thread.
@@ -1284,5 +1281,4 @@ int unwind_init_running(struct unwind_frame_info *info,return arch_unwind_init_running (info, callback, arg); } -EXPORT_SYMBOL (unwind_init_running);
PATCH 1/1 ivtv-fb.c bugfix
In reply to Andrew MortonQuoted 7 lines · Andrew Morton
...
Changes since 2.6.23-rc2-mm2:
...
git-dvb.patch
...
git trees
...
This patch fixes an obvious bug in ivtvfb_release_buffers().
---093bdc9ba94bffbec2ed44743418899771488832
drivers/media/video/ivtv/ivtv-fb.c +2 -2
@@ -1068,8 +1068,8 @@ static void ivtvfb_release_buffers (struct ivtv *itv)struct osd_info *oi = itv->osd_info;/* Release cmap */ -if (oi->ivtvfb_info.cmap.len); -fb_dealloc_cmap (&oi->ivtvfb_info.cmap); +if (oi->ivtvfb_info.cmap.len) +fb_dealloc_cmap (&oi->ivtvfb_info.cmap);/* Release pseudo palette */ if (oi->ivtvfb_info.pseudo_palette)
Re: [v4l-dvb-maintainer] [-mm patch] ivtv-fb.c bugfix
Quoted 9 lines · On Monday 27 August 2007 23:29:29 Adrian Bunk wrote:
Quoted 7 lines · Andrew Morton
...
Changes since 2.6.23-rc2-mm2:
...
git-dvb.patch
...
git trees
...
Quoted 3 lines
This patch fixes an obvious bug in
ivtvfb_release_buffers().Signed-off-by Adrian Bunk <[email protected]>
Ouch. Thanks.
Mauro, I've added this patch to my v4l-dvb tree. Can you pull from it?
Thanks,
Hans
Quoted 24 lines
---
093bdc9ba94bffbec2ed44743418899771488832(quoted diff) +0
-0
b/drivers/media/video/ivtv/ivtv-fb.cindex 0080765..8a344d5 100644drivers/media/video/ivtv/ivtv-fb.c +2
-2@@ -1068,8 +1068,8 @@ static void ivtvfb_release_buffers (struct ivtv *itv) struct osd_info *oi = itv->osd_info;/* Release cmap */ -if (oi->ivtvfb_info.cmap.len); -fb_dealloc_cmap (&oi->ivtvfb_info.cmap); +if (oi->ivtvfb_info.cmap.len) +fb_dealloc_cmap (&oi->ivtvfb_info.cmap);/* Release pseudo palette */ if (oi->ivtvfb_info.pseudo_palette)_______________________________________________
v4l-dvb-maintainer mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer
2.6.23-rc3-mm1: i386: -maccumulate-outgoing-args unconditionally
In reply to Andrew MortonReview
Quoted 9 lines · Andrew Morton
...
Changes since 2.6.23-rc2-mm2:
...(quoted diff) +2
-0+x86_64-mm-unwinder.patch +x86_64-mm-remove-maccumulate-outgoing-args.patch x86 tree updates
-maccumulate-outgoing-args on i386 count:
1 + 1 - 1 = 1
If the stack unwinder needs it please enable it only explicitely when the unwinder is enabled - we are talking about a 2.5% size increase with defconfig.
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seedoops at sr_block_release [Re: 2.6.23-rc3-mm1]
In reply to Andrew MortonAndrew Morton napsal(a):
Quoted 1 line
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
I got this during gxine initialization of ocko.tv live stream without any cd in cdroms:
BUG: unable to handle kernel NULL pointer dereference at virtual address 0000005c printing eip: f88fbe7a *pde = 00000000 Oops: 0000 [#1] SMP Modules linked in: ath5k arc4 ecb blkcipher cryptomgr crypto_algapi
rc80211_simple mac80211 cfg80211 nls_cp437 vfat fat usb_storage tun ipv6 floppy parport_pc parport ohci1394 ieee1394 usbhid sr_mod ehci_hcd cdrom ff_memless
Pid: 2809, comm: hald-addon-stor Not tainted (2.6.23-rc3-mm1 #315)
EIP: 0060:[<f88fbe7a>] EFLAGS: 00010246 CPU: 1
EIP is at sr_block_release+0xb/0x2c [sr_mod]
EAX: 00000000 EBX: 00000000 ECX: f88fbe6f EDX: 00000000
ESI: c21c36c0 EDI: c289a780 EBP: c3729f18 ESP: c3729f10
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process hald-addon-stor (pid: 2809, ti=c3729000 task=c1c2be40 task.ti=c3729000)
Stack: 00000000 c21c36c0 c3729f38 c018d7ad c21c36cc c1f9ff80 c21c3730 c21c36c0
c2a6ada0 dcbb3f80 c3729f40 c018d7dc c3729f4c c018e103 00000010 c3729f74
c016bc5f 00000000 00000000 c217fa80 c1f9ff80 c2a6ada0 dcbb3f80 c1cc6900
Call Trace:
[<c0105022>] show_trace_log_lvl+0x1a/0x30
[<c01050dd>] show_stack_log_lvl+0xa5/0xca
[<c01051d2>] show_registers+0xd0/0x1c1
[<c01053cd>] die+0x10a/0x24d
[<c011afbe>] do_page_fault+0x496/0x608
[<c03768e2>] error_code+0x72/0x78
[<c018d7ad>] __blkdev_put+0x125/0x14a
[<c018d7dc>] blkdev_put+0xa/0xc
[<c018e103>] blkdev_close+0x29/0x2c
[<c016bc5f>] __fput+0xa6/0x161
[<c016bea4>] fput+0x22/0x3b
[<c016960b>] filp_close+0x41/0x67
[<c016a78c>] sys_close+0x60/0x9f
[<c01040ce>] syscall_call+0x7/0xb
=======================
Code: 0c 81 c3 4c 01 00 00 89 5c 24 08 89 44 24 04 c7 04 24 88 cd 8f f8 e8 99 8482 c7 e9 04 fe ff ff 55 89 e5 56 53 8b 80 04 01 00 00 <8b> 40 5c 8b 70 3c 8d 46 18 e8 cf f6 fe ff 89 c3 85 c0 75 07 89
EIP: [<f88fbe7a>] sr_block_release+0xb/0x2c [sr_mod] SS:ESP 0068:c3729f10
regards,
Signature · 2 lines
Jiri Slaby ([email protected]) Faculty of Informatics, Masaryk University
Re: oops at sr_block_release [Re: 2.6.23-rc3-mm1]
Hi Jiri,
Quoted 5 lines · Jiri Slaby
Andrew Morton napsal(a):
Quoted 1 line
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
I got this during gxine initialization of ocko.tv live stream without any cd in cdroms:
Yup, that's an old habit of hald-addon-storage ... doing open(2), ioctl(2) and close(2) on the cdrom block device even when it's idle, every 2 seconds.
Quoted 34 lines
BUG: unable to handle kernel NULL pointer dereference at virtual address 0000005c printing eip: f88fbe7a *pde = 00000000 Oops: 0000 [#1] SMP Modules linked in: ath5k arc4 ecb blkcipher cryptomgr crypto_algapi
rc80211_simplemac80211 cfg80211nls_cp437vfat fatusb_storagetun ipv6 floppyparport_pcparport ohci1394 ieee1394 usbhidsr_modehci_hcdcdromff_memlessPid: 2809, comm: hald-addon-stor Not tainted (2.6.23-rc3-mm1 #315)
EIP: 0060:[<f88fbe7a>] EFLAGS: 00010246 CPU: 1
EIP is atsr_block_release+0xb/0x2c[sr_mod]
EAX: 00000000 EBX: 00000000 ECX:f88fbe6fEDX: 00000000
ESI:c21c36c0EDI:c289a780EBP:c3729f18ESP:c3729f10
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process hald-addon-stor (pid: 2809, ti=c3729000 task=c1c2be40 task.ti=c3729000)Stack: 00000000 c21c36c0 c3729f38 c018d7ad c21c36cc c1f9ff80 c21c3730 c21c36c0 c2a6ada0 dcbb3f80 c3729f40 c018d7dc c3729f4c c018e103 00000010 c3729f74 c016bc5f 00000000 00000000 c217fa80 c1f9ff80 c2a6ada0 dcbb3f80 c1cc6900 Call Trace: [<c0105022>] show_trace_log_lvl+0x1a/0x30 [<c01050dd>] show_stack_log_lvl+0xa5/0xca [<c01051d2>] show_registers+0xd0/0x1c1 [<c01053cd>] die+0x10a/0x24d [<c011afbe>] do_page_fault+0x496/0x608 [<c03768e2>] error_code+0x72/0x78 [<c018d7ad>] __blkdev_put+0x125/0x14a [<c018d7dc>] blkdev_put+0xa/0xc [<c018e103>] blkdev_close+0x29/0x2c [<c016bc5f>] __fput+0xa6/0x161 [<c016bea4>] fput+0x22/0x3b [<c016960b>] filp_close+0x41/0x67 [<c016a78c>] sys_close+0x60/0x9f [<c01040ce>] syscall_call+0x7/0xb ======================= Code: 0c 81 c3 4c 01 00 00 89 5c 24 08 89 44 24 04 c7 04 24 88 cd 8f f8 e8 99 84
Quoted 3 lines
82 c7 e9 04 fe ff ff 55 89 e5 56 53 8b 80 04 01 00 00 <8b> 40 5c 8b 70 3c 8d 46 18 e8 cf f6 fe ff 89 c3 85 c0 75 07 89
EIP: [<f88fbe7a>]sr_block_release+0xb/0x2c[sr_mod] SS:ESP 0068:c3729f10
blkdev_put(bdev, ...)
__blkdev_put(bdev, ...) sr_block_release(bdev->bd_inode, ...) (sees bdev->bd_inode->i_bdev->bd_disk == NULL)
Doesn't seem like an sr_block_release() (or sr_mod) issue to me at all, looks more like a wierd race in the block_device code ... can you send or put up some link to your .config?
If this is reproducible (I bet it isn't, though) you could try bisecting.
Satyam
Re: oops at sr_block_release [Re: 2.6.23-rc3-mm1]
Satyam Sharma napsal(a):
Quoted 53 lines
Hi Jiri,
Quoted 4 lines · Jiri Slaby
Andrew Morton napsal(a):
Quoted 1 line
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
I got this during gxine initialization of ocko.tv live stream without any cd in cdroms:
Yup, that's an old habit of hald-addon-storage ... doing open(2), ioctl(2) and close(2) on the cdrom block device even when it's idle, every 2 seconds.
Quoted 34 lines
BUG: unable to handle kernel NULL pointer dereference at virtual address 0000005c printing eip: f88fbe7a *pde = 00000000 Oops: 0000 [#1] SMP Modules linked in: ath5k arc4 ecb blkcipher cryptomgr crypto_algapi
rc80211_simplemac80211 cfg80211nls_cp437vfat fatusb_storagetun ipv6 floppyparport_pcparport ohci1394 ieee1394 usbhidsr_modehci_hcdcdromff_memlessPid: 2809, comm: hald-addon-stor Not tainted (2.6.23-rc3-mm1 #315)
EIP: 0060:[<f88fbe7a>] EFLAGS: 00010246 CPU: 1
EIP is atsr_block_release+0xb/0x2c[sr_mod]
EAX: 00000000 EBX: 00000000 ECX:f88fbe6fEDX: 00000000
ESI:c21c36c0EDI:c289a780EBP:c3729f18ESP:c3729f10
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process hald-addon-stor (pid: 2809, ti=c3729000 task=c1c2be40 task.ti=c3729000)Stack: 00000000 c21c36c0 c3729f38 c018d7ad c21c36cc c1f9ff80 c21c3730 c21c36c0 c2a6ada0 dcbb3f80 c3729f40 c018d7dc c3729f4c c018e103 00000010 c3729f74 c016bc5f 00000000 00000000 c217fa80 c1f9ff80 c2a6ada0 dcbb3f80 c1cc6900 Call Trace: [<c0105022>] show_trace_log_lvl+0x1a/0x30 [<c01050dd>] show_stack_log_lvl+0xa5/0xca [<c01051d2>] show_registers+0xd0/0x1c1 [<c01053cd>] die+0x10a/0x24d [<c011afbe>] do_page_fault+0x496/0x608 [<c03768e2>] error_code+0x72/0x78 [<c018d7ad>] __blkdev_put+0x125/0x14a [<c018d7dc>] blkdev_put+0xa/0xc [<c018e103>] blkdev_close+0x29/0x2c [<c016bc5f>] __fput+0xa6/0x161 [<c016bea4>] fput+0x22/0x3b [<c016960b>] filp_close+0x41/0x67 [<c016a78c>] sys_close+0x60/0x9f [<c01040ce>] syscall_call+0x7/0xb ======================= Code: 0c 81 c3 4c 01 00 00 89 5c 24 08 89 44 24 04 c7 04 24 88 cd 8f f8 e8 99 84Quoted 3 lines
82 c7 e9 04 fe ff ff 55 89 e5 56 53 8b 80 04 01 00 00 <8b> 40 5c 8b 70 3c 8d 46 18 e8 cf f6 fe ff 89 c3 85 c0 75 07 89
EIP: [<f88fbe7a>]sr_block_release+0xb/0x2c[sr_mod] SS:ESP 0068:c3729f10
Quoted 8 lines
blkdev_put(bdev, ...)__blkdev_put(bdev, ...) sr_block_release(bdev->bd_inode, ...) (sees bdev->bd_inode->i_bdev->bd_disk == NULL)Doesn't seem like an
sr_block_release()(orsr_mod) issue to me at all, looks more like a wierd race in theblock_devicecode ... can you send or put up some link to your .config?
http://www.fi.muni.cz/~xslaby/sklad/config-2.6.23-rc3-mm1
Quoted 1 line
If this is reproducible
:) no.
Signature · 2 lines
Jiri Slaby ([email protected]) Faculty of Informatics, Masaryk University
Re: oops at sr_block_release [Re: 2.6.23-rc3-mm1]
In reply to Jiri SlabyQuoted 40 lines · On Tue, 28 Aug 2007 13:32:57 +0200 Jiri Slaby <[email protected]> wrote:
Andrew Morton napsal(a):
Quoted 1 line
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
I got this during gxine initialization of ocko.tv live stream without any cd in cdroms:
BUG: unable to handle kernel NULL pointer dereference at virtual address 0000005c printing eip: f88fbe7a *pde = 00000000 Oops: 0000 [#1] SMP Modules linked in: ath5k arc4 ecb blkcipher cryptomgr crypto_algapi
rc80211_simplemac80211 cfg80211nls_cp437vfat fatusb_storagetun ipv6 floppyparport_pcparport ohci1394 ieee1394 usbhidsr_modehci_hcdcdromff_memlessPid: 2809, comm: hald-addon-stor Not tainted (2.6.23-rc3-mm1 #315)
EIP: 0060:[<f88fbe7a>] EFLAGS: 00010246 CPU: 1
EIP is atsr_block_release+0xb/0x2c[sr_mod]
EAX: 00000000 EBX: 00000000 ECX:f88fbe6fEDX: 00000000
ESI:c21c36c0EDI:c289a780EBP:c3729f18ESP:c3729f10
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process hald-addon-stor (pid: 2809, ti=c3729000 task=c1c2be40 task.ti=c3729000)Stack: 00000000 c21c36c0 c3729f38 c018d7ad c21c36cc c1f9ff80 c21c3730 c21c36c0 c2a6ada0 dcbb3f80 c3729f40 c018d7dc c3729f4c c018e103 00000010 c3729f74 c016bc5f 00000000 00000000 c217fa80 c1f9ff80 c2a6ada0 dcbb3f80 c1cc6900 Call Trace: [<c0105022>] show_trace_log_lvl+0x1a/0x30 [<c01050dd>] show_stack_log_lvl+0xa5/0xca [<c01051d2>] show_registers+0xd0/0x1c1 [<c01053cd>] die+0x10a/0x24d [<c011afbe>] do_page_fault+0x496/0x608 [<c03768e2>] error_code+0x72/0x78 [<c018d7ad>] __blkdev_put+0x125/0x14a [<c018d7dc>] blkdev_put+0xa/0xc [<c018e103>] blkdev_close+0x29/0x2c [<c016bc5f>] __fput+0xa6/0x161 [<c016bea4>] fput+0x22/0x3b [<c016960b>] filp_close+0x41/0x67 [<c016a78c>] sys_close+0x60/0x9f [<c01040ce>] syscall_call+0x7/0xb ======================= Code: 0c 81 c3 4c 01 00 00 89 5c 24 08 89 44 24 04 c7 04 24 88 cd 8f f8 e8 99 84
Quoted 4 lines
82 c7 e9 04 fe ff ff 55 89 e5 56 53 8b 80 04 01 00 00 <8b> 40 5c 8b 70 3c 8d 46 18 e8 cf f6 fe ff 89 c3 85 c0 75 07 89
EIP: [<f88fbe7a>]sr_block_release+0xb/0x2c[sr_mod] SS:ESP 0068:c3729f10
Possibly due to remove-bdput-from-do_open-in-fs-block_devc.patch.
That patch is "wrong" and I think the problem which it attempts to address actually lies in the cdrom code. viro was taking a look at it but appears to have recoiled in horror. I'll drop remove-bdput-from-do_open-in-fs-block_devc.patch so let's just watch out for any reoccurrence, thanks.
Quoted 1 line · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
Sorry for not catching this one sooner, but AFAICT, Fedora didn't ship a glibc that trips over this (2.6.90-12) until Saturday and I installed it yesterday. -22-rc6-mm1 demonstrated the same issue as well.
The issue: vdso and gettimeofday seem to be having a quarrel.
At boot, the system clock is just fine. Right when it hits the 5-minute
uptime mark (and suspiciously close to the jiffie rollover), the date suddenly shoots forward 4096 seconds.
Dumb test script:
#!/bin/bash
log="uptime.uname -r"
touch /root/$log
tail -f /root/$log &
while /bin/true;
do
uptime >> /root/$log
date >> /root/$log
sleep 1
done
Exerpt from runtime:
19:57:55 up 1 min, 0 users, load average: 0.09, 0.05, 0.01
Tue Aug 28 19:57:55 EDT 2007
19:57:56 up 1 min, 0 users, load average: 0.09, 0.05, 0.01
Tue Aug 28 19:57:56 EDT 2007
19:57:57 up 2 min, 0 users, load average: 0.08, 0.05, 0.01
Tue Aug 28 19:57:57 EDT 2007
19:57:58 up 2 min, 0 users, load average: 0.08, 0.05, 0.01
...
20:00:55 up 4 min, 0 users, load average: 0.01, 0.03, 0.00
Tue Aug 28 20:00:55 EDT 2007
20:00:56 up 4 min, 0 users, load average: 0.01, 0.03, 0.00
Tue Aug 28 20:00:56 EDT 2007
20:00:57 up 5 min, 0 users, load average: 0.01, 0.03, 0.00
Tue Aug 28 21:09:15 EDT 2007
20:00:58 up 5 min, 0 users, load average: 0.01, 0.03, 0.00
Tue Aug 28 21:09:16 EDT 2007
20:00:59 up 5 min, 0 users, load average: 0.01, 0.03, 0.00
Tue Aug 28 21:09:17 EDT 2007
uptime keeps reporting the right time, date goes flying ahead. Once we get into this state, I can issue a 'date' command to set the *right* time, and then it will immediately reset back. Doing a 'touch foo; ls -l foo' shows the correct time.
Booting with vdso=0 makes the time/date run normally.
Ideas?
Re: 2.6.23-rc3-mm1 - vdso and gettimeofday issues with glibc
On Wed, 29 Aug 2007 10:04:33 EDT, [email protected] said:
(Fixing the Subject: and updating the info)
Quoted 4 lines · Andrew Morton
Quoted 1 line
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
The issue: vdso and gettimeofday seem to be having a quarrel.
This is also open as a Fedora bug:
https://bugzilla.redhat.com/show_bug.cgi?id=262481
Re: 2.6.23-rc3-mm1 - vdso and gettimeofday issues with glibc
Quoted 4 lines · On Wed, 29 Aug 2007 13:37:38 -0400 [email protected] wrote:
On Wed, 29 Aug 2007 10:04:33 EDT, [email protected] said:
(Fixing the Subject: and updating the info)
Quoted 8 lines
Quoted 4 lines · Andrew Morton
Quoted 1 line
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
The issue: vdso and gettimeofday seem to be having a quarrel.
This is also open as a Fedora bug:
https://bugzilla.redhat.com/show_bug.cgi?id=262481
So it's an interaction between the x86_64 vdso patches in Andi's tree and newer glibc, and we don't know which one is getting it wrong yet?
If I ever get another -mm out the door (have been without electricity for several days) I'll drop the vdso changes until this is sorted out.
Re: 2.6.23-rc3-mm1 - vdso and gettimeofday issues with glibc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 2 lines · Andrew Morton
So it's an interaction between the
x86_64vdso patches in Andi's tree and newer glibc, and we don't know which one is getting it wrong yet?
glibc does nothing but call the code in the vdso. We have a function pointer variable which either has the old vsyscall value or the address of the function in the vdso. Everything else is identical. Unless the interface of the vdso function is different (which it shouldn't) I don't think you can blame glibc.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFG1i+K2ijCOnn/RHQRArogAKC3zBeyOzqJRF+x2zj3fBg9iGLdyQCgx9Z3 dv3Izh65+kxKedza6RH3MHk=
=qEdC
-----END PGP SIGNATURE-----
Re: 2.6.23-rc3-mm1 - vdso and gettimeofday issues with glibc
In reply to Andrew MortonQuoted 5 lines · Andrew Morton
So it's an interaction between the
x86_64vdso patches in Andi's tree and newer glibc, and we don't know which one is getting it wrong yet?If I ever get another -mm out the door (have been without electricity for several days) I'll drop the vdso changes until this is sorted out.
Don't bother, I tested this last night against a vanilla 2.6.23-rc3 kernel and it had the same issue as well. So Andi's vdso patches in his tree and/or the -mm kernel aren't to blame - it's in mainline as well. And it's been in for a while - I also hit it with a 2.6.22-rc6-mm1 kernel.
Re: 2.6.23-rc3-mm1 - vdso and gettimeofday issues with glibc
Quoted 5 lines · On 08/30/2007 10:08 AM, [email protected] wrote:
Quoted 3 lines · Andrew Morton
So it's an interaction between the
x86_64vdso patches in Andi's tree and newer glibc, and we don't know which one is getting it wrong yet?
Quoted 8 lines
Quoted 2 lines
If I ever get another -mm out the door (have been without electricity for several days) I'll drop the vdso changes until this is sorted out.
Don't bother, I tested this last night against a vanilla 2.6.23-rc3 kernel and it had the same issue as well. So Andi's vdso patches in his tree and/or the -mm kernel aren't to blame - it's in mainline as well. And it's been in for a while - I also hit it with a 2.6.22-rc6-mm1 kernel.
We also have:
http://lkml.org/lkml/2007/7/29/376
(Time repeatedly jumps backwards ~4400 seconds.)
Re: 2.6.23-rc3-mm1 - vdso and gettimeofday issues with glibc
In reply to Andrew MortonQuoted 11 lines · Andrew Morton
Quoted 4 lines
Quoted 1 line
The issue: vdso and gettimeofday seem to be having a quarrel.
This is also open as a Fedora bug:
https://bugzilla.redhat.com/show_bug.cgi?id=262481So it's an interaction between the
x86_64vdso patches in Andi's tree and newer glibc, and we don't know which one is getting it wrong yet?If I ever get another -mm out the door (have been without electricity for several days) I'll drop the vdso changes until this is sorted out. -
Problem is present in stock 2.6.23-rc too. Still don't know whether it is the new glibc code or the vdso that's causing it, though.
Re: 2.6.23-rc3-mm1 - vdso and gettimeofday issues with glibc
Quoted 9 lines · Chuck Ebbert
Quoted 8 lines · Andrew Morton
Quoted 4 lines
Quoted 1 line
The issue: vdso and gettimeofday seem to be having a quarrel.
This is also open as a Fedora bug:
https://bugzilla.redhat.com/show_bug.cgi?id=262481So it's an interaction between the
x86_64vdso patches in Andi's tree and newer glibc, and we don't know which one is getting it wrong yet?
Quoted 6 lines
Quoted 3 lines
If I ever get another -mm out the door (have been without electricity for several days) I'll drop the vdso changes until this is sorted out. -
Problem is present in stock 2.6.23-rc too. Still don't know whether it is the new glibc code or the vdso that's causing it, though.
Updating on this issue: Both myself and another person have reported on
the RedHat bugzilla that it's a clocksource issue - if you are using the hpet clocksource, the time warps, but booting with clocksource=acpi_pm works.
This ring any bells?
Re: 2.6.23-rc3-mm1 - vdso and gettimeofday issues with glibc
Quoted 6 lines
Updating on this issue: Both myself and another person have reported on
the RedHat bugzilla that it's a clocksource issue - if you are using the hpet clocksource, the time warps, but booting with clocksource=acpi_pm works.This ring any bells?
Does this patch fix it?
-Andi
Add missing mask operation to vdso
vdso vgetns() didn't mask the time source offset calculation, which could lead to time problems with 32bit HPET. Add the masking.
Thanks to Chuck Ebbert for tracking down.
arch/x86_64/vdso/vclock_gettime.c +3 -2
@@ -34,10 +34,11 @@ static long vdso_fallback_gettime(long cstatic inline long vgetns (void ) { +long v;cycles_t (*vread)(void); vread = gtod->clock.vread; -return ((vread () - gtod->clock.cycle_last) * gtod->clock.mult) >> - gtod->clock.shift; + v = (vread () - gtod->clock.cycle_last) & gtod->clock.mask; +return (v * gtod->clock.mult) >> gtod->clock.shift; } static noinline int do_realtime(struct timespec *ts)
[email protected]
Tested-byRe: 2.6.23-rc3-mm1 - vdso and gettimeofday issues with glibc
Quoted 9 lines · Andi Kleen
Quoted 5 lines
Updating on this issue: Both myself and another person have reported on
the RedHat bugzilla that it's a clocksource issue - if you are using the hpet clocksource, the time warps, but booting with clocksource=acpi_pm works.This ring any bells?
Does this patch fix it?
-Andi
Quoted 8 lines
Add missing mask operation to vdso
vdso
vgetns()didn't mask the time source offset calculation, which could lead to time problems with 32bit HPET. Add the masking.Thanks to Chuck Ebbert for tracking down.
Signed-off-by Andi Kleen <[email protected]>
Confirming that does indeed fix it - booted with hpet clocksource and vdso=1, and the time didn't warp at the 5-minute mark.
Re: 2.6.23-rc3-mm1 - vdso and gettimeofday issues with glibc
In reply to Andrew MortonQuoted 4 lines · Andrew Morton
So it's an interaction between the
x86_64vdso patches in Andi's tree and newer glibc, and we don't know which one is getting it wrong yet?
Just found this duplicated code in 2.6.23-rc4, maybe it was supposed to be something else? The second one was added in the x86_64 vdso patch.
arch/x86_64/kernel/vsyscall.c:
void update_vsyscall(struct timespec *wall_time, struct clocksource *clock)
{
unsigned long flags;
write_seqlock_irqsave(&vsyscall_gtod_data.lock, flags);
/* copy vsyscall data */
vsyscall_gtod_data.clock.vread = clock->vread;
vsyscall_gtod_data.clock.cycle_last = clock->cycle_last;
vsyscall_gtod_data.clock.mask = clock->mask;
vsyscall_gtod_data.clock.mult = clock->mult;
vsyscall_gtod_data.clock.shift = clock->shift;
vsyscall_gtod_data.wall_time_sec = wall_time->tv_sec;
vsyscall_gtod_data.wall_time_nsec = wall_time->tv_nsec; <===
vsyscall_gtod_data.sys_tz = sys_tz;
vsyscall_gtod_data.wall_time_nsec = wall_time->tv_nsec; <===
vsyscall_gtod_data.wall_to_monotonic = wall_to_monotonic;
write_sequnlock_irqrestore(&vsyscall_gtod_data.lock, flags);
}Re: 2.6.23-rc3-mm1 - vdso and gettimeofday issues with glibc
Quoted 12 lines
write_seqlock_irqsave(&vsyscall_gtod_data.lock, flags);
/* copy vsyscall data */
vsyscall_gtod_data.clock.vread = clock->vread;
vsyscall_gtod_data.clock.cycle_last = clock->cycle_last;
vsyscall_gtod_data.clock.mask = clock->mask;
vsyscall_gtod_data.clock.mult = clock->mult;
vsyscall_gtod_data.clock.shift = clock->shift;
vsyscall_gtod_data.wall_time_sec = wall_time->tv_sec;
vsyscall_gtod_data.wall_time_nsec = wall_time->tv_nsec; <===
vsyscall_gtod_data.sys_tz = sys_tz;
vsyscall_gtod_data.wall_time_nsec = wall_time->tv_nsec; <===Must have been a (harmless) merging mistake, but I bet gcc optimizes it out anyways.
-Andi
Re: 2.6.23-rc3-mm1 - vdso and gettimeofday issues with glibc
Quoted 12 lines · Andi Kleen
Quoted 11 lines
write_seqlock_irqsave(&vsyscall_gtod_data.lock, flags); /* copy vsyscall data */ vsyscall_gtod_data.clock.vread = clock->vread; vsyscall_gtod_data.clock.cycle_last = clock->cycle_last; vsyscall_gtod_data.clock.mask = clock->mask; vsyscall_gtod_data.clock.mult = clock->mult; vsyscall_gtod_data.clock.shift = clock->shift; vsyscall_gtod_data.wall_time_sec = wall_time->tv_sec; vsyscall_gtod_data.wall_time_nsec = wall_time->tv_nsec; <=== vsyscall_gtod_data.sys_tz = sys_tz; vsyscall_gtod_data.wall_time_nsec = wall_time->tv_nsec; <===
Quoted 3 lines
Must have been a (harmless) merging mistake, but I bet gcc optimizes it out anyways.
I did find this after some digging:
In the vdso code:
static inline long vgetns(void)
{
cycles_t (*vread)(void);
vread = gtod->clock.vread;
return ((vread() - gtod->clock.cycle_last) * gtod->clock.mult) >>
gtod->clock.shift;
}Looks like an open-coded version of this in the kernel timekeeping code:
static inline s64 __get_nsec_offset(void)
{
cycle_t cycle_now, cycle_delta;
s64 ns_offset;
/* read clocksource: */
cycle_now = clocksource_read(clock);
/* calculate the delta since the last update_wall_time: */
cycle_delta = (cycle_now - clock->cycle_last) & clock->mask;
/* convert to nanoseconds: */
ns_offset = cyc2ns(clock, cycle_delta);
return ns_offset;
}But the vdso version isn't doing any masking. And the mask is different for different clocksources, so it has to track the underlying kernel's clocksource when it gets changed.
Re: 2.6.23-rc3-mm1 - vdso and gettimeofday issues with glibc
Quoted 12 lines
In the vdso code:
static inline long vgetns(void)
{ cycles_t (*vread)(void); vread = gtod->clock.vread; return ((vread() - gtod->clock.cycle_last) * gtod->clock.mult) >> gtod->clock.shift; }
Quoted 1 line
Looks like an open-coded version of this in the kernel timekeeping code:
vdso code needs to be all inlined because the vdso runs in ring 3 and cannot access other kernel code.
It was opencoded it to have more control over the code (vdso requirements are a bit peculiar).
Quoted 3 lines
But the vdso version isn't doing any masking. And the mask is different for different clocksources, so it has to track the underlying kernel's clocksource when it gets changed.
vdso effectively only supports TSC and HPET (the other clock sources are not accessible from ring 3)
TSC doesn't need a mask, but many HPETs need a 32bit mask; good point.
Does adding the mask to vgetns make the clock problems go away?
-Andi
Re: 2.6.23-rc3-mm1 - vdso and gettimeofday issues with glibc
Quoted 2 lines · Andi Kleen
vdso effectively only supports TSC and HPET (the other clock sources are not accessible from ring 3)
Ahh.. that explains why acpi_pm clocksource doesn't trip over the problem....