Skip to contentSkip to conversation

2.6.23-rc3-mm1

PATCH In review Andrew Morton 58 participants 208 messages Aug 22, 2007 – Sep 17, 2007 Page 2 of 2

Subsystems (21)
lore
Share & tools
lore
#128 lore raw

PATCH 1/2 sysctl: Properly register the irda binary sysctl numbers.

In reply to Andrew Morton

Grumble. 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
index 88f0941..77c9ae2 100644
@@ -238,6 +238,7 @@ enum
 	NET_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
index 957e04f..525343a 100644
@@ -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
#129 lore raw

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
index d5e0337..aa5b6f6 100644
@@ -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
#130 lore raw

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.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.

Quoted 44 lines
---
 kernel/sysctl_check.c |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)
kernel/sysctl_check.c +19 -0
index d5e0337..aa5b6f6 100644
@@ -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
Tested-by on v1 1/2
#131 lore raw

Re: [PATCH 1/2] sysctl: Properly register the irda binary sysctl numbers.

In reply to Eric W. Biederman
Quoted 6 lines · Eric W. Biederman

Grumble. 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.

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:

#132 lore raw

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.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.

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:

Thanks.

It's good to have confirmation that my sysctl_check routine didn't find something else wrong.

Eric

#133 lore raw

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_check routine 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.

#134 lore raw

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_check routine 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-mm1 is only about 10M, and the Fedora kernels are weighing in at about 75M of /lib/modules a 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

#135 lore raw

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_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.

Yep. Nothing I actually use needs SYSCTL_SYSCALL, so I turned it off to see what breaks...

#136 lore raw

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_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.

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

#137 lore raw

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
index aa5b6f6..10dd744 100644
@@ -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
#139 lore raw

Re: [PATCH 1/2] sysctl: Properly register the irda binary sysctl numbers.

In reply to Eric W. Biederman

Hi Eric,

Quoted 4 lines · Eric W. Biederman

Grumble. 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.

Thanks for that, I should have taken care of it earlier...

Quoted 1 line
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
index 88f0941..77c9ae2 100644
@@ -238,6 +238,7 @@ enum
 	NET_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
index 957e04f..525343a 100644
@@ -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
#140 lore raw
In reply to Andrew Morton

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)
#141 lore raw
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.

#142 lore raw
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_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?

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/proces sor.ko): Input/output error

Quoted 1 line

WARNING: Error inserting processor

(/lib/modules/2.6.23-rc3-mm1-testing/kernel/drivers/acpi/proces sor.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

#143 lore raw
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-mm1

Quoted 4 lines
Quoted 3 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_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?

This is probably not related to cpufreq changes itself. Looks like it is
coming due to

Quoted 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/proces sor.ko): Input/output error

Quoted 1 line

WARNING: Error inserting processor

(/lib/modules/2.6.23-rc3-mm1-testing/kernel/drivers/acpi/proces sor.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.

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

#144 lore raw

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 error

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.

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)
#145 lore raw
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 error

This is indeed related to CPUIDLE.

Quoted 7 lines
Quoted 3 lines

Tilman: Can you configure CONFIG_CPU_IDLE in 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 ***

#146 lore raw

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_IDLE in 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)
#147 lore raw
In reply to Andrew Morton
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 error

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?

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
#148 lore raw
In reply to Andrew Morton
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.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

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_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.

[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

#149 lore raw

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 2007

Hrmm. 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)
#150 lore raw
In reply to Andrew Morton

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.h

which 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 2007

What 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_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.

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
#151 lore raw
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.h

which patch is that?

The one allowing drivers/scsi/advansys.c to compile with CONFIG_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_ISA is disabled, the isa_driver support 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_64 capable, but I'm still running 32 bit kernels on it.

OK.

Quoted 5 lines
Quoted 3 lines

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.

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-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.)

--- /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-mm1 2007-08-25 02:26:08.000000000 +0200

tmp/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 at f0000000 is 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 at f0000000 reserved 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.0

tmp/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.

#152 lore raw
Quoted 12 lines · Andrew Morton
Quoted 11 lines

<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

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
#153 lore raw

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: 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

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_RTC and CONFIG_RTC_DRV_CMOS set.

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

#154 lore raw

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_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.

Quoted 7 lines
Quoted 2 lines

EBUSY. I've seen this happen when you have both CONFIG_RTC and CONFIG_RTC_DRV_CMOS set.

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=y
CONFIG_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)
#155 lore raw

Clock trouble retest results with 2.6.23-rc4-mm1 (was: 2.6.23-rc3-mm1)

In reply to Andrew Morton

Am 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_source failed.

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: 0xfed00000 is busy
+<4>hpet_acpi_add: no address or irqs in _CRS

oh 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_limit

I 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)
#156 lore raw

X freezes kernel during exit [Re: 2.6.23-rc3-mm1]

In reply to Andrew Morton

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): 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
#157 lore raw

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): 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
#158 lore raw

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): 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.

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
#159 lore raw

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): 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).

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?

#160 lore raw

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
#161 lore raw

Re: X freezes kernel during exit [Re: 2.6.23-rc3-mm1]

In reply to Andrew Morton
Quoted 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): 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).

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
#162 lore raw

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_map in list_for_each_entry on the first CPU. The a->l list 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

#163 lore raw

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_map in list_for_each_entry on the first CPU. The a->l list 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
#164 lore raw

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

#165 lore raw

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 : 0
vendor_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 : yes
fpu_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 : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_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 : yes
fpu_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 : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

Signature · 2 lines
Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University
#166 lore raw

Re: X freezes kernel during exit [Re: 2.6.23-rc3-mm1]

In reply to Andi Kleen
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_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
#167 lore raw

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_map looks 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

#168 lore raw

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_map looks like:

Can you stick a printk into change_page_attr to 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
#169 lore raw

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.

#170 lore raw

Re: X freezes kernel during exit [Re: 2.6.23-rc3-mm1]

In reply to Jiri Slaby
Quoted 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_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.
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_init is called on it? Weird.

Ok, here comes a BUG with trace:
set status page addr 0x00033000
list_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
#171 lore raw

PATCH 1/1 make "struct menu_governor" static (again)

In reply to Andrew Morton
Quoted 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
index f5a8865..8d3fdc5 100644
@@ -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,
#172 lore raw

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.

---
cb33b296204127cf50df54b84b2d79e152fb924b

drivers/cpuidle/governors/menu.c +1 -1
index f5a8865..8d3fdc5 100644
@@ -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,
#173 lore raw

PATCH 1/1 remove parport_device_num()

In reply to Andrew Morton
Quoted 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
index 8f23024..265fcdc 100644
@@ -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
index ff9f344..5bbff20 100644
@@ -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
index 9cdd694..ec3f765 100644
@@ -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);
 
#174 lore raw

PATCH 1/1 unexport noautodma

In reply to Andrew Morton
Quoted 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
index b3b5f00..5b09066 100644
@@ -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;
#175 lore raw

PATCH 1/1 mousedev.c:mixdev_open_devices() bugfix

In reply to Andrew Morton
Quoted 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
index 2ad8633..4ca0ad3 100644
@@ -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;
#176 lore raw

PATCH 1/1 make do_restart_poll() static

In reply to Andrew Morton
Quoted 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
index 5a3ab01..3e515aa 100644
@@ -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;
#177 lore raw

PATCH 1/1 unexport snd_ctl_elem_{read,write}

In reply to Andrew Morton
Quoted 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
index 396e98e..6144d8a 100644
@@ -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)
 {
#178 lore raw

PATCH 1/1 iwl-base.c bugfixes

In reply to Andrew Morton
Quoted 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
index b8293fe..f65c30e 100644
@@ -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);
#179 lore raw

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.

---

 drivers/net/wireless/iwl-base.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

600ffdc11b25ac0aee15271d1b2ce99a367efa31

drivers/net/wireless/iwl-base.c +1 -1
index b8293fe..f65c30e 100644
@@ -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

#180 lore raw

PATCH 1/1 unexport sys_{open,read}

In reply to Andrew Morton
Quoted 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
index 23f334d..c0814de 100644
@@ -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
index 507ddff..d913d1e 100644
@@ -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)
 {
#181 lore raw

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?

#182 lore raw

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_close in 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 Seed
#183 lore raw

2.6.23-rc3-mm1: m32r defconfig compile error

In reply to Andrew Morton
Quoted 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 Seed
#184 lore raw

Re: 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 -->

...
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

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
index c46cfaa..42b08bf 100644
@@ -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/
#185 lore raw

PATCH 1/1 remove unwind exports

In reply to Andrew Morton
Quoted 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
index 8c267c7..adb1ebe 100644
@@ -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);
 
#186 lore raw

PATCH 1/1 ivtv-fb.c bugfix

In reply to Andrew Morton
Quoted 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
index 0080765..8a344d5 100644
@@ -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)
#187 lore raw

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().

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.c index 0080765..8a344d5 100644

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)

_______________________________________________
v4l-dvb-maintainer mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer

#188 lore raw

2.6.23-rc3-mm1: i386: -maccumulate-outgoing-args unconditionally

In reply to Andrew Morton

Review

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 Seed
#189 lore raw

oops at sr_block_release [Re: 2.6.23-rc3-mm1]

In reply to Andrew Morton

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_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 84

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

regards,

Signature · 2 lines
Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University
#190 lore raw

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_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 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

#191 lore raw

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_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 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

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() (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?

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
#192 lore raw

Re: oops at sr_block_release [Re: 2.6.23-rc3-mm1]

In reply to Jiri Slaby
Quoted 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_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 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.

#193 lore raw
In reply to Andrew Morton
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?

#194 lore raw

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

#195 lore raw

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.

#196 lore raw

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_64 vdso 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-----

#197 lore raw

Re: 2.6.23-rc3-mm1 - vdso and gettimeofday issues with glibc

In reply to Andrew Morton
Quoted 5 lines · Andrew Morton

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.

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.

#198 lore raw

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_64 vdso 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.)

#199 lore raw

Re: 2.6.23-rc3-mm1 - vdso and gettimeofday issues with glibc

In reply to Andrew Morton
Quoted 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=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. -

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.

#200 lore raw

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=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?

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?

#201 lore raw

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
Index: linux/arch/x86_64/vdso/vclock_gettime.c
===================================================================
@@ -34,10 +34,11 @@ static long vdso_fallback_gettime(long c
 
 static 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)
#202 lore raw

Re: 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.

Confirming that does indeed fix it - booted with hpet clocksource and vdso=1, and the time didn't warp at the 5-minute mark.

#203 lore raw

Re: 2.6.23-rc3-mm1 - vdso and gettimeofday issues with glibc

In reply to Andrew Morton
Quoted 4 lines · Andrew Morton

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?

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);
}
#204 lore raw

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

#205 lore raw

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.

#206 lore raw

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

#207 lore raw

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....