2.6.24-rc2-mm1

Quoted 20 lines · Andrew Morton

Quoted 18 lines · On Wed, 14 Nov 2007 12:29:59 -0800 mark gross <[email protected]> wrote:
Quoted 4 lines
Quoted 2 lines
[  102.366932]  =======================
[  108.552031] printk: 31 messages suppressed.
Quoted 10 lines
All this BUG / WARNINGS are caused by *-qos* patches. Reverting this 3 patches makes the BUGs go away :
latencyc-use-qos-infrastructure.patch pm-qos-infrastructure-and-interface.patch pm-qos-infrastructure-and-interface-static-initialization-with-blocking-notifiers.patch
Gabriel
This looks like the same issue Rafael saw.
Try the patch in the following post:

Quoted 8 lines

Quoted 2 lines
http://marc.info/?l=linux-kernel&m=119265627228498&w=2
Well that's not very good. _I_ can go fishing in my lkml archives for random patches but not everyone is set up to do that. And the diff to which you refer gets 100% rejects against rc2-mm1 anyway.
Please prepare a tested, changelogged patch against rc2-mm1 asap.

my bad. I didn't catch the 24-rc2-mm1 baseline for this issue. I'll look at this right way.

--mgross

mark gross

2007-11-15 19:19 UTC #16 lore raw

Quoted 20 lines · Andrew Morton

Quoted 18 lines · On Wed, 14 Nov 2007 12:29:59 -0800 mark gross <[email protected]> wrote:
Quoted 4 lines
Quoted 2 lines
[  102.366932]  =======================
[  108.552031] printk: 31 messages suppressed.
Quoted 10 lines
All this BUG / WARNINGS are caused by *-qos* patches. Reverting this 3 patches makes the BUGs go away :
latencyc-use-qos-infrastructure.patch pm-qos-infrastructure-and-interface.patch pm-qos-infrastructure-and-interface-static-initialization-with-blocking-notifiers.patch
Gabriel
This looks like the same issue Rafael saw.
Try the patch in the following post:

Quoted 8 lines

Quoted 2 lines
http://marc.info/?l=linux-kernel&m=119265627228498&w=2
Well that's not very good. _I_ can go fishing in my lkml archives for random patches but not everyone is set up to do that. And the diff to which you refer gets 100% rejects against rc2-mm1 anyway.
Please prepare a tested, changelogged patch against rc2-mm1 asap.

I'm having difficulty coming up with a .config that boots, I'll continue working on this but the following is what I'm pretty confident will fix the warnings.

You should hold off until I get a system booting 2.6.24-rc2-mm1 before taking this.

pm-qos-remove-locks-around-blocking-notifier-registration.patch

Changelog:
Remove spin locking around blocking notifier calls that can sleep.

--mgross

Signed-off-by mark gross <[email protected]>

kernel/pm_qos_params.c +0 -6

Index: linux-2.6.24-rc2-mm1/kernel/pm_qos_params.c
===================================================================
@@ -319,13 +319,10 @@
  */
  int pm_qos_add_notifier(int pm_qos_class, struct notifier_block *notifier)
 {
-	unsigned long flags;
 	int retval;
 
-	spin_lock_irqsave(&pm_qos_lock, flags);
 	retval = blocking_notifier_chain_register(
 			pm_qos_array[pm_qos_class]->notifiers, notifier);
-	spin_unlock_irqrestore(&pm_qos_lock, flags);
 
 	return retval;
 }

@@ -341,13 +338,10 @@
  */
 int pm_qos_remove_notifier(int pm_qos_class, struct notifier_block *notifier)
 {
-	unsigned long flags;
 	int retval;
 
-	spin_lock_irqsave(&pm_qos_lock, flags);
 	retval = blocking_notifier_chain_unregister(
 			pm_qos_array[pm_qos_class]->notifiers, notifier);
-	spin_unlock_irqrestore(&pm_qos_lock, flags);
 
 	return retval;
 }

Gabriel C

2007-11-15 21:40 UTC #17 lore raw

Quoted 26 lines · mark gross

Quoted 25 lines · Andrew Morton
Quoted 10 lines · On Wed, 14 Nov 2007 12:29:59 -0800 mark gross <[email protected]> wrote:
Quoted 10 lines
Quoted 2 lines
[  102.366932]  =======================
[  108.552031] printk: 31 messages suppressed.
All this BUG / WARNINGS are caused by *-qos* patches. Reverting this 3 patches makes the BUGs go away :
latencyc-use-qos-infrastructure.patch pm-qos-infrastructure-and-interface.patch pm-qos-infrastructure-and-interface-static-initialization-with-blocking-notifiers.patch
Quoted 9 lines
Quoted 3 lines
Gabriel
This looks like the same issue Rafael saw.
Try the patch in the following post:
http://marc.info/?l=linux-kernel&m=119265627228498&w=2
Well that's not very good. _I_ can go fishing in my lkml archives for random patches but not everyone is set up to do that. And the diff to which you refer gets 100% rejects against rc2-mm1 anyway.

Quoted 5 lines

Quoted 1 line
Please prepare a tested, changelogged patch against rc2-mm1 asap.
I'm having difficulty coming up with a .config that boots, I'll continue working on this but the following is what I'm pretty confident will fix the warnings.

Yes your patch fixes the warnings / problems here. Thx.

Quoted 49 lines

You should hold off until I get a system booting 2.6.24-rc2-mm1 before taking this.
pm-qos-remove-locks-around-blocking-notifier-registration.patch
Changelog:
Remove spin locking around blocking notifier calls that can sleep.
--mgross
Signed-off-by mark gross <[email protected]>
Index: linux-2.6.24-rc2-mm1/kernel/pm_qos_params.c
===================================================================
kernel/pm_qos_params.c +0 -6
@@ -319,13 +319,10 @@
  */
  int pm_qos_add_notifier(int pm_qos_class, struct notifier_block *notifier)
 {
-	unsigned long flags;
 	int retval;
 
-	spin_lock_irqsave(&pm_qos_lock, flags);
 	retval = blocking_notifier_chain_register(
 			pm_qos_array[pm_qos_class]->notifiers, notifier);
-	spin_unlock_irqrestore(&pm_qos_lock, flags);
 
 	return retval;
 }
@@ -341,13 +338,10 @@
  */
 int pm_qos_remove_notifier(int pm_qos_class, struct notifier_block *notifier)
 {
-	unsigned long flags;
 	int retval;
 
-	spin_lock_irqsave(&pm_qos_lock, flags);
 	retval = blocking_notifier_chain_unregister(
 			pm_qos_array[pm_qos_class]->notifiers, notifier);
-	spin_unlock_irqrestore(&pm_qos_lock, flags);
 
 	return retval;
 }

mark gross

2007-11-15 22:58 UTC #18 lore raw

In reply to mark gross

Quoted 28 lines · mark gross

Quoted 27 lines · Andrew Morton
Quoted 11 lines · On Wed, 14 Nov 2007 12:29:59 -0800 mark gross <[email protected]> wrote:
Quoted 11 lines
Quoted 2 lines
[  102.366932]  =======================
[  108.552031] printk: 31 messages suppressed.
All this BUG / WARNINGS are caused by *-qos* patches. Reverting this 3 patches makes the BUGs go away :
latencyc-use-qos-infrastructure.patch pm-qos-infrastructure-and-interface.patch pm-qos-infrastructure-and-interface-static-initialization-with-blocking-notifiers.patch
Quoted 9 lines
Quoted 3 lines
Gabriel
This looks like the same issue Rafael saw.
Try the patch in the following post:
http://marc.info/?l=linux-kernel&m=119265627228498&w=2
Well that's not very good. _I_ can go fishing in my lkml archives for random patches but not everyone is set up to do that. And the diff to which you refer gets 100% rejects against rc2-mm1 anyway.

Quoted 8 lines

Quoted 1 line
Please prepare a tested, changelogged patch against rc2-mm1 asap.
I'm having difficulty coming up with a .config that boots, I'll continue working on this but the following is what I'm pretty confident will fix the warnings.
You should hold off until I get a system booting 2.6.24-rc2-mm1 before taking this.

I'm able to boot and have done a bit of testing and this patch wasn't good enough. I'm sending a new one in a min.

--mgross

Quoted 50 lines

pm-qos-remove-locks-around-blocking-notifier-registration.patch
Changelog:
Remove spin locking around blocking notifier calls that can sleep.
--mgross
Signed-off-by mark gross <[email protected]>
Index: linux-2.6.24-rc2-mm1/kernel/pm_qos_params.c
===================================================================
kernel/pm_qos_params.c +0 -7
@@ -319,13 +319,10 @@
  */
  int pm_qos_add_notifier(int pm_qos_class, struct notifier_block *notifier)
 {
-	unsigned long flags;
 	int retval;
 
-	spin_lock_irqsave(&pm_qos_lock, flags);
 	retval = blocking_notifier_chain_register(
 			pm_qos_array[pm_qos_class]->notifiers, notifier);
-	spin_unlock_irqrestore(&pm_qos_lock, flags);
 
 	return retval;
 }
@@ -341,13 +338,10 @@
  */
 int pm_qos_remove_notifier(int pm_qos_class, struct notifier_block *notifier)
 {
-	unsigned long flags;
 	int retval;
 
-	spin_lock_irqsave(&pm_qos_lock, flags);
 	retval = blocking_notifier_chain_unregister(
 			pm_qos_array[pm_qos_class]->notifiers, notifier);
-	spin_unlock_irqrestore(&pm_qos_lock, flags);
 
 	return retval;
 }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

mark gross

2007-11-15 23:09 UTC #19 lore raw

PATCH 1/1 pm-qos-remove-locks-around-blocking-notifier.patch ... was Re: 2.6.24-rc2-mm1

In reply to mark gross

Quoted 21 lines · mark gross

Quoted 20 lines · Andrew Morton
Quoted 18 lines · On Wed, 14 Nov 2007 12:29:59 -0800 mark gross <[email protected]> wrote:
Quoted 4 lines
Quoted 2 lines
[  102.366932]  =======================
[  108.552031] printk: 31 messages suppressed.
Quoted 10 lines
All this BUG / WARNINGS are caused by *-qos* patches. Reverting this 3 patches makes the BUGs go away :
latencyc-use-qos-infrastructure.patch pm-qos-infrastructure-and-interface.patch pm-qos-infrastructure-and-interface-static-initialization-with-blocking-notifiers.patch
Gabriel
This looks like the same issue Rafael saw.
Try the patch in the following post:

Quoted 10 lines

Quoted 8 lines
Quoted 2 lines
http://marc.info/?l=linux-kernel&m=119265627228498&w=2
Well that's not very good. _I_ can go fishing in my lkml archives for random patches but not everyone is set up to do that. And the diff to which you refer gets 100% rejects against rc2-mm1 anyway.
Please prepare a tested, changelogged patch against rc2-mm1 asap.

pm-qos-remove-locks-around-blocking-notifier.patch

I have done some testing with this fix, I think it addresses all the sleep within a held lock warnings reported.

please apply.

Changelog:
Remove spin locking around all blocking notifier calls that can sleep. I had to re-structure some of the code to avoid locking issues.

--mgross

Signed-off-by mark gross <[email protected]>

kernel/pm_qos_params.c +12 ~~-15~~

Index: linux-2.6.24-rc2-mm1/kernel/pm_qos_params.c
===================================================================
@@ -135,13 +135,14 @@
 }
 
 
-
-/* assumes pm_qos_lock is held */
 static void update_target(int target)
 {
 	s32 extreme_value;
 	struct requirement_list *node;
+	unsigned long flags;
+	int call_notifier = 0;
 
+	spin_lock_irqsave(&pm_qos_lock, flags);
 	extreme_value = pm_qos_array[target]->default_value;
 	list_for_each_entry(node,
 			&pm_qos_array[target]->requirements.list, list) {

@@ -149,13 +150,16 @@
 				extreme_value, node->value);
 	}
 	if (pm_qos_array[target]->target_value != extreme_value) {
+		call_notifier = 1;
 		pm_qos_array[target]->target_value = extreme_value;
 		pr_debug(KERN_ERR "new target for qos %d is %d\n", target,
 			pm_qos_array[target]->target_value);
-		blocking_notifier_call_chain(pm_qos_array[target]->notifiers,
-			(unsigned long) pm_qos_array[target]->target_value,
-						NULL);
 	}
+	spin_unlock_irqrestore(&pm_qos_lock, flags);
+
+	if (call_notifier)
+		blocking_notifier_call_chain(pm_qos_array[target]->notifiers,
+			(unsigned long) extreme_value, NULL);
 }
 
 static int register_pm_qos_misc(struct pm_qos_object *qos)

@@ -227,8 +231,8 @@
 		spin_lock_irqsave(&pm_qos_lock, flags);
 		list_add(&dep->list,
 			&pm_qos_array[pm_qos_class]->requirements.list);
-		update_target(pm_qos_class);
 		spin_unlock_irqrestore(&pm_qos_lock, flags);
+		update_target(pm_qos_class);
 
 		return 0;
 	}

@@ -269,11 +273,10 @@
 			break;
 		}
 	}
+	spin_unlock_irqrestore(&pm_qos_lock, flags);
 	if (pending_update)
 		update_target(pm_qos_class);
 
-	spin_unlock_irqrestore(&pm_qos_lock, flags);
-
 	return 0;
 }
 EXPORT_SYMBOL_GPL(pm_qos_update_requirement);

@@ -303,9 +306,9 @@
 			break;
 		}
 	}
+	spin_unlock_irqrestore(&pm_qos_lock, flags);
 	if (pending_update)
 		update_target(pm_qos_class);
-	spin_unlock_irqrestore(&pm_qos_lock, flags);
 }
 EXPORT_SYMBOL_GPL(pm_qos_remove_requirement);

@@ -319,13 +322,10 @@
  */
  int pm_qos_add_notifier(int pm_qos_class, struct notifier_block *notifier)
 {
-	unsigned long flags;
 	int retval;
 
-	spin_lock_irqsave(&pm_qos_lock, flags);
 	retval = blocking_notifier_chain_register(
 			pm_qos_array[pm_qos_class]->notifiers, notifier);
-	spin_unlock_irqrestore(&pm_qos_lock, flags);
 
 	return retval;
 }

@@ -341,13 +341,10 @@
  */
 int pm_qos_remove_notifier(int pm_qos_class, struct notifier_block *notifier)
 {
-	unsigned long flags;
 	int retval;
 
-	spin_lock_irqsave(&pm_qos_lock, flags);
 	retval = blocking_notifier_chain_unregister(
 			pm_qos_array[pm_qos_class]->notifiers, notifier);
-	spin_unlock_irqrestore(&pm_qos_lock, flags);
 
 	return retval;
 }

Tony Breeds

2007-11-14 03:40 UTC #20 lore raw

PATCH 1/1 Fix build failure when CONFIG_INFINIBAND_IPOIB_CM is not defined.

Fixes:
CC [M] drivers/infiniband/ulp/ipoib/ipoib_main.o
drivers/infiniband/ulp/ipoib/ipoib_main.c: In function ‘ipoib_init_module’:
drivers/infiniband/ulp/ipoib/ipoib_main.c:1269: error: invalid lvalue in assignment

In the case where CONFIG_INFINIBAND_IPOIB_CM is not defined ipoib_max_conn_qp is #defined to 0.

Signed-off-by Tony Breeds <[email protected]>

---

 drivers/infiniband/ulp/ipoib/ipoib_main.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

drivers/infiniband/ulp/ipoib/ipoib_main.c +2 -1

index 623458e..aeb5a01 100644
@@ -1265,8 +1265,9 @@ static int __init ipoib_init_module(void)
 	ipoib_sendq_size = roundup_pow_of_two(ipoib_sendq_size);
 	ipoib_sendq_size = min(ipoib_sendq_size, IPOIB_MAX_QUEUE_SIZE);
 	ipoib_sendq_size = max(ipoib_sendq_size, IPOIB_MIN_QUEUE_SIZE);
-
+#ifdef CONFIG_INFINIBAND_IPOIB_CM
 	ipoib_max_conn_qp = min(ipoib_max_conn_qp, IPOIB_CM_MAX_CONN_QP);
+#endif
 
 	ret = ipoib_register_debugfs();
 	if (ret)

Yours Tony

linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!

Mel Gorman

2007-11-15 14:50 UTC #21 lore raw

Re: [PATCH] Fix build failure when CONFIG_INFINIBAND_IPOIB_CM is not defined.

On (14/11/07 14:40), Tony Breeds didst pronounce:

Quoted 19 lines

Fixes:
CC [M] drivers/infiniband/ulp/ipoib/ipoib_main.o
drivers/infiniband/ulp/ipoib/ipoib_main.c: In function ???ipoib_init_module???:
drivers/infiniband/ulp/ipoib/ipoib_main.c:1269: error: invalid lvalue in assignment
In the case where CONFIG_INFINIBAND_IPOIB_CM is not defined ipoib_max_conn_qp is #defined to 0.
Signed-off-by Tony Breeds <[email protected]>
---
 drivers/infiniband/ulp/ipoib/ipoib_main.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
drivers/infiniband/ulp/ipoib/ipoib_main.c +0 -0
index 623458e..aeb5a01 100644

drivers/infiniband/ulp/ipoib/ipoib_main.c static int __init ipoib_init_module(void) · line 1270

Quoted 7 lines

drivers/infiniband/ulp/ipoib/ipoib_main.c +2 -1

@@ -1265,8 +1265,9 @@ static int __init ipoib_init_module(void)
 	ipoib_sendq_size = roundup_pow_of_two(ipoib_sendq_size);
 	ipoib_sendq_size = min(ipoib_sendq_size, IPOIB_MAX_QUEUE_SIZE);
 	ipoib_sendq_size = max(ipoib_sendq_size, IPOIB_MIN_QUEUE_SIZE);
-
+#ifdef CONFIG_INFINIBAND_IPOIB_CM
 	ipoib_max_conn_qp = min(ipoib_max_conn_qp, IPOIB_CM_MAX_CONN_QP);
+#endif

The patch fixes the compile although having a variable name #defined as 0 seems a bit of an unexpected suprise.

Either way, when applied with the hotfixes, bl6-13 on
http://test.kernel.org successfully boots.

Quoted 13 lines

drivers/infiniband/ulp/ipoib/ipoib_main.c +0 -0
 	ret = ipoib_register_debugfs();
 	if (ret)
 
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 4 lines

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Gabriel C

2007-11-14 03:41 UTC #22 lore raw

Uff clone-prepare-to-recycle-clone_detached-and-clone_stopped.patch *really* spams. Looks like some programs are using this 'deprecated flag'.

Could this have some CONFIG_SPAM_ME_PLEASE ?;)

This is what I got in some minutes :

--dmesg|grep 'used deprecated clone flags'|sed 's/.*] //'|sort -u fork(): process artsd' used deprecated clone flags 0x400000 fork(): process firefox-bin' used deprecated clone flags 0x400000 fork(): process gcompris' used deprecated clone flags 0x400000 fork(): process qgit' used deprecated clone flags 0x400000 fork(): process thunderbird-bin' used deprecated clone flags 0x400000 fork(): process wish' used deprecated clone flags 0x400000 fork(): process xchat' used deprecated clone flags 0x400000 fork(): process kdbus' used deprecated clone flags 0x400000

--dmesg|grep 'used deprecated clone flags'|wc -l
151

Gabriel

Andrew Morton

author maintainer

2007-11-14 04:56 UTC #23 lore raw

Quoted 18 lines · On Wed, 14 Nov 2007 04:41:38 +0100 Gabriel C <[email protected]> wrote:

Uff clone-prepare-to-recycle-clone_detached-and-clone_stopped.patch *really* spams. Looks like some programs are using this 'deprecated flag'.
Could this have some CONFIG_SPAM_ME_PLEASE ?;)
This is what I got in some minutes :
--dmesg|grep 'used deprecated clone flags'|sed 's/.*] //'|sort -u fork(): process artsd' used deprecated clone flags 0x400000 fork(): process firefox-bin' used deprecated clone flags 0x400000 fork(): process gcompris' used deprecated clone flags 0x400000 fork(): process qgit' used deprecated clone flags 0x400000 fork(): process thunderbird-bin' used deprecated clone flags 0x400000 fork(): process wish' used deprecated clone flags 0x400000 fork(): process xchat' used deprecated clone flags 0x400000 fork(): process kdbus' used deprecated clone flags 0x400000

Quoted 2 lines

--dmesg|grep 'used deprecated clone flags'|wc -l
151

hm, that was supposed to shut itself off after 100 messages:

	if (unlikely(clone_flags & (CLONE_DETACHED|CLONE_STOPPED))) {
		static int __read_mostly count = 100;

		if (count && printk_ratelimit()) {
			char comm[TASK_COMM_LEN];

			count--;
			printk(KERN_INFO "fork(): process `%s' used deprecated "
					"clone flags 0x%lx\n",
				get_task_comm(comm, current),
				clone_flags & (CLONE_DETACHED|CLONE_STOPPED));
		}
	}

I don't see how you got 151 instances. I guess I'm having another stupid day.

Oh well. That's CLONE_DETACHED and I think Ulrich's question just got answered.

Which distro/version are you running?

Thanks for letting us know....

Ulrich Drepper

2007-11-14 05:13 UTC #24 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 4 lines · Andrew Morton

Oh well. That's CLONE_DETACHED and I think Ulrich's question just got answered.
Which distro/version are you running?

People should really compile their glibc better than this. The sources still use it but only if you compile for compatibility with kernels before 2.6.2. Nobody should need to need such backward compatibility.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHOoMs2ijCOnn/RHQRAn+rAJ91vQoJRpuyPJipNLFn+3g6bajDtwCgs9fm moefStvq8QdvOxVLLDPUC1o=
=GsVU
-----END PGP SIGNATURE-----

Gabriel C

2007-11-14 05:27 UTC #25 lore raw

Quoted 39 lines · Andrew Morton

Quoted 18 lines · On Wed, 14 Nov 2007 04:41:38 +0100 Gabriel C <[email protected]> wrote:
Uff clone-prepare-to-recycle-clone_detached-and-clone_stopped.patch *really* spams. Looks like some programs are using this 'deprecated flag'.
Could this have some CONFIG_SPAM_ME_PLEASE ?;)
This is what I got in some minutes :
--dmesg|grep 'used deprecated clone flags'|sed 's/.*] //'|sort -u fork(): process artsd' used deprecated clone flags 0x400000 fork(): process firefox-bin' used deprecated clone flags 0x400000 fork(): process gcompris' used deprecated clone flags 0x400000 fork(): process qgit' used deprecated clone flags 0x400000 fork(): process thunderbird-bin' used deprecated clone flags 0x400000 fork(): process wish' used deprecated clone flags 0x400000 fork(): process xchat' used deprecated clone flags 0x400000 fork(): process kdbus' used deprecated clone flags 0x400000
Quoted 2 lines
--dmesg|grep 'used deprecated clone flags'|wc -l
151
hm, that was supposed to shut itself off after 100 messages:
	if (unlikely(clone_flags & (CLONE_DETACHED|CLONE_STOPPED))) {
		static int __read_mostly count = 100;

		if (count && printk_ratelimit()) {
			char comm[TASK_COMM_LEN];

			count--;
			printk(KERN_INFO "fork(): process `%s' used deprecated "
					"clone flags 0x%lx\n",
				get_task_comm(comm, current),
				clone_flags & (CLONE_DETACHED|CLONE_STOPPED));
		}
	}

Quoted 3 lines

I don't see how you got 151 instances. I guess I'm having another stupid day.

No idea how I got this I just grepped the dmesg =)

Quoted 4 lines

Oh well. That's CLONE_DETACHED and I think Ulrich's question just got answered.
Which distro/version are you running?

I'm using Frugalware Linux 'current' right now with the following software :

-- sh scripts/ver_linux
If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes.

Linux lara 2.6.24-rc2-mm1 #4 SMP Wed Nov 14 05:47:48 CET 2007 i686 Intel(R) Xeon(TM) CPU 2.00GHz GenuineIntel GNU/Linux

 Gnu C                  4.2.2
 Gnu make               3.81
 binutils               2.18.50.0.2.20071001
 util-linux             2.13
 mount                  2.13
 module-init-tools      3.2.2
 e2fsprogs              1.40.2
 xfsprogs               2.9.4
 pcmciautils            014
 Linux C Library        2.7
 Dynamic linker (ldd)   2.7
 Linux C++ Library      so.6.0
 Procps                 3.2.7
 Net-tools              1.60
 Kbd                    1.12
 Sh-utils               6.9
 udev                   116
 Modules Loaded         fuse pc87360 hwmon_vid eeprom adm1021 ext4dev jbd2 crc16 loop lp 3c59x intel_agp mii agpgart sr_mod parport_pc cdrom iTCO_wdt parport thermal dcdbas i82860_edac iTCO_vendor_support evdev i2c_i801 button pcspkr processor edac_core watchdog_core shpchp pci_hotplug watchdog_dev

Quoted 3 lines

Thanks for letting us know....

Zan Lynx

2007-11-14 05:45 UTC #26 lore raw

Andrew Morton wrote:
[cut]

Quoted 16 lines

hm, that was supposed to shut itself off after 100 messages:

	if (unlikely(clone_flags & (CLONE_DETACHED|CLONE_STOPPED))) {
		static int __read_mostly count = 100;

		if (count && printk_ratelimit()) {
			char comm[TASK_COMM_LEN];

			count--;
			printk(KERN_INFO "fork(): process `%s' used deprecated "
					"clone flags 0x%lx\n",
				get_task_comm(comm, current),
				clone_flags & (CLONE_DETACHED|CLONE_STOPPED));
		}
	}

Quoted 2 lines

I don't see how you got 151 instances. I guess I'm having another stupid day.

It looks like a simple race, two threads do count-- before doing if(count), resulting in an almost infinite loop. Probably.

atomic_test_and_dec might work.

Dave Young

2007-11-14 06:18 UTC #27 lore raw

Hi,
Boot failed on my machine. hand copy some messages.

First with BLK_DEV_RAM=y

BUG kmalloc-64 Poison overwritting:
Alloced in kset_create
Freed in kobject_cleanup

--cut--
alloc_disk_node
rd_init
kernel_init
--cut--

Then config ramdisk as module, build and reboot:

BUG: unable handle paging resuest at 6b6b6b6b

EIP is kobject_add 0xc4/0x150

--cut--
kobject_set_name
register_disk
add_disk
exact_match
exact_lock
loop_init
--cut--

Regards
dave
--cut--

Andrew Morton

author maintainer

2007-11-14 06:38 UTC #28 lore raw

Quoted 20 lines · On Wed, 14 Nov 2007 14:18:39 +0800 "Dave Young" <[email protected]>…

Hi,
Boot failed on my machine. hand copy some messages.
First with BLK_DEV_RAM=y
BUG kmalloc-64 Poison overwritting:
Alloced in kset_create
Freed in kobject_cleanup
--cut--
alloc_disk_node
rd_init
kernel_init
--cut--
Then config ramdisk as module, build and reboot:
BUG: unable handle paging resuest at 6b6b6b6b
EIP is kobject_add 0xc4/0x150

Quoted 9 lines

--cut--
kobject_set_name
register_disk
add_disk
exact_match
exact_lock
loop_init
--cut--

erp. Can you send the config over please?

And which distro/version is that machine running?

Thanks.

Dave Young

2007-11-14 06:47 UTC #29 lore raw

Quoted 33 lines · Andrew Morton

Quoted 20 lines · On Wed, 14 Nov 2007 14:18:39 +0800 "Dave Young" <[email protected]>…
Hi,
Boot failed on my machine. hand copy some messages.
First with BLK_DEV_RAM=y
BUG kmalloc-64 Poison overwritting:
Alloced in kset_create
Freed in kobject_cleanup
--cut--
alloc_disk_node
rd_init
kernel_init
--cut--
Then config ramdisk as module, build and reboot:
BUG: unable handle paging resuest at 6b6b6b6b
EIP is kobject_add 0xc4/0x150
Quoted 9 lines
--cut--
kobject_set_name
register_disk
add_disk
exact_match
exact_lock
loop_init
--cut--

Quoted 4 lines

erp. Can you send the config over please?
And which distro/version is that machine running?

Hi,andrew

slackware 11

config as follows:
#
# Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc2-mm1
# Wed Nov 14 13:50:01 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_FAST_CMPXCHG_LOCAL=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
# CONFIG_GENERIC_GPIO is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
# CONFIG_CGROUPS is not set
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_FAIR_USER_SCHED=y
# CONFIG_FAIR_CGROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBD=y
# CONFIG_BLK_DEV_IO_TRACE is not set
CONFIG_LSF=y
CONFIG_BLK_DEV_BSG=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"
CONFIG_PREEMPT_NOTIFIERS=y

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_SMP=y
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_RDC321X is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
# CONFIG_PARAVIRT_GUEST is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MCORE2 is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_X86_XADD=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_NR_CPUS=8
# CONFIG_SCHED_SMT is not set
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=m
# CONFIG_X86_MCE_P4THERMAL is not set
CONFIG_VM86=y
CONFIG_TOSHIBA=m
CONFIG_I8K=m
CONFIG_X86_REBOOTFIXUPS=y
CONFIG_MICROCODE=m
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m

#
# Firmware Drivers
#
CONFIG_EDD=m
CONFIG_DELL_RBU=m
CONFIG_DCDBAS=m
CONFIG_DMIID=y
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_NR_QUICK=1
CONFIG_VIRT_TO_BUS=y
CONFIG_HIGHPTE=y
CONFIG_MATH_EMULATION=y
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_IRQBALANCE=y
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_300=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=300
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
CONFIG_PHYSICAL_START=0x100000
CONFIG_RELOCATABLE=y
CONFIG_PHYSICAL_ALIGN=0x100000
CONFIG_HOTPLUG_CPU=y
CONFIG_COMPAT_VDSO=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_PM_LEGACY=y
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND_SMP_POSSIBLE=y
CONFIG_SUSPEND=y
CONFIG_HIBERNATION_SMP_POSSIBLE=y
# CONFIG_HIBERNATION is not set
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=m
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=m
CONFIG_ACPI_ASUS=m
CONFIG_ACPI_TOSHIBA=m
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=m
# CONFIG_ACPI_SBS is not set
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
# CONFIG_APM_CPU_IDLE is not set
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=m
# CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m

#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=m
CONFIG_X86_POWERNOW_K6=m
CONFIG_X86_POWERNOW_K7=m
CONFIG_X86_POWERNOW_K7_ACPI=y
CONFIG_X86_POWERNOW_K8=m
CONFIG_X86_POWERNOW_K8_ACPI=y
CONFIG_X86_GX_SUSPMOD=m
CONFIG_X86_SPEEDSTEP_CENTRINO=m
CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y
CONFIG_X86_SPEEDSTEP_ICH=m
CONFIG_X86_SPEEDSTEP_SMI=m
CONFIG_X86_P4_CLOCKMOD=m
CONFIG_X86_CPUFREQ_NFORCE2=m
CONFIG_X86_LONGRUN=m
# CONFIG_X86_LONGHAUL is not set
# CONFIG_X86_E_POWERSAVER is not set

# shared options
#
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
CONFIG_X86_SPEEDSTEP_LIB=m
CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK=y
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCIEPORTBUS=y
CONFIG_PCIEAER=y
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
CONFIG_PCI_LEGACY=y
CONFIG_HT_IRQ=y
CONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
CONFIG_K8_NB=y
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=m

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
CONFIG_NET_KEY=m
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
CONFIG_IP_VS=m
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12

#
# IPVS transport protocol load balancing support
#
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y

#
# IPVS scheduler
#
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m

#
# IPVS application helper
#
CONFIG_IP_VS_FTP=m
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETLABEL is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
CONFIG_NF_CONNTRACK_ENABLED=m
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CT_ACCT=y
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_EVENTS=y
# CONFIG_NF_CT_PROTO_SCTP is not set
# CONFIG_NF_CT_PROTO_UDPLITE is not set
# CONFIG_NF_CONNTRACK_AMANDA is not set
# CONFIG_NF_CONNTRACK_FTP is not set
# CONFIG_NF_CONNTRACK_H323 is not set
# CONFIG_NF_CONNTRACK_IRC is not set
# CONFIG_NF_CONNTRACK_NETBIOS_NS is not set
# CONFIG_NF_CONNTRACK_PPTP is not set
# CONFIG_NF_CONNTRACK_SANE is not set
# CONFIG_NF_CONNTRACK_SIP is not set
# CONFIG_NF_CONNTRACK_TFTP is not set
CONFIG_NF_CT_NETLINK=m
CONFIG_NETFILTER_XTABLES=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
# CONFIG_NETFILTER_XT_TARGET_CONNMARK is not set
# CONFIG_NETFILTER_XT_TARGET_DSCP is not set
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
# CONFIG_NETFILTER_XT_TARGET_NFLOG is not set
# CONFIG_NETFILTER_XT_TARGET_NOTRACK is not set
# CONFIG_NETFILTER_XT_TARGET_TRACE is not set
# CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
# CONFIG_NETFILTER_XT_MATCH_CONNBYTES is not set
# CONFIG_NETFILTER_XT_MATCH_CONNLIMIT is not set
# CONFIG_NETFILTER_XT_MATCH_CONNMARK is not set
# CONFIG_NETFILTER_XT_MATCH_CONNTRACK is not set
CONFIG_NETFILTER_XT_MATCH_DCCP=m
# CONFIG_NETFILTER_XT_MATCH_DSCP is not set
CONFIG_NETFILTER_XT_MATCH_ESP=m
# CONFIG_NETFILTER_XT_MATCH_HELPER is not set
CONFIG_NETFILTER_XT_MATCH_LENGTH=m
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
# CONFIG_NETFILTER_XT_MATCH_QUOTA is not set
CONFIG_NETFILTER_XT_MATCH_REALM=m
CONFIG_NETFILTER_XT_MATCH_SCTP=m
# CONFIG_NETFILTER_XT_MATCH_STATE is not set
# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
# CONFIG_NETFILTER_XT_MATCH_TIME is not set
# CONFIG_NETFILTER_XT_MATCH_U32 is not set
# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set

#
# IP: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV4=m
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
CONFIG_NF_NAT_SNMP_BASIC=m
# CONFIG_NF_NAT_FTP is not set
# CONFIG_NF_NAT_IRC is not set
# CONFIG_NF_NAT_TFTP is not set
# CONFIG_NF_NAT_AMANDA is not set
# CONFIG_NF_NAT_PPTP is not set
# CONFIG_NF_NAT_H323 is not set
# CONFIG_NF_NAT_SIP is not set
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
# CONFIG_IP_NF_TARGET_CLUSTERIP is not set
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
# CONFIG_IP_DCCP is not set
CONFIG_IP_SCTP=m
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=y
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
CONFIG_LLC=m
# CONFIG_LLC2 is not set
CONFIG_IPX=m
# CONFIG_IPX_INTERN is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_SCHED is not set
CONFIG_NET_CLS_ROUTE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=m
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
CONFIG_BT_HIDP=m

#
# Bluetooth device drivers
#
# CONFIG_BT_HCIUSB is not set
CONFIG_BT_HCIBTUSB=m
# CONFIG_BT_HCIBTSDIO is not set
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIUART_LL=y
# CONFIG_BT_HCIBCM203X is not set
# CONFIG_BT_HCIBPA10X is not set
# CONFIG_BT_HCIBFUSB is not set
CONFIG_BT_HCIVHCI=m
# CONFIG_AF_RXRPC is not set
CONFIG_FIB_RULES=y

#
# Wireless
#
# CONFIG_CFG80211 is not set
CONFIG_WIRELESS_EXT=y
# CONFIG_MAC80211 is not set
CONFIG_IEEE80211=m
# CONFIG_IEEE80211_DEBUG is not set
# CONFIG_IEEE80211_CRYPT_WEP is not set
# CONFIG_IEEE80211_CRYPT_CCMP is not set
# CONFIG_IEEE80211_CRYPT_TKIP is not set
# CONFIG_IEEE80211_SOFTMAC is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
CONFIG_MTD=m
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set

#
# User Modules And Translation Layers
#
# CONFIG_MTD_CHAR is not set
# CONFIG_MTD_BLKDEVS is not set
# CONFIG_MTD_BLOCK is not set
# CONFIG_MTD_BLOCK_RO is not set
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_MTD_OOPS is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=m
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=m
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_CFI_INTELEXT is not set
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_CFI_STAA is not set
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_PNC2000 is not set
# CONFIG_MTD_NETSC520 is not set
# CONFIG_MTD_TS5500 is not set
# CONFIG_MTD_INTEL_VR_NOR is not set
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
# CONFIG_MTD_NAND is not set
# CONFIG_MTD_ONENAND is not set

#
# UBI - Unsorted block images
#
# CONFIG_MTD_UBI is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
CONFIG_CDROM_PKTCDVD=y
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
# CONFIG_ATA_OVER_ETH is not set
CONFIG_MISC_DEVICES=y
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ASUS_LAPTOP is not set
# CONFIG_FUJITSU_LAPTOP is not set
# CONFIG_MSI_LAPTOP is not set
# CONFIG_SONY_LAPTOP is not set
# CONFIG_THINKPAD_ACPI is not set
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives #
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDETAPE=m
CONFIG_BLK_DEV_IDEFLOPPY=y
CONFIG_BLK_DEV_IDESCSI=y
# CONFIG_BLK_DEV_IDEACPI is not set
# CONFIG_IDE_TASK_IOCTL is not set CONFIG_IDE_PROC_FS=y

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_PLATFORM is not set
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set

#
# PCI IDE chipsets support
#
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_PCIBUS_ORDER=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_AEC62XX=y
CONFIG_BLK_DEV_ALI15X3=y
# CONFIG_WDC_ALI15X3 is not set
CONFIG_BLK_DEV_AMD74XX=y
CONFIG_BLK_DEV_ATIIXP=y
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_TRIFLEX=y
CONFIG_BLK_DEV_CY82C693=y
CONFIG_BLK_DEV_CS5520=y
CONFIG_BLK_DEV_CS5530=y
CONFIG_BLK_DEV_CS5535=y
CONFIG_BLK_DEV_HPT34X=y
# CONFIG_HPT34X_AUTODMA is not set
CONFIG_BLK_DEV_HPT366=y
# CONFIG_BLK_DEV_JMICRON is not set
CONFIG_BLK_DEV_SC1200=y
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_IT8213 is not set
CONFIG_BLK_DEV_IT821X=y
# CONFIG_BLK_DEV_NS87415 is not set
CONFIG_BLK_DEV_PDC202XX_OLD=y
CONFIG_PDC202XX_BURST=y
CONFIG_BLK_DEV_PDC202XX_NEW=y
CONFIG_BLK_DEV_SVWKS=y
CONFIG_BLK_DEV_SIIMAGE=y
CONFIG_BLK_DEV_SIS5513=y
CONFIG_BLK_DEV_SLC90E66=y
CONFIG_BLK_DEV_TRM290=m
CONFIG_BLK_DEV_VIA82CXXX=y
# CONFIG_BLK_DEV_TC86C001 is not set
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDE_ARCH_OBSOLETE_INIT=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
CONFIG_CHR_DEV_SCH=m

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs #
CONFIG_SCSI_MULTI_LUN=y
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set CONFIG_SCSI_WAIT_SCAN=m

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=y
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=y
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_SRP is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_ACPI=y
CONFIG_SATA_AHCI=y
# CONFIG_SATA_SVW is not set
CONFIG_ATA_PIIX=y
CONFIG_SATA_MV=y
CONFIG_SATA_NV=y
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
CONFIG_SATA_SIL=y
CONFIG_SATA_SIL24=y
CONFIG_SATA_SIS=y
CONFIG_SATA_ULI=y
CONFIG_SATA_VIA=y
CONFIG_SATA_VITESSE=y
# CONFIG_SATA_INIC162X is not set
# CONFIG_PATA_ACPI is not set
CONFIG_PATA_ALI=y
CONFIG_PATA_AMD=y
CONFIG_PATA_ARTOP=y
CONFIG_PATA_ATIIXP=y
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5535 is not set
# CONFIG_PATA_CS5536 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
CONFIG_ATA_GENERIC=y
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
CONFIG_PATA_MPIIX=y
CONFIG_PATA_OLDPIIX=y
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
CONFIG_PATA_SIS=y
CONFIG_PATA_VIA=y
# CONFIG_PATA_WINBOND is not set
# CONFIG_MD is not set
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
CONFIG_I2O=y
CONFIG_I2O_LCT_NOTIFY_ON_CHANGES=y
CONFIG_I2O_EXT_ADAPTEC=y
CONFIG_I2O_CONFIG=y
# CONFIG_I2O_CONFIG_OLD_IOCTL is not set
CONFIG_I2O_BUS=y
CONFIG_I2O_BLOCK=y
CONFIG_I2O_SCSI=y
CONFIG_I2O_PROC=y
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
CONFIG_VETH=m
# CONFIG_NET_SB1000 is not set
# CONFIG_IP1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_PHYLIB is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
CONFIG_EEPRO100=m
CONFIG_E100=m
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_SC92031 is not set
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set

#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
# CONFIG_WLAN_80211 is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=y
CONFIG_INPUT_POLLDEV=m

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
CONFIG_INPUT_EVDEV=m
CONFIG_INPUT_EVBUG=m

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=m
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_PS2_ELANTECH is not set
CONFIG_MOUSE_SERIAL=m
# CONFIG_MOUSE_APPLETOUCH is not set
CONFIG_MOUSE_VSXXXAA=m
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
CONFIG_JOYSTICK_A3D=m
CONFIG_JOYSTICK_ADI=m
CONFIG_JOYSTICK_COBRA=m
CONFIG_JOYSTICK_GF2K=m
CONFIG_JOYSTICK_GRIP=m
CONFIG_JOYSTICK_GRIP_MP=m
CONFIG_JOYSTICK_GUILLEMOT=m
CONFIG_JOYSTICK_INTERACT=m
CONFIG_JOYSTICK_SIDEWINDER=m
CONFIG_JOYSTICK_TMDC=m
CONFIG_JOYSTICK_IFORCE=m
# CONFIG_JOYSTICK_IFORCE_USB is not set
CONFIG_JOYSTICK_IFORCE_232=y
CONFIG_JOYSTICK_WARRIOR=m
CONFIG_JOYSTICK_MAGELLAN=m
CONFIG_JOYSTICK_SPACEORB=m
CONFIG_JOYSTICK_SPACEBALL=m
CONFIG_JOYSTICK_STINGER=m
CONFIG_JOYSTICK_TWIDJOY=m
CONFIG_JOYSTICK_JOYDUMP=m
# CONFIG_JOYSTICK_XPAD is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
# CONFIG_INPUT_APANEL is not set
CONFIG_INPUT_WISTRON_BTNS=m
# CONFIG_INPUT_ATLAS_BTNS is not set
# CONFIG_INPUT_ATI_REMOTE is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
CONFIG_INPUT_UINPUT=m

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=m
CONFIG_SERIO_CT82C710=m
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=m
CONFIG_GAMEPORT=m
CONFIG_GAMEPORT_NS558=m
CONFIG_GAMEPORT_L4=m
CONFIG_GAMEPORT_EMU10K1=m
CONFIG_GAMEPORT_FM801=m

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_JSM=m
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_HVC_DRIVER=y
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_SI=m
CONFIG_IPMI_WATCHDOG=m
CONFIG_IPMI_POWEROFF=m
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_INTEL=y
CONFIG_HW_RANDOM_AMD=y
CONFIG_HW_RANDOM_GEODE=y
CONFIG_HW_RANDOM_VIA=y
CONFIG_NVRAM=m
CONFIG_RTC=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
CONFIG_HANGCHECK_TIMER=m
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m

#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI1563=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD756_S4882=m
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_I810=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_NFORCE2=m
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_PARPORT_LIGHT=m
CONFIG_I2C_PROSAVAGE=m
CONFIG_I2C_SAVAGE4=m
# CONFIG_I2C_SIMTEC is not set
CONFIG_SCx200_ACB=m
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
CONFIG_I2C_SIS96X=m
# CONFIG_I2C_TAOS_EVM is not set
CONFIG_I2C_STUB=m
# CONFIG_I2C_TINY_USB is not set
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
CONFIG_I2C_VOODOO3=m

#
# Miscellaneous I2C Chip support
#
CONFIG_DS1682=y
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
# CONFIG_PCF8575 is not set
CONFIG_SENSORS_PCA9539=m
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_MAX6875=m
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_BATTERY_DS2760 is not set
# CONFIG_HWMON is not set
# CONFIG_WATCHDOG is not set

#
# Sonics Silicon Backplane
#
CONFIG_SSB_POSSIBLE=y
# CONFIG_SSB is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
# CONFIG_DAB is not set

#
# Graphics support
#
CONFIG_AGP=m
CONFIG_AGP_ALI=m
CONFIG_AGP_ATI=m
CONFIG_AGP_AMD=m
CONFIG_AGP_AMD64=m
CONFIG_AGP_INTEL=m
CONFIG_AGP_NVIDIA=m
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
CONFIG_AGP_VIA=m
# CONFIG_AGP_EFFICEON is not set
CONFIG_DRM=m
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
CONFIG_DRM_RADEON=m
CONFIG_DRM_I810=m
CONFIG_DRM_I830=m
CONFIG_DRM_I915=m
CONFIG_DRM_MGA=m
CONFIG_DRM_SIS=m
CONFIG_DRM_VIA=m
CONFIG_DRM_SAVAGE=m
CONFIG_VGASTATE=m
CONFIG_VIDEO_OUTPUT_CONTROL=m
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DDC=m
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_SYS_FOPS is not set
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
CONFIG_FB_BACKLIGHT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
CONFIG_FB_VGA16=m
CONFIG_FB_VESA=y
# CONFIG_FB_EFI is not set
# CONFIG_FB_HECUBA is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
CONFIG_FB_NVIDIA=m
CONFIG_FB_NVIDIA_I2C=y
# CONFIG_FB_NVIDIA_DEBUG is not set
CONFIG_FB_NVIDIA_BACKLIGHT=y
# CONFIG_FB_RIVA is not set
CONFIG_FB_I810=m
CONFIG_FB_I810_GTF=y
CONFIG_FB_I810_I2C=y
# CONFIG_FB_LE80578 is not set
CONFIG_FB_INTEL=m
# CONFIG_FB_INTEL_DEBUG is not set
CONFIG_FB_INTEL_I2C=y
# CONFIG_FB_MATROX is not set
CONFIG_FB_RADEON=m
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_BACKLIGHT=y
CONFIG_FB_RADEON_DEBUG=y
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_CYBLA is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=m
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_CORGI is not set
# CONFIG_BACKLIGHT_PROGEAR is not set

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y CONFIG_VGACON_SOFT_SCROLLBACK=y CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64 CONFIG_VIDEO_SELECT=y
CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set CONFIG_FONTS=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_FONT_6x11 is not set
# CONFIG_FONT_7x14 is not set
# CONFIG_FONT_PEARL_8x8 is not set
# CONFIG_FONT_ACORN_8x8 is not set
# CONFIG_FONT_MINI_4x6 is not set
# CONFIG_FONT_SUN8x16 is not set
# CONFIG_FONT_SUN12x22 is not set
# CONFIG_FONT_10x18 is not set
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set CONFIG_LOGO_LINUX_CLUT224=y

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_MPU401_UART=m
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTPAV=m
CONFIG_SND_SERIAL_U16550=m
CONFIG_SND_MPU401=m

#
# PCI devices
#
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5530 is not set
# CONFIG_SND_CS5535AUDIO is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
CONFIG_SND_HDA_INTEL=m
# CONFIG_SND_HDA_HWDEP is not set
CONFIG_SND_HDA_CODEC_REALTEK=y
CONFIG_SND_HDA_CODEC_ANALOG=y
CONFIG_SND_HDA_CODEC_SIGMATEL=y
CONFIG_SND_HDA_CODEC_VIA=y
CONFIG_SND_HDA_CODEC_ATIHDMI=y
CONFIG_SND_HDA_CODEC_CONEXANT=y
CONFIG_SND_HDA_CODEC_CMEDIA=y
CONFIG_SND_HDA_CODEC_SI3054=y
CONFIG_SND_HDA_GENERIC=y
# CONFIG_SND_HDA_POWER_SAVE is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set

#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set
# CONFIG_SND_USB_CAIAQ is not set

#
# System on Chip audio support
#
# CONFIG_SND_SOC is not set

#
# SoC Audio support for SuperH
#

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
CONFIG_HID_DEBUG=y
# CONFIG_HIDRAW is not set

#
# USB Input Devices
#
CONFIG_USB_HID=y
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
CONFIG_HID_FF=y
CONFIG_HID_PID=y
CONFIG_LOGITECH_FF=y
# CONFIG_PANTHERLORD_FF is not set
# CONFIG_THRUSTMASTER_FF is not set
# CONFIG_ZEROPLUS_FF is not set
CONFIG_USB_HIDDEV=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_DEVICE_CLASS=y
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
# CONFIG_USB_PERSIST is not set
# CONFIG_USB_OTG is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' #

# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_USB_STORAGE_DPCM=y
CONFIG_USB_STORAGE_USBAT=y
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y
CONFIG_USB_STORAGE_ALAUDA=y
CONFIG_USB_STORAGE_KARMA=y
CONFIG_USB_LIBUSUAL=y

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_MON is not set

#
# USB port drivers
#

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set

#
# USB DSL modem support
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
CONFIG_MMC=m
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
# CONFIG_MMC_PASSWORDS is not set

#
# MMC/SD Card Drivers
#
CONFIG_MMC_BLOCK=m
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set

#
# MMC/SD Host Controller Drivers
#
# CONFIG_MMC_SDHCI is not set
# CONFIG_MMC_WBSD is not set
# CONFIG_MMC_TIFM_SD is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=m

#
# LED drivers
#
# CONFIG_LEDS_CLEVO_MAIL is not set

#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_LEDS_TRIGGER_IDE_DISK=y
# CONFIG_LEDS_TRIGGER_HEARTBEAT is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=m
CONFIG_RTC_CLASS=m

#
# Conflicting RTC option has been selected, check GEN_RTC and RTC #

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
CONFIG_RTC_DRV_TEST=m

#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
CONFIG_RTC_DRV_DS1672=m
# CONFIG_RTC_DRV_MAX6900 is not set
CONFIG_RTC_DRV_RS5C372=m
# CONFIG_RTC_DRV_ISL1208 is not set
CONFIG_RTC_DRV_X1205=m
CONFIG_RTC_DRV_PCF8563=m
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set

#
# SPI RTC drivers
#

#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=m
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
CONFIG_RTC_DRV_M48T86=m
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_V3020 is not set

#
# on-CPU RTC drivers
#
# CONFIG_DMADEVICES is not set
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
CONFIG_KVM_AMD=m
CONFIG_LGUEST=y

#
# Userspace I/O
#
# CONFIG_UIO is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=y
CONFIG_FS_MBCACHE=y
# CONFIG_REISER4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_QUOTA=y
# CONFIG_QUOTA_NETLINK_INTERFACE is not set
CONFIG_PRINT_QUOTA_WARNING=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=m
CONFIG_QUOTACTL=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_FUSE_FS=m

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=y
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set

#
# Layered filesystems
#
# CONFIG_ECRYPT_FS is not set
# CONFIG_UNION_FS is not set

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS2_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_SMB_FS is not set
CONFIG_CIFS=m
# CONFIG_CIFS_STATS is not set
# CONFIG_CIFS_WEAK_PW_HASH is not set
# CONFIG_CIFS_XATTR is not set
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
CONFIG_NLS_CODEPAGE_936=m
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y
# CONFIG_DLM is not set
# CONFIG_INSTRUMENTATION is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_UNUSED_SYMBOLS=y
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_KERNEL is not set
CONFIG_SLUB_DEBUG_ON=y
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_PROFILE_LIKELY is not set
# CONFIG_SAMPLES is not set
CONFIG_EARLY_PRINTK=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_DOUBLEFAULT=y

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
# CONFIG_SECURITY_NETWORK_XFRM is not set
# CONFIG_SECURITY_CAPABILITIES is not set
# CONFIG_SECURITY_ROOTPLUG is not set
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=m
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_TGR192=m
# CONFIG_CRYPTO_GF128MUL is not set
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_PCBC=m
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_XTS is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_DES=m
# CONFIG_CRYPTO_FCRYPT is not set
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
# CONFIG_CRYPTO_TWOFISH_586 is not set
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_586=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_ANUBIS=m
# CONFIG_CRYPTO_SEED is not set
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CAMELLIA is not set
CONFIG_CRYPTO_TEST=m
# CONFIG_CRYPTO_AUTHENC is not set
CONFIG_CRYPTO_HW=y
CONFIG_CRYPTO_DEV_PADLOCK=m
CONFIG_CRYPTO_DEV_PADLOCK_AES=m
CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
CONFIG_CRYPTO_DEV_GEODE=m
# CONFIG_CRYPTO_DEV_HIFN_795X is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CHECK_SIGNATURE=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_KTIME_SCALAR=y

Andrew Morton

author maintainer

2007-11-14 08:42 UTC #30 lore raw

Quoted 41 lines · On Wed, 14 Nov 2007 14:47:38 +0800 "Dave Young" <[email protected]>…

Quoted 33 lines · Andrew Morton
Quoted 20 lines · On Wed, 14 Nov 2007 14:18:39 +0800 "Dave Young" <[email protected]>…
Hi,
Boot failed on my machine. hand copy some messages.
First with BLK_DEV_RAM=y
BUG kmalloc-64 Poison overwritting:
Alloced in kset_create
Freed in kobject_cleanup
--cut--
alloc_disk_node
rd_init
kernel_init
--cut--
Then config ramdisk as module, build and reboot:
BUG: unable handle paging resuest at 6b6b6b6b
EIP is kobject_add 0xc4/0x150
Quoted 9 lines
--cut--
kobject_set_name
register_disk
add_disk
exact_match
exact_lock
loop_init
--cut--
Quoted 4 lines
erp. Can you send the config over please?
And which distro/version is that machine running?
Hi,andrew

Quoted 8 lines

slackware 11
config as follows:
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24-rc2-mm1
# Wed Nov 14 13:50:01 2007
#

OK, I can reproduce that on the Vaio, thanks.

oops: http://userweb.kernel.org/~akpm/dsc00037.jpg
config: (what you sent)
dmesg: http://userweb.kernel.org/~akpm/dmesg-sony.txt

An inspired guess led me to suspect the driver tree. The offending patch is gregkh-driver-kset-convert-block_subsys-to-use-kset_create.patch.

There's some kobject warning which comes out when gregkh-driver-kset-convert-block_subsys-to-use-kset_create.patch isn't applied. More bisecting coming up..

Andrew Morton

author maintainer

2007-11-14 09:32 UTC #31 lore raw

Quoted 3 lines · On Wed, 14 Nov 2007 00:41:29 -0800 Andrew Morton <[email protected]>…

There's some kobject warning which comes out when gregkh-driver-kset-convert-block_subsys-to-use-kset_create.patch isn't applied. More bisecting coming up..

[   11.863390] ACPI: AC Adapter [ACAD] (on-line)
[   11.868004] ACPI: Battery Slot [BAT1] (battery present)
[   11.922945] Real Time Clock Driver v1.12ac
[   11.923078] intel_rng: FWH not detected
[   11.923160] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
[   14.934078] floppy0: no floppy controllers found
[   14.934616] WARNING: at lib/kref.c:33 kref_get()
[   14.934690]  [<c0242810>] kref_get+0x40/0x50
[   14.934766]  [<c024185f>] kobject_get+0xf/0x20
[   14.934839]  [<c0241e7f>] kobject_add+0x14f/0x1a0
[   14.934917]  [<c0241c8e>] kobject_set_name+0x7e/0xc0
[   14.934998]  [<c01b82af>] register_disk+0x3f/0x200
[   14.935078]  [<c02392ff>] blk_register_region+0x2f/0x40
[   14.935164]  [<c0239349>] add_disk+0x39/0x50
[   14.935234]  [<c0238b80>] exact_match+0x0/0x10
[   14.935306]  [<c0239120>] exact_lock+0x0/0x10
[   14.935378]  [<c051b73b>] loop_init+0x13b/0x190
[   14.935453]  [<c0500570>] kernel_init+0x130/0x300
[   14.935532]  [<c010428e>] ret_from_fork+0x6/0x1c
[   14.938302]  [<c0500440>] kernel_init+0x0/0x300
[   14.941033]  [<c0500440>] kernel_init+0x0/0x300
[   14.943732]  [<c0104f8f>] kernel_thread_helper+0x7/0x18
[   14.946436]  =======================
[   14.949535] loop: module loaded
[   14.952336] e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
[   14.955022] e100: Copyright(c) 1999-2006 Intel Corporation
[   14.957813] ACPI: PCI Interrupt 0000:06:08.0[A] -> GSI 20 (level, low) -> IRQ

Caused by gregkh-driver-remove-struct-kobj_type-from-struct-kset.patch

Dave Young

2007-11-14 09:36 UTC #32 lore raw

Quoted 53 lines · Andrew Morton

Quoted 41 lines · On Wed, 14 Nov 2007 14:47:38 +0800 "Dave Young" <[email protected]>…
Quoted 33 lines · Andrew Morton
Quoted 20 lines · On Wed, 14 Nov 2007 14:18:39 +0800 "Dave Young" <[email protected]>…
Hi,
Boot failed on my machine. hand copy some messages.
First with BLK_DEV_RAM=y
BUG kmalloc-64 Poison overwritting:
Alloced in kset_create
Freed in kobject_cleanup
--cut--
alloc_disk_node
rd_init
kernel_init
--cut--
Then config ramdisk as module, build and reboot:
BUG: unable handle paging resuest at 6b6b6b6b
EIP is kobject_add 0xc4/0x150
Quoted 9 lines
--cut--
kobject_set_name
register_disk
add_disk
exact_match
exact_lock
loop_init
--cut--
Quoted 4 lines
erp. Can you send the config over please?
And which distro/version is that machine running?
Hi,andrew
Quoted 8 lines
slackware 11
config as follows:
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24-rc2-mm1
# Wed Nov 14 13:50:01 2007
#

Quoted 9 lines

OK, I can reproduce that on the Vaio, thanks.
oops: http://userweb.kernel.org/~akpm/dsc00037.jpg
config: (what you sent)
dmesg: http://userweb.kernel.org/~akpm/dmesg-sony.txt
An inspired guess led me to suspect the driver tree. The offending patch is gregkh-driver-kset-convert-block_subsys-to-use-kset_create.patch.

Hi,
I do some printk debug, the problem hide in the kobject.c line 256 in kobject_add
seems at
list_add_tail(&kobj->entry,&kobj->kset->list);

Regards
dave

Greg KH

2007-11-14 17:06 UTC #33 lore raw

Quoted 60 lines · Dave Young

Quoted 59 lines · Andrew Morton
Quoted 41 lines · On Wed, 14 Nov 2007 14:47:38 +0800 "Dave Young" <[email protected]>…
Quoted 33 lines · Andrew Morton
Quoted 20 lines · On Wed, 14 Nov 2007 14:18:39 +0800 "Dave Young" <[email protected]>…
Hi,
Boot failed on my machine. hand copy some messages.
First with BLK_DEV_RAM=y
BUG kmalloc-64 Poison overwritting:
Alloced in kset_create
Freed in kobject_cleanup
--cut--
alloc_disk_node
rd_init
kernel_init
--cut--
Then config ramdisk as module, build and reboot:
BUG: unable handle paging resuest at 6b6b6b6b
EIP is kobject_add 0xc4/0x150
Quoted 9 lines
--cut--
kobject_set_name
register_disk
add_disk
exact_match
exact_lock
loop_init
--cut--
Quoted 4 lines
erp. Can you send the config over please?
And which distro/version is that machine running?
Hi,andrew
Quoted 8 lines
slackware 11
config as follows:
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24-rc2-mm1
# Wed Nov 14 13:50:01 2007
#
OK, I can reproduce that on the Vaio, thanks.
oops: http://userweb.kernel.org/~akpm/dsc00037.jpg
config: (what you sent)
dmesg: http://userweb.kernel.org/~akpm/dmesg-sony.txt

Quoted 8 lines

Quoted 3 lines
An inspired guess led me to suspect the driver tree. The offending patch is gregkh-driver-kset-convert-block_subsys-to-use-kset_create.patch.
Hi,
I do some printk debug, the problem hide in the kobject.c line 256 in kobject_add
seems at
list_add_tail(&kobj->entry,&kobj->kset->list);

That's just wierd. I'll try to figure this out...

Kay, any thoughts, I can use any hint anyone has here :)

thanks,

greg k-h

Kay Sievers

2007-11-14 18:38 UTC #34 lore raw

Quoted 70 lines · Greg KH

Quoted 60 lines · Dave Young
Quoted 59 lines · Andrew Morton
Quoted 41 lines · On Wed, 14 Nov 2007 14:47:38 +0800 "Dave Young" <[email protected]>…
Quoted 33 lines · Andrew Morton
Quoted 20 lines · On Wed, 14 Nov 2007 14:18:39 +0800 "Dave Young" <[email protected]>…
Hi,
Boot failed on my machine. hand copy some messages.
First with BLK_DEV_RAM=y
BUG kmalloc-64 Poison overwritting:
Alloced in kset_create
Freed in kobject_cleanup
--cut--
alloc_disk_node
rd_init
kernel_init
--cut--
Then config ramdisk as module, build and reboot:
BUG: unable handle paging resuest at 6b6b6b6b
EIP is kobject_add 0xc4/0x150
Quoted 9 lines
--cut--
kobject_set_name
register_disk
add_disk
exact_match
exact_lock
loop_init
--cut--
Quoted 4 lines
erp. Can you send the config over please?
And which distro/version is that machine running?
Hi,andrew
Quoted 8 lines
slackware 11
config as follows:
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24-rc2-mm1
# Wed Nov 14 13:50:01 2007
#
OK, I can reproduce that on the Vaio, thanks.
oops: http://userweb.kernel.org/~akpm/dsc00037.jpg
config: (what you sent)
dmesg: http://userweb.kernel.org/~akpm/dmesg-sony.txt
Quoted 8 lines
Quoted 3 lines
An inspired guess led me to suspect the driver tree. The offending patch is gregkh-driver-kset-convert-block_subsys-to-use-kset_create.patch.
Hi,
I do some printk debug, the problem hide in the kobject.c line 256 in kobject_add
seems at
list_add_tail(&kobj->entry,&kobj->kset->list);

Quoted 3 lines

That's just wierd. I'll try to figure this out...
Kay, any thoughts, I can use any hint anyone has here :)

Hmm, I tried to reproduce, but none of my boxes shows that.

Could it be an init-order problem, where something tries to use the block subsystem? Before it is initialized with:
block/genhd.c :: subsys_initcall(genhd_device_init);

If that's the case, we have an old bug that nobody noticed with static structures, which are zeroed that time, but definitely not properly initialized.

I'll try to build loop non-modular now, and see if that makes the bug appear here.

Kay

Jiri Kosina

2007-11-14 19:20 UTC #35 lore raw

Quoted 7 lines · Kay Sievers

Could it be an init-order problem, where something tries to use the block subsystem? Before it is initialized with:
block/genhd.c :: subsys_initcall(genhd_device_init);
If that's the case, we have an old bug that nobody noticed with static structures, which are zeroed that time, but definitely not properly initialized. I'll try to build loop non-modular now, and see if that makes the bug appear here.

Hi Kay,

my .config with which I reproduc this on 2.6.24-rc2-mm1 reliably can be obtained from http://www.jikos.cz/jikos/junk/.config

Signature · 1 line

Jiri Kosina

Kay Sievers

2007-11-14 21:27 UTC #36 lore raw

Quoted 10 lines · Jiri Kosina

Quoted 7 lines · Kay Sievers
Could it be an init-order problem, where something tries to use the block subsystem? Before it is initialized with:
block/genhd.c :: subsys_initcall(genhd_device_init);
If that's the case, we have an old bug that nobody noticed with static structures, which are zeroed that time, but definitely not properly initialized. I'll try to build loop non-modular now, and see if that makes the bug appear here.

Quoted 2 lines

my .config with which I reproduc this on 2.6.24-rc2-mm1 reliably can be obtained from http://www.jikos.cz/jikos/junk/.config

Hmm, that config doesn't do anything here, and if I make it boot, it does not show the bug.

Could you possibly enable kobject debugging and see if that exposes something, maybe something goes wrong with the kset refcount and it gets released while in use.

Kay

Dave Young

2007-11-15 01:01 UTC #37 lore raw

Quoted 14 lines · Kay Sievers

Quoted 10 lines · Jiri Kosina
Quoted 7 lines · Kay Sievers
Could it be an init-order problem, where something tries to use the block subsystem? Before it is initialized with:
block/genhd.c :: subsys_initcall(genhd_device_init);
If that's the case, we have an old bug that nobody noticed with static structures, which are zeroed that time, but definitely not properly initialized. I'll try to build loop non-modular now, and see if that makes the bug appear here.
Quoted 2 lines
my .config with which I reproduc this on 2.6.24-rc2-mm1 reliably can be obtained from http://www.jikos.cz/jikos/junk/.config

Quoted 7 lines

Hmm, that config doesn't do anything here, and if I make it boot, it does not show the bug.
Could you possibly enable kobject debugging and see if that exposes something, maybe something goes wrong with the kset refcount and it gets released while in use.

Hi,
I would do that.
BTW, The bug report as EIP at __list_add with CONFIG_DEBUG_LIST=y

Regards
dave

Kay Sievers

2007-11-15 02:37 UTC #38 lore raw

Quoted 18 lines · Dave Young

Quoted 17 lines · Kay Sievers
Quoted 10 lines · Jiri Kosina
Quoted 7 lines · Kay Sievers
Could it be an init-order problem, where something tries to use the block subsystem? Before it is initialized with:
block/genhd.c :: subsys_initcall(genhd_device_init);
If that's the case, we have an old bug that nobody noticed with static structures, which are zeroed that time, but definitely not properly initialized. I'll try to build loop non-modular now, and see if that makes the bug appear here.
Quoted 2 lines
my .config with which I reproduc this on 2.6.24-rc2-mm1 reliably can be obtained from http://www.jikos.cz/jikos/junk/.config
Hmm, that config doesn't do anything here, and if I make it boot, it does not show the bug.

Quoted 6 lines

Quoted 4 lines
Could you possibly enable kobject debugging and see if that exposes something, maybe something goes wrong with the kset refcount and it gets released while in use.
Hi,
I would do that.

That would be great.

Quoted 1 line

BTW, The bug report as EIP at __list_add with CONFIG_DEBUG_LIST=y

Yeah, that hints that the kset, which contains the list, is not allocated at the time it is used, or it is already released (kfree) again by some buggy logic.

All this could not happen before, as the kset was statically in memory. It may be an old bug, that just never crashed anything. We already fixed a bunch of similar things, that showed up while doing this patch set.

Thanks,
Kay

Dave Young

2007-11-15 03:11 UTC #39 lore raw

Quoted 31 lines · Kay Sievers

Quoted 18 lines · Dave Young
Quoted 17 lines · Kay Sievers
Quoted 10 lines · Jiri Kosina
Quoted 7 lines · Kay Sievers
Could it be an init-order problem, where something tries to use the block subsystem? Before it is initialized with:
block/genhd.c :: subsys_initcall(genhd_device_init);
If that's the case, we have an old bug that nobody noticed with static structures, which are zeroed that time, but definitely not properly initialized. I'll try to build loop non-modular now, and see if that makes the bug appear here.
Quoted 2 lines
my .config with which I reproduc this on 2.6.24-rc2-mm1 reliably can be obtained from http://www.jikos.cz/jikos/junk/.config
Hmm, that config doesn't do anything here, and if I make it boot, it does not show the bug.
Quoted 6 lines
Quoted 4 lines
Could you possibly enable kobject debugging and see if that exposes something, maybe something goes wrong with the kset refcount and it gets released while in use.
Hi,
I would do that.
That would be great.
Quoted 1 line
BTW, The bug report as EIP at __list_add with CONFIG_DEBUG_LIST=y

Quoted 8 lines

Yeah, that hints that the kset, which contains the list, is not allocated at the time it is used, or it is already released (kfree) again by some buggy logic.
All this could not happen before, as the kset was statically in memory. It may be an old bug, that just never crashed anything. We already fixed a bunch of similar things, that showed up while doing this patch set.

Now with the DEBUG_KOBJECT set , nothing more info.
But this time the EIP is at the strnlen (called by printk -- line 239 of kobject.c)

EIP is at strnlen +0x9/0x20
EAX 6b6b6b6b EBX c05487c14 ecx 6b6b6b6b EDX fffffffe ---cut---

If you need more infomation, I will copy more (no camera in hand)

Regards
dave

Dave Young

2007-11-15 08:08 UTC #40 lore raw

In reply to Kay Sievers

Quoted 26 lines · Kay Sievers

Quoted 18 lines · Dave Young
Quoted 17 lines · Kay Sievers
Quoted 10 lines · Jiri Kosina
Quoted 7 lines · Kay Sievers
Could it be an init-order problem, where something tries to use the block subsystem? Before it is initialized with:
block/genhd.c :: subsys_initcall(genhd_device_init);
If that's the case, we have an old bug that nobody noticed with static structures, which are zeroed that time, but definitely not properly initialized. I'll try to build loop non-modular now, and see if that makes the bug appear here.
Quoted 2 lines
my .config with which I reproduc this on 2.6.24-rc2-mm1 reliably can be obtained from http://www.jikos.cz/jikos/junk/.config
Hmm, that config doesn't do anything here, and if I make it boot, it does not show the bug.
Quoted 6 lines
Quoted 4 lines
Could you possibly enable kobject debugging and see if that exposes something, maybe something goes wrong with the kset refcount and it gets released while in use.
Hi,
I would do that.

Quoted 7 lines

That would be great.
Quoted 1 line
BTW, The bug report as EIP at __list_add with CONFIG_DEBUG_LIST=y
Yeah, that hints that the kset, which contains the list, is not allocated at the time it is used, or it is already released (kfree) again by some buggy logic.

Yes, I debugged it, there's some new findings.
It is freed by put_disk.
The floppy driver alloc_disk and then call put_disk without register_disk. in kobject_cleanup line 551:
if(s)

	kset_put(s);

Now the kset is set in alloc_disk after kobject_init, so it is not refereced yet. please try this patch:

block/genhd.c | 2 +-

1 file changed, 1 insertion(+), 1 deletion(-)

block/genhd.c +1 -1

diff -upr linux/block/genhd.c linux.new/block/genhd.c
@@ -718,9 +718,9 @@ struct gendisk *alloc_disk_node(int mino
 			}
 		}
 		disk->minors = minors;
-		kobject_init(&disk->kobj);
 		disk->kobj.kset = block_kset;
 		disk->kobj.ktype = &ktype_block;
+		kobject_init(&disk->kobj);
 		rand_initialize_disk(disk);
 		INIT_WORK(&disk->async_notify,
 			media_change_notify_thread);

Kay Sievers

2007-11-15 08:51 UTC #41 lore raw

Quoted 35 lines · Dave Young

Quoted 26 lines · Kay Sievers
Quoted 18 lines · Dave Young
Quoted 17 lines · Kay Sievers
Quoted 10 lines · Jiri Kosina
Quoted 7 lines · Kay Sievers
Could it be an init-order problem, where something tries to use the block subsystem? Before it is initialized with:
block/genhd.c :: subsys_initcall(genhd_device_init);
If that's the case, we have an old bug that nobody noticed with static structures, which are zeroed that time, but definitely not properly initialized. I'll try to build loop non-modular now, and see if that makes the bug appear here.
Quoted 2 lines
my .config with which I reproduc this on 2.6.24-rc2-mm1 reliably can be obtained from http://www.jikos.cz/jikos/junk/.config
Hmm, that config doesn't do anything here, and if I make it boot, it does not show the bug.
Quoted 6 lines
Quoted 4 lines
Could you possibly enable kobject debugging and see if that exposes something, maybe something goes wrong with the kset refcount and it gets released while in use.
Hi,
I would do that.
Quoted 7 lines
That would be great.
Quoted 1 line
BTW, The bug report as EIP at __list_add with CONFIG_DEBUG_LIST=y
Yeah, that hints that the kset, which contains the list, is not allocated at the time it is used, or it is already released (kfree) again by some buggy logic.

Quoted 7 lines

Yes, I debugged it, there's some new findings.
It is freed by put_disk.
The floppy driver alloc_disk and then call put_disk without register_disk. in kobject_cleanup line 551:
if(s)
	kset_put(s);
Now the kset is set in alloc_disk after kobject_init, so it is not refereced yet.

Yeah, that looks like it.

It still does not fail here, but I can simulate the behavior of floppy.c, and that gets fixed by your patch. Great!

Thanks a lot,
Kay

Greg KH

2007-11-15 17:10 UTC #42 lore raw

In reply to Dave Young

Quoted 50 lines · Dave Young

Quoted 26 lines · Kay Sievers
Quoted 18 lines · Dave Young
Quoted 17 lines · Kay Sievers
Quoted 10 lines · Jiri Kosina
Quoted 7 lines · Kay Sievers
Could it be an init-order problem, where something tries to use the block subsystem? Before it is initialized with:
block/genhd.c :: subsys_initcall(genhd_device_init);
If that's the case, we have an old bug that nobody noticed with static structures, which are zeroed that time, but definitely not properly initialized. I'll try to build loop non-modular now, and see if that makes the bug appear here.
Quoted 2 lines
my .config with which I reproduc this on 2.6.24-rc2-mm1 reliably can be obtained from http://www.jikos.cz/jikos/junk/.config
Hmm, that config doesn't do anything here, and if I make it boot, it does not show the bug.
Quoted 6 lines
Quoted 4 lines
Could you possibly enable kobject debugging and see if that exposes something, maybe something goes wrong with the kset refcount and it gets released while in use.
Hi,
I would do that.
Quoted 7 lines
That would be great.
Quoted 1 line
BTW, The bug report as EIP at __list_add with CONFIG_DEBUG_LIST=y
Yeah, that hints that the kset, which contains the list, is not allocated at the time it is used, or it is already released (kfree) again by some buggy logic.
Yes, I debugged it, there's some new findings.
It is freed by put_disk.
The floppy driver alloc_disk and then call put_disk without register_disk. in kobject_cleanup line 551:
if(s)
	kset_put(s);
Now the kset is set in alloc_disk after kobject_init, so it is not refereced yet. please try this patch:
block/genhd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -upr linux/block/genhd.c linux.new/block/genhd.c

block/genhd.c struct gendisk *alloc_disk_node(int mino · line 726

Quoted 10 lines

block/genhd.c +1 -1

@@ -718,9 +718,9 @@ struct gendisk *alloc_disk_node(int mino
 			}
 		}
 		disk->minors = minors;
-		kobject_init(&disk->kobj);
 		disk->kobj.kset = block_kset;
 		disk->kobj.ktype = &ktype_block;
+		kobject_init(&disk->kobj);
 		rand_initialize_disk(disk);
 		INIT_WORK(&disk->async_notify,
 			media_change_notify_thread);

Ah, yes, that is a bug, and it's my fault, let me go fix that in my patch series. Thanks a lot for finding this.

Does this patch fix your problem?

thanks,

greg k-h

Kay Sievers

2007-11-15 17:16 UTC #43 lore raw

Quoted 56 lines · Greg KH

Quoted 55 lines · Dave Young
Quoted 26 lines · Kay Sievers
Quoted 18 lines · Dave Young
Quoted 17 lines · Kay Sievers
Quoted 10 lines · Jiri Kosina
Quoted 7 lines · Kay Sievers
Could it be an init-order problem, where something tries to use the block subsystem? Before it is initialized with:
block/genhd.c :: subsys_initcall(genhd_device_init);
If that's the case, we have an old bug that nobody noticed with static structures, which are zeroed that time, but definitely not properly initialized. I'll try to build loop non-modular now, and see if that makes the bug appear here.
Quoted 2 lines
my .config with which I reproduc this on 2.6.24-rc2-mm1 reliably can be obtained from http://www.jikos.cz/jikos/junk/.config
Hmm, that config doesn't do anything here, and if I make it boot, it does not show the bug.
Quoted 6 lines
Quoted 4 lines
Could you possibly enable kobject debugging and see if that exposes something, maybe something goes wrong with the kset refcount and it gets released while in use.
Hi,
I would do that.
Quoted 7 lines
That would be great.
Quoted 1 line
BTW, The bug report as EIP at __list_add with CONFIG_DEBUG_LIST=y
Yeah, that hints that the kset, which contains the list, is not allocated at the time it is used, or it is already released (kfree) again by some buggy logic.
Yes, I debugged it, there's some new findings.
It is freed by put_disk.
The floppy driver alloc_disk and then call put_disk without register_disk. in kobject_cleanup line 551:
if(s)
	kset_put(s);
Now the kset is set in alloc_disk after kobject_init, so it is not refereced yet. please try this patch:
block/genhd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -upr linux/block/genhd.c linux.new/block/genhd.c
block/genhd.c +0 -1
@@ -718,9 +718,9 @@ struct gendisk *alloc_disk_node(int mino
 			}
 		}
 		disk->minors = minors;
-		kobject_init(&disk->kobj);
 		disk->kobj.kset = block_kset;

Quoted 8 lines

block/genhd.c struct gendisk *alloc_disk_node(int mino · line 726
Quoted 5 lines
block/genhd.c +1 -0
 		disk->kobj.ktype = &ktype_block;
+		kobject_init(&disk->kobj);
 		rand_initialize_disk(disk);
 		INIT_WORK(&disk->async_notify,
 			media_change_notify_thread);
Ah, yes, that is a bug, and it's my fault, let me go fix that in my patch series.

Oh, this is an old bug, that just didn't crash with the static ksets, it did all the refcounting wrong, but nobody noticed it because the kset data was still there.

Kay

Greg KH

2007-11-15 19:02 UTC #44 lore raw

Quoted 66 lines · Kay Sievers

Quoted 56 lines · Greg KH
Quoted 55 lines · Dave Young
Quoted 26 lines · Kay Sievers
Quoted 18 lines · Dave Young
Quoted 17 lines · Kay Sievers
Quoted 10 lines · Jiri Kosina
Quoted 7 lines · Kay Sievers
Could it be an init-order problem, where something tries to use the block subsystem? Before it is initialized with:
block/genhd.c :: subsys_initcall(genhd_device_init);
If that's the case, we have an old bug that nobody noticed with static structures, which are zeroed that time, but definitely not properly initialized. I'll try to build loop non-modular now, and see if that makes the bug appear here.
Quoted 2 lines
my .config with which I reproduc this on 2.6.24-rc2-mm1 reliably can be obtained from http://www.jikos.cz/jikos/junk/.config
Hmm, that config doesn't do anything here, and if I make it boot, it does not show the bug.
Quoted 6 lines
Quoted 4 lines
Could you possibly enable kobject debugging and see if that exposes something, maybe something goes wrong with the kset refcount and it gets released while in use.
Hi,
I would do that.
Quoted 7 lines
That would be great.
Quoted 1 line
BTW, The bug report as EIP at __list_add with CONFIG_DEBUG_LIST=y
Yeah, that hints that the kset, which contains the list, is not allocated at the time it is used, or it is already released (kfree) again by some buggy logic.
Yes, I debugged it, there's some new findings.
It is freed by put_disk.
The floppy driver alloc_disk and then call put_disk without register_disk. in kobject_cleanup line 551:
if(s)
	kset_put(s);
Now the kset is set in alloc_disk after kobject_init, so it is not refereced yet. please try this patch:
block/genhd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -upr linux/block/genhd.c linux.new/block/genhd.c
block/genhd.c +0 -1
@@ -718,9 +718,9 @@ struct gendisk *alloc_disk_node(int mino
 			}
 		}
 		disk->minors = minors;
-		kobject_init(&disk->kobj);
 		disk->kobj.kset = block_kset;
Quoted 8 lines
block/genhd.c struct gendisk *alloc_disk_node(int mino · line 726
Quoted 5 lines
block/genhd.c +1 -0
 		disk->kobj.ktype = &ktype_block;
+		kobject_init(&disk->kobj);
 		rand_initialize_disk(disk);
 		INIT_WORK(&disk->async_notify,
 			media_change_notify_thread);
Ah, yes, that is a bug, and it's my fault, let me go fix that in my patch series.

Quoted 3 lines

Oh, this is an old bug, that just didn't crash with the static ksets, it did all the refcounting wrong, but nobody noticed it because the kset data was still there.

No, I messed it up when I did the initial kset changes. If you look at 2.6.24-rc2, it's correct there:

		disk->minors = minors;
		kobj_set_kset_s(disk,block_subsys);
		kobject_init(&disk->kobj);

I have no idea why I switched those lines around, sorry about that.

greg k-h

Olof Johansson

2007-11-14 06:31 UTC #45 lore raw

PATCH 1/1 Fix dependencies for FSL_DMA

[POWERPC] Fix dependencies for FSL_DMA

Quoted 1 line

From a powerpc allyesconfig build:

drivers/dma/fsldma.c:504: error: implicit declaration of function 'bus_to_virt'

Signed-off-by Olof Johansson <[email protected]>

drivers/dma/Kconfig +1 -1

Index: mm/drivers/dma/Kconfig
===================================================================
@@ -36,7 +36,7 @@ config INTEL_IOP_ADMA
 
 config FSL_DMA
 	bool "Freescale MPC85xx/MPC83xx DMA support"
-	depends on PPC
+	depends on PPC && VIRT_TO_BUS
 	select DMA_ENGINE
 	---help---
 	  Enable support for the Freescale DMA engine. Now, it support

Andy Whitcroft

2007-11-14 08:56 UTC #46 lore raw

Re: 2.6.24-rc2-mm1 -- mkfs failing on variety of fs types

We seem to have some general problem with mkfs for all filesystems. I am seeing this across at least three test systems although most are unable to compile this kernel :(, even with the hotfix. Basically, all mkfs operations for any filsystem type are failing, ext2 reports this as "short write", various others are mentioning pwrite and pwrite64 returning bad things:

ext2: Could not write 8 blocks in inode table starting at 851970:
Attempt to write block from filesystem resulted in short write

reiserfs: bwrite: write 4096 bytes returned -1 (block=851968,
dev=3): No space left on device

xfs: mkfs.xfs: pwrite64 failed: No space left on device

Nothing is reported in dmesg at the time as far as I can tell. From the ext2 log I would swear we get this error on a block number far below that which is reported written successfully, though I cannot say I trust mkfs.

Nothing obvious has changed pwrite or block/* to my eye, so heck knows where this is coming from. 2.6.24-rc2 works on these same systems as goes the latest 2.6.24-rc2-git5.

Full mkfs output below.

-apw

*** elm3b6, x86_64:

mke2fs 1.37 (21-Mar-2005)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
1465920 inodes, 2929854 blocks
146492 blocks (5.00%) reserved for the super user
First data block=0
90 block groups
32768 blocks per group, 32768 fragments per group
16288 inodes per group
Superblock backups stored on blocks:

	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

mkfs.ext2: Attempt to write block from filesystem resulted in short write while zeroing block 2929824 at end of filesystem Writing inode tables:
Could not write 8 blocks in inode table starting at 851970: Attempt to write block from filesystem resulted in short write
===
mkfs.jfs version 1.1.7, 22-Jul-2004
The specified disk did not finish formatting.
===
mkfs.reiserfs 3.6.19 (2003 www.namesys.com)
[...]
Guessing about desired format.. Kernel 2.6.24-rc2-mm1-autokern1 is running.
Format 3.6 with standard journal
Count of blocks on the device: 2929840
Number of blocks consumed by mkreiserfs formatting process: 8301
Blocksize: 4096
Hash function used to sort names: "r5"
Journal Size 8193 blocks (first block 18)
Journal Max transaction length 1024
inode generation number: 0
UUID: c759e218-681b-4891-b4c4-33466d4eb4f0
Initializing journal - 0%....20%....40%....60%....80%....100%
bwrite: write 4096 bytes returned -1 (block=851968, dev=3): No space left on device
===
mkfs.xfs: pwrite64 failed: No space left on device

meta-data=/dev/sdb2              isize=256    agcount=16, agsize=183115 blks
         =                       sectsz=512  
data     =                       bsize=4096   blocks=2929840, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096  
log      =internal log           bsize=4096   blocks=2560, version=1
         =                       sectsz=512   sunit=0 blks
realtime =none                   extsz=65536  blocks=0, rtextents=0

*** elm3b239, x86_64:

mke2fs 1.38 (30-Jun-2005)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
2410624 inodes, 4819500 blocks
240975 blocks (5.00%) reserved for the super user
First data block=0
148 block groups
32768 blocks per group, 32768 fragments per group
16288 inodes per group
Superblock backups stored on blocks:

	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000

mkfs.ext2: Attempt to write block from filesystem resulted in short write while zeroing block 4819472 at end of filesystem Writing inode tables:
Could not write 8 blocks in inode table starting at 655362: Attempt to write block from filesystem resulted in short write

*** pSeries-101, ppc64

mke2fs 1.38 (30-Jun-2005)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
1281696 inodes, 2560000 blocks
128000 blocks (5.00%) reserved for the super user
First data block=0
79 block groups
32768 blocks per group, 32768 fragments per group
16224 inodes per group
Superblock backups stored on blocks:

	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

mkfs.ext2: Attempt to write block from filesystem resulted in short write while zeroing block 2559984 at end of filesystem Writing inode tables:
Could not write 8 blocks in inode table starting at 491522: Attempt to write block from filesystem resulted in short write

*** gekko-lp1, ppc64

mke2fs 1.38 (30-Jun-2005)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
1224000 inodes, 2443880 blocks
122194 blocks (5.00%) reserved for the super user
First data block=0
75 block groups
32768 blocks per group, 32768 fragments per group
16320 inodes per group
Superblock backups stored on blocks:

	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

mkfs.ext2: Attempt to write block from filesystem resulted in short write while zeroing block 2443856 at end of filesystem Writing inode tables:
Could not write 8 blocks in inode table starting at 360450: Attempt to write block from filesystem resulted in short write
===
mkfs.xfs: pwrite64 failed: No space left on device

meta-data=/dev/sda7              isize=256    agcount=16, agsize=152742 blks
         =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=2443872, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096  
log      =internal log           bsize=4096   blocks=2560, version=1
         =                       sectsz=512   sunit=0 blks
realtime =none                   extsz=65536  blocks=0, rtextents=0

===
mkfs.reiserfs 3.6.19 (2003 www.namesys.com)
[...]
Guessing about desired format.. Kernel 2.6.24-rc2-mm1-autokern1 is running. Format 3.6 with standard journal
Count of blocks on the device: 2443872
Number of blocks consumed by mkreiserfs formatting process: 8286
Blocksize: 4096
Hash function used to sort names: "r5"
Journal Size 8193 blocks (first block 18)
Journal Max transaction length 1024
inode generation number: 0
UUID: e9aa2dc4-dfc3-47e8-865b-693f28eac2e5
Initializing journal - 0%....20%....40%....60%....80%....100%
bwrite: write 4096 bytes returned -1 (block=360448, dev=3): No space left on device

Andrew Morton

author maintainer

2007-11-14 10:29 UTC #47 lore raw

Re: 2.6.24-rc2-mm1 -- mkfs failing on variety of fs types

Quoted 149 lines · On Wed, 14 Nov 2007 08:56:01 +0000 Andy Whitcroft <[email protected]> wrote:

We seem to have some general problem with mkfs for all filesystems. I am seeing this across at least three test systems although most are unable to compile this kernel :(, even with the hotfix. Basically, all mkfs operations for any filsystem type are failing, ext2 reports this as "short write", various others are mentioning pwrite and pwrite64 returning bad things:
ext2: Could not write 8 blocks in inode table starting at 851970:
Attempt to write block from filesystem resulted in short write
reiserfs: bwrite: write 4096 bytes returned -1 (block=851968,
dev=3): No space left on device
xfs: mkfs.xfs: pwrite64 failed: No space left on device
Nothing is reported in dmesg at the time as far as I can tell. From the ext2 log I would swear we get this error on a block number far below that which is reported written successfully, though I cannot say I trust mkfs.
Nothing obvious has changed pwrite or block/* to my eye, so heck knows where this is coming from. 2.6.24-rc2 works on these same systems as goes the latest 2.6.24-rc2-git5.
Full mkfs output below.
-apw
*** elm3b6, x86_64:
mke2fs 1.37 (21-Mar-2005)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
1465920 inodes, 2929854 blocks
146492 blocks (5.00%) reserved for the super user
First data block=0
90 block groups
32768 blocks per group, 32768 fragments per group
16288 inodes per group
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208
mkfs.ext2: Attempt to write block from filesystem resulted in short write while zeroing block 2929824 at end of filesystem Writing inode tables:
Could not write 8 blocks in inode table starting at 851970: Attempt to write block from filesystem resulted in short write
===
mkfs.jfs version 1.1.7, 22-Jul-2004
The specified disk did not finish formatting.
===
mkfs.reiserfs 3.6.19 (2003 www.namesys.com)
[...]
Guessing about desired format.. Kernel 2.6.24-rc2-mm1-autokern1 is running.
Format 3.6 with standard journal
Count of blocks on the device: 2929840
Number of blocks consumed by mkreiserfs formatting process: 8301
Blocksize: 4096
Hash function used to sort names: "r5"
Journal Size 8193 blocks (first block 18)
Journal Max transaction length 1024
inode generation number: 0
UUID: c759e218-681b-4891-b4c4-33466d4eb4f0
Initializing journal - 0%....20%....40%....60%....80%....100%
bwrite: write 4096 bytes returned -1 (block=851968, dev=3): No space left on device
===
mkfs.xfs: pwrite64 failed: No space left on device
meta-data=/dev/sdb2              isize=256    agcount=16, agsize=183115 blks
         =                       sectsz=512  
data     =                       bsize=4096   blocks=2929840, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096  
log      =internal log           bsize=4096   blocks=2560, version=1
         =                       sectsz=512   sunit=0 blks
realtime =none                   extsz=65536  blocks=0, rtextents=0
*** elm3b239, x86_64:
mke2fs 1.38 (30-Jun-2005)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
2410624 inodes, 4819500 blocks
240975 blocks (5.00%) reserved for the super user
First data block=0
148 block groups
32768 blocks per group, 32768 fragments per group
16288 inodes per group
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000
mkfs.ext2: Attempt to write block from filesystem resulted in short write while zeroing block 4819472 at end of filesystem Writing inode tables:
Could not write 8 blocks in inode table starting at 655362: Attempt to write block from filesystem resulted in short write
*** pSeries-101, ppc64
mke2fs 1.38 (30-Jun-2005)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
1281696 inodes, 2560000 blocks
128000 blocks (5.00%) reserved for the super user
First data block=0
79 block groups
32768 blocks per group, 32768 fragments per group
16224 inodes per group
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
mkfs.ext2: Attempt to write block from filesystem resulted in short write while zeroing block 2559984 at end of filesystem Writing inode tables:
Could not write 8 blocks in inode table starting at 491522: Attempt to write block from filesystem resulted in short write
*** gekko-lp1, ppc64
mke2fs 1.38 (30-Jun-2005)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
1224000 inodes, 2443880 blocks
122194 blocks (5.00%) reserved for the super user
First data block=0
75 block groups
32768 blocks per group, 32768 fragments per group
16320 inodes per group
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
mkfs.ext2: Attempt to write block from filesystem resulted in short write while zeroing block 2443856 at end of filesystem Writing inode tables:
Could not write 8 blocks in inode table starting at 360450: Attempt to write block from filesystem resulted in short write
===
mkfs.xfs: pwrite64 failed: No space left on device
meta-data=/dev/sda7              isize=256    agcount=16, agsize=152742 blks
         =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=2443872, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096  
log      =internal log           bsize=4096   blocks=2560, version=1
         =                       sectsz=512   sunit=0 blks
realtime =none                   extsz=65536  blocks=0, rtextents=0

Quoted 15 lines

===
mkfs.reiserfs 3.6.19 (2003 www.namesys.com)
[...]
Guessing about desired format.. Kernel 2.6.24-rc2-mm1-autokern1 is running. Format 3.6 with standard journal
Count of blocks on the device: 2443872
Number of blocks consumed by mkreiserfs formatting process: 8286
Blocksize: 4096
Hash function used to sort names: "r5"
Journal Size 8193 blocks (first block 18)
Journal Max transaction length 1024
inode generation number: 0
UUID: e9aa2dc4-dfc3-47e8-865b-693f28eac2e5
Initializing journal - 0%....20%....40%....60%....80%....100%
bwrite: write 4096 bytes returned -1 (block=360448, dev=3): No space left on device

It was mm-fix-blkdev-size-calculation-in-generic_write_checks.patch.

Odd, I thought that looked OK.

Here's a revert (uploaded to hot-fixes/, too):

mm/filemap.c renamed from mm/filemap.c~revert-mm-fix-blkdev-size-calculation-in-generic_write_checks +1 -3

@@ -1855,11 +1855,9 @@ inline int generic_write_checks(struct f
 	} else {
 #ifdef CONFIG_BLOCK
 		loff_t isize;
-		unsigned int blksize;
 		if (bdev_read_only(I_BDEV(inode)))
 			return -EPERM;
-		blksize = block_size(I_BDEV(inode));
-		isize = i_size_read(inode) & ~(blksize - 1);
+		isize = i_size_read(inode);
 		if (*pos >= isize) {
 			if (*count || *pos > isize)
 				return -ENOSPC;

Dmitry Monakhov

2007-11-14 10:49 UTC #48 lore raw

Re: 2.6.24-rc2-mm1 -- mkfs failing on variety of fs types

Quoted 2 lines · Andrew Morton

On Wed, 14 Nov 2007 08:56:01 +0000 Andy Whitcroft <[email protected]> wrote:

[snip]

Quoted 6 lines

Quoted 4 lines
We seem to have some general problem with mkfs for all filesystems.
UUID: e9aa2dc4-dfc3-47e8-865b-693f28eac2e5
Initializing journal - 0%....20%....40%....60%....80%....100%
bwrite: write 4096 bytes returned -1 (block=360448, dev=3): No space left on device
It was mm-fix-blkdev-size-calculation-in-generic_write_checks.patch.

Oh my ..., I'm truly sorry. When i've sent this patch to Andrew first time he ask me to remake it in order to make it less intrusive. When later i've found what patch was buggy because of incorrect int to loff_t conversion

isize = i_size_read(inode) & ~(blksize - 1);
                              ^^^^^^^^^^^^^^

Later i've missed when this patch was accepted some days ago :(.

Quoted 23 lines

Odd, I thought that looked OK.

Here's a revert (uploaded to hot-fixes/, too):

mm/filemap.c renamed from mm/filemap.c~revert-mm-fix-blkdev-size-calculation-in-generic_write_checks +1 -3

@@ -1855,11 +1855,9 @@ inline int generic_write_checks(struct f
 	} else {
 #ifdef CONFIG_BLOCK
 		loff_t isize;
-		unsigned int blksize;
 		if (bdev_read_only(I_BDEV(inode)))
 			return -EPERM;
-		blksize = block_size(I_BDEV(inode));
-		isize = i_size_read(inode) & ~(blksize - 1);
+		isize = i_size_read(inode);
 		if (*pos >= isize) {
 			if (*count || *pos > isize)
 				return -ENOSPC;

Jiri Kosina

2007-11-14 14:41 UTC #49 lore raw

Quoted 2 lines · Andrew Morton

- To fetch an -mm tree using git, use (for example)
git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1

$ git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.24-rc2-mm1
error: no such remote ref refs/tags/v2.6.24-rc2-mm1
fatal: Fetch failure: git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git

I can see the v2.6.24-rc2-mm1 tag on
http://git.kernel.org/?p=linux/kernel/git/smurf/linux-trees.git;a=summary
though, so there seems to be something fishy ... ?

Signature · 1 line

Jiri Kosina

Matthias Urlichs

2007-11-14 15:25 UTC #50 lore raw

Hi,

Jiri Kosina:

Quoted 2 lines

$ git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.24-rc2-mm1
error: no such remote ref refs/tags/v2.6.24-rc2-mm1

Yeah, the import took too long and thus broke.

Should be fixed by now.

Signature · 8 lines

Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [email protected]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
:FTP: /F-T-P/, _not_ /fit'ip/ 1. [techspeak] n. The File Transfer
   Protocol for transmitting files between systems on the Internet. 2. vt.
   To {beam} a file using the File Transfer Protocol. 3. Sometimes used as
   a generic even for file transfers not using {FTP}. "Lemme get a copy of
   "Wuthering Heights" ftp'd from uunet."

Jiri Kosina

2007-11-14 15:04 UTC #51 lore raw

Quoted 4 lines · Matthias Urlichs

Quoted 2 lines
$ git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.24-rc2-mm1
error: no such remote ref refs/tags/v2.6.24-rc2-mm1
Yeah, the import took too long and thus broke.
Should be fixed by now.

Hi Matthias,

hmm, still doesn't work even if I try to fetch the tag directly from hera (i.e. not waiting for sync to git mirrors on kernel.org):

$ git-fetch [email protected]:/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.24-rc2-mm1
error: refs/heads/master points nowhere!
error: refs/heads/master points nowhere!
error: no such remote ref refs/tags/v2.6.24-rc2-mm1
fatal: Fetch failure: [email protected]:/pub/scm/linux/kernel/git/smurf/linux-trees.git

Signature · 1 line

Jiri Kosina

Matthias Urlichs

2007-11-14 15:43 UTC #52 lore raw

Hi,

Jiri Kosina:

Quoted 1 line

hmm, still doesn't work even if I try to fetch the tag directly from hera

*Sigh* fixed. I hope. ;-)

Signature · 6 lines

Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [email protected]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Just about every computer on the market today runs Unix, except the Mac
(and nobody cares about it).
		-- Bill Joy 6/21/85

Jiri Kosina

2007-11-14 15:49 UTC #53 lore raw

Quoted 2 lines · Matthias Urlichs

Quoted 1 line
hmm, still doesn't work even if I try to fetch the tag directly from hera
*Sigh* fixed. I hope. ;-)

Yes, now it works. Thanks a lot,

Signature · 1 line

Jiri Kosina

Jiri Kosina

2007-11-14 16:30 UTC #54 lore raw

Quoted 1 line · Andrew Morton

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2/2.6.24-rc2-mm1/

Doesn't boot here:

serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A 00:02: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Floppy drive(s): fd0 is 1.44M
floppy0: Floppy io-port 0x03f2 in use
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation. turning off the locking correctness validator.

Call Trace:
 [<ffffffff80251f88>] __lock_acquire+0x1b7/0xcd0
 [<ffffffff80252e8e>] lock_acquire+0x51/0x6c
 [<ffffffff8035bd62>] kobject_add+0x9b/0x197
 [<ffffffff80598ce2>] _spin_lock+0x1e/0x27
 [<ffffffff8035bd62>] kobject_add+0x9b/0x197
 [<ffffffff802c9a42>] register_disk+0x48/0x209
 [<ffffffff80355d14>] add_disk+0x34/0x3d
 [<ffffffff8083cdb4>] rd_init+0x172/0x1e1
 [<ffffffff8082063a>] kernel_init+0x175/0x2e6
 [<ffffffff8025194c>] trace_hardirqs_on+0x115/0x139
 [<ffffffff80598779>] trace_hardirqs_on_thunk+0x35/0x3a
 [<ffffffff8025194c>] trace_hardirqs_on+0x115/0x139
 [<ffffffff8020c628>] child_rip+0xa/0x12
 [<ffffffff8020bd3f>] restore_args+0x0/0x30
 [<ffffffff808204c5>] kernel_init+0x0/0x2e6
 [<ffffffff8020c61e>] child_rip+0x0/0x12

INFO: lockdep is turned off.

BUG: spinlock lockup on CPU#0, swapper/1, FFFF81001FA2BED0

Call Trace:
 [<ffffffff80363632>] _raw_spin_lock+0xd1/0xf8
 [<ffffffff8035bd62>] kobject_add+0x9b/0x197
 [<ffffffff8035bd62>] kobject_add+0x9b/0x197
 [<ffffffff802c9a42>] register_disk+0x48/0x209
 [<ffffffff80355d14>] add_disk+0x34/0x3d
 [<ffffffff8083cdb4>] rd_init+0x172/0x1e1
 [<ffffffff8082063a>] kernel_init+0x175/0x2e6
 [<ffffffff8025194c>] trace_hardirqs_on+0x115/0x139
 [<ffffffff80598779>] trace_hardirqs_on_thunk+0x35/0x3a
 [<ffffffff8025194c>] trace_hardirqs_on+0x115/0x139
 [<ffffffff8020c628>] child_rip+0xa/0x12
 [<ffffffff8020bd3f>] restore_args+0x0/0x30
 [<ffffffff808204c5>] kernel_init+0x0/0x2e6
 [<ffffffff8020c61e>] child_rip+0x0/0x12

INFO: lockdep is turned off.

I will investigate.

Signature · 1 line

Jiri Kosina

Andrew Morton

author maintainer

2007-11-14 16:40 UTC #55 lore raw

Quoted 51 lines · On Wed, 14 Nov 2007 17:29:49 +0100 (CET) Jiri Kosina <[email protected]> wrote:

Quoted 1 line · Andrew Morton

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2/2.6.24-rc2-mm1/

Doesn't boot here:

Call Trace:
 [<ffffffff80251f88>] __lock_acquire+0x1b7/0xcd0
 [<ffffffff80252e8e>] lock_acquire+0x51/0x6c
 [<ffffffff8035bd62>] kobject_add+0x9b/0x197
 [<ffffffff80598ce2>] _spin_lock+0x1e/0x27
 [<ffffffff8035bd62>] kobject_add+0x9b/0x197
 [<ffffffff802c9a42>] register_disk+0x48/0x209
 [<ffffffff80355d14>] add_disk+0x34/0x3d
 [<ffffffff8083cdb4>] rd_init+0x172/0x1e1
 [<ffffffff8082063a>] kernel_init+0x175/0x2e6
 [<ffffffff8025194c>] trace_hardirqs_on+0x115/0x139
 [<ffffffff80598779>] trace_hardirqs_on_thunk+0x35/0x3a
 [<ffffffff8025194c>] trace_hardirqs_on+0x115/0x139
 [<ffffffff8020c628>] child_rip+0xa/0x12
 [<ffffffff8020bd3f>] restore_args+0x0/0x30
 [<ffffffff808204c5>] kernel_init+0x0/0x2e6
 [<ffffffff8020c61e>] child_rip+0x0/0x12

INFO: lockdep is turned off.

BUG: spinlock lockup on CPU#0, swapper/1, FFFF81001FA2BED0

Call Trace:
 [<ffffffff80363632>] _raw_spin_lock+0xd1/0xf8
 [<ffffffff8035bd62>] kobject_add+0x9b/0x197
 [<ffffffff8035bd62>] kobject_add+0x9b/0x197
 [<ffffffff802c9a42>] register_disk+0x48/0x209
 [<ffffffff80355d14>] add_disk+0x34/0x3d
 [<ffffffff8083cdb4>] rd_init+0x172/0x1e1
 [<ffffffff8082063a>] kernel_init+0x175/0x2e6
 [<ffffffff8025194c>] trace_hardirqs_on+0x115/0x139
 [<ffffffff80598779>] trace_hardirqs_on_thunk+0x35/0x3a
 [<ffffffff8025194c>] trace_hardirqs_on+0x115/0x139
 [<ffffffff8020c628>] child_rip+0xa/0x12
 [<ffffffff8020bd3f>] restore_args+0x0/0x30
 [<ffffffff808204c5>] kernel_init+0x0/0x2e6
 [<ffffffff8020c61e>] child_rip+0x0/0x12

Quoted 2 lines

INFO: lockdep is turned off.

I'd suspect the driver tree. I think I'll need to do a quick -mm2 without that tree present.

Jiri Kosina

2007-11-14 16:41 UTC #56 lore raw

Quoted 2 lines · Andrew Morton

I'd suspect the driver tree. I think I'll need to do a quick -mm2 without that tree present.

I am just verifying whether reverting kset changes fixes this, will let you know soon.

Signature · 1 line

Jiri Kosina

Jiri Kosina

2007-11-14 17:02 UTC #57 lore raw

Quoted 4 lines · Jiri Kosina

Quoted 2 lines
I'd suspect the driver tree. I think I'll need to do a quick -mm2 without that tree present.
I am just verifying whether reverting kset changes fixes this, will let you know soon.

OK, so I reverted gregkh-driver-kset-convert-block_subsys-to-use-kset_create (which made me also revert gregkh-driver-kobject-remove-subsystem_register-functions and gregkh-driver-kset-remove-decl_subsys-macro so that we compile). Both the error message from lockdep and more importantly the spinlock lockup have gone, and the system with these patches reverted boots for me fine.

Well not that fine, I still see (which is the same backtrace that caused the lockup with plain -rc2-mm1, but doesn't make the machine hang):

floppy0: Floppy io-port 0x03f2 in use

WARNING: at lib/kref.c:33 kref_get()

Call Trace:
 [<ffffffff8035bd43>] kobject_add+0x9b/0x197
 [<ffffffff8035c6e1>] kref_get+0x2f/0x36
 [<ffffffff8035b82f>] kobject_get+0x12/0x17
 [<ffffffff8035bd55>] kobject_add+0xad/0x197
 [<ffffffff802c9a36>] register_disk+0x48/0x205
 [<ffffffff80355cf3>] add_disk+0x34/0x3d
 [<ffffffff8083cd99>] rd_init+0x172/0x1e1
 [<ffffffff8082063a>] kernel_init+0x175/0x2e6
 [<ffffffff8025193c>] trace_hardirqs_on+0x115/0x139
 [<ffffffff80598769>] trace_hardirqs_on_thunk+0x35/0x3a
 [<ffffffff8025193c>] trace_hardirqs_on+0x115/0x139
 [<ffffffff8020c628>] child_rip+0xa/0x12
 [<ffffffff8020bd3f>] restore_args+0x0/0x30
 [<ffffffff808204c5>] kernel_init+0x0/0x2e6
 [<ffffffff8020c61e>] child_rip+0x0/0x12

Signature · 1 line

Jiri Kosina

Jiri Kosina

2007-11-14 17:43 UTC #58 lore raw

Quoted 12 lines · Jiri Kosina

Well not that fine, I still see (which is the same backtrace that caused the lockup with plain -rc2-mm1, but doesn't make the machine hang):
floppy0: Floppy io-port 0x03f2 in use
WARNING: at lib/kref.c:33 kref_get()
Call Trace:
 [<ffffffff8035bd43>] kobject_add+0x9b/0x197
 [<ffffffff8035c6e1>] kref_get+0x2f/0x36
 [<ffffffff8035b82f>] kobject_get+0x12/0x17
 [<ffffffff8035bd55>] kobject_add+0xad/0x197
 [<ffffffff802c9a36>] register_disk+0x48/0x205
 [<ffffffff80355cf3>] add_disk+0x34/0x3d
 [<ffffffff8083cd99>] rd_init+0x172/0x1e1

Quoted 8 lines

 [<ffffffff8082063a>] kernel_init+0x175/0x2e6
 [<ffffffff8025193c>] trace_hardirqs_on+0x115/0x139
 [<ffffffff80598769>] trace_hardirqs_on_thunk+0x35/0x3a
 [<ffffffff8025193c>] trace_hardirqs_on+0x115/0x139
 [<ffffffff8020c628>] child_rip+0xa/0x12
 [<ffffffff8020bd3f>] restore_args+0x0/0x30
 [<ffffffff808204c5>] kernel_init+0x0/0x2e6
 [<ffffffff8020c61e>] child_rip+0x0/0x12

And this goes away when gregkh-driver-remove-struct-kobj_type-from-struct-kset is reverted.

Signature · 1 line

Jiri Kosina

Greg KH

2007-11-14 18:20 UTC #59 lore raw

In reply to Jiri Kosina

Quoted 28 lines · Jiri Kosina

Quoted 4 lines · Jiri Kosina
Quoted 2 lines
I'd suspect the driver tree. I think I'll need to do a quick -mm2 without that tree present.
I am just verifying whether reverting kset changes fixes this, will let you know soon.
OK, so I reverted gregkh-driver-kset-convert-block_subsys-to-use-kset_create (which made me also revert gregkh-driver-kobject-remove-subsystem_register-functions and gregkh-driver-kset-remove-decl_subsys-macro so that we compile). Both the error message from lockdep and more importantly the spinlock lockup have gone, and the system with these patches reverted boots for me fine.
Well not that fine, I still see (which is the same backtrace that caused the lockup with plain -rc2-mm1, but doesn't make the machine hang):
floppy0: Floppy io-port 0x03f2 in use
WARNING: at lib/kref.c:33 kref_get()

Call Trace:
 [<ffffffff8035bd43>] kobject_add+0x9b/0x197
 [<ffffffff8035c6e1>] kref_get+0x2f/0x36
 [<ffffffff8035b82f>] kobject_get+0x12/0x17
 [<ffffffff8035bd55>] kobject_add+0xad/0x197
 [<ffffffff802c9a36>] register_disk+0x48/0x205
 [<ffffffff80355cf3>] add_disk+0x34/0x3d
 [<ffffffff8083cd99>] rd_init+0x172/0x1e1

Quoted 8 lines

 [<ffffffff8082063a>] kernel_init+0x175/0x2e6
 [<ffffffff8025193c>] trace_hardirqs_on+0x115/0x139
 [<ffffffff80598769>] trace_hardirqs_on_thunk+0x35/0x3a
 [<ffffffff8025193c>] trace_hardirqs_on+0x115/0x139
 [<ffffffff8020c628>] child_rip+0xa/0x12
 [<ffffffff8020bd3f>] restore_args+0x0/0x30
 [<ffffffff808204c5>] kernel_init+0x0/0x2e6
 [<ffffffff8020c61e>] child_rip+0x0/0x12

someone is trying to call kref_get on a kobject that has not been initialized yet, which could be the reason the newer patches break something, as the pointers are not set up properly with a call to kobject_init() first.

But, alloc_disk() should have been called on this gendisk for it to work properly at all, unless something is trashing that structure?

I'm way confused...

greg k-h

Greg KH

2007-11-15 19:27 UTC #60 lore raw

Quoted 43 lines · Greg KH

Quoted 28 lines · Jiri Kosina
Quoted 4 lines · Jiri Kosina
Quoted 2 lines
I'd suspect the driver tree. I think I'll need to do a quick -mm2 without that tree present.
I am just verifying whether reverting kset changes fixes this, will let you know soon.
OK, so I reverted gregkh-driver-kset-convert-block_subsys-to-use-kset_create (which made me also revert gregkh-driver-kobject-remove-subsystem_register-functions and gregkh-driver-kset-remove-decl_subsys-macro so that we compile). Both the error message from lockdep and more importantly the spinlock lockup have gone, and the system with these patches reverted boots for me fine.
Well not that fine, I still see (which is the same backtrace that caused the lockup with plain -rc2-mm1, but doesn't make the machine hang):
floppy0: Floppy io-port 0x03f2 in use
WARNING: at lib/kref.c:33 kref_get()

Call Trace:
 [<ffffffff8035bd43>] kobject_add+0x9b/0x197
 [<ffffffff8035c6e1>] kref_get+0x2f/0x36
 [<ffffffff8035b82f>] kobject_get+0x12/0x17
 [<ffffffff8035bd55>] kobject_add+0xad/0x197
 [<ffffffff802c9a36>] register_disk+0x48/0x205
 [<ffffffff80355cf3>] add_disk+0x34/0x3d
 [<ffffffff8083cd99>] rd_init+0x172/0x1e1
Quoted 8 lines
 [<ffffffff8082063a>] kernel_init+0x175/0x2e6
 [<ffffffff8025193c>] trace_hardirqs_on+0x115/0x139
 [<ffffffff80598769>] trace_hardirqs_on_thunk+0x35/0x3a
 [<ffffffff8025193c>] trace_hardirqs_on+0x115/0x139
 [<ffffffff8020c628>] child_rip+0xa/0x12
 [<ffffffff8020bd3f>] restore_args+0x0/0x30
 [<ffffffff808204c5>] kernel_init+0x0/0x2e6
 [<ffffffff8020c61e>] child_rip+0x0/0x12
someone is trying to call kref_get on a kobject that has not been initialized yet, which could be the reason the newer patches break something, as the pointers are not set up properly with a call to kobject_init() first.

Quoted 4 lines

But, alloc_disk() should have been called on this gendisk for it to work properly at all, unless something is trashing that structure?
I'm way confused...

This patch, as found by Dave Young, should fix the issue:

I'll roll it into my larger patchset so that Andrew will get it automatically next release, but here it is for people to use now.

thanks,

greg k-h

--------------

From: Greg Kroah-Hartman <[email protected]>
Subject: fix bug with adding new block devices in -mm

need to set the kset before initializing the kobject.

---
 block/genhd.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

block/genhd.c +1 -1

@@ -718,9 +718,9 @@ struct gendisk *alloc_disk_node(int mino
 			}
 		}
 		disk->minors = minors;
-		kobject_init(&disk->kobj);
 		disk->kobj.kset = block_kset;
 		disk->kobj.ktype = &ktype_block;
+		kobject_init(&disk->kobj);
 		rand_initialize_disk(disk);
 		INIT_WORK(&disk->async_notify,
 			media_change_notify_thread);

Jiri Kosina

2007-11-15 21:42 UTC #61 lore raw

Quoted 3 lines · Greg KH

This patch, as found by Dave Young, should fix the issue: I'll roll it into my larger patchset so that Andrew will get it automatically next release, but here it is for people to use now.

Hmm, something strange going on here. With this patch applied on top of 2.6.24-rc2-mm1, I can't see no lockup or warning from kobjects code, which is good. But this happens:

...
Creating device nodes with udev
resume device not found (ignoring)
Waiting for device /dev/disk/by-id/scsi-SATA_HDS722516VLSA80_VN6D3ECDE5BD9D-part6 to appear:
ok
showconsole: Warning: the ioctl TIOCGDEV is not known by the kernel fsck 1.40.2 (12-Jul-2007)
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/disk/by-id/scsi-SATA_HDS722516VLSA80_VN6D3ECDE5BD9D-part6 Error writing block 1542 (Attempt to write block from filesystem resulted in short write).

/dev/disk/by-id/scsi-SATA_HDS722516VLSA80_VN6D3ECDE5BD9D-part6: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
Error writing block 1542 (Attempt to write block from filesystem resulted in short write).

(and this keeps looping forever).

However the very same kernel, with the very same .config, but with just

gregkh-driver-kset-convert-block_subsys-to-use-kset_create gregkh-driver-kobject-remove-subsystem_register-functions gregkh-driver-kset-remove-decl_subsys-macro

reverted, boots perfectly fine.

Signature · 1 line

Jiri Kosina

Andrew Morton

author maintainer

2007-11-15 21:54 UTC #62 lore raw

Quoted 23 lines · On Thu, 15 Nov 2007 22:41:41 +0100 (CET) Jiri Kosina <[email protected]> wrote:

Quoted 3 lines · Greg KH
This patch, as found by Dave Young, should fix the issue: I'll roll it into my larger patchset so that Andrew will get it automatically next release, but here it is for people to use now.
Hmm, something strange going on here. With this patch applied on top of 2.6.24-rc2-mm1, I can't see no lockup or warning from kobjects code, which is good. But this happens:
...
Creating device nodes with udev
resume device not found (ignoring)
Waiting for device /dev/disk/by-id/scsi-SATA_HDS722516VLSA80_VN6D3ECDE5BD9D-part6 to appear:
ok
showconsole: Warning: the ioctl TIOCGDEV is not known by the kernel fsck 1.40.2 (12-Jul-2007)
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/disk/by-id/scsi-SATA_HDS722516VLSA80_VN6D3ECDE5BD9D-part6 Error writing block 1542 (Attempt to write block from filesystem resulted in short write).

Quoted 4 lines

/dev/disk/by-id/scsi-SATA_HDS722516VLSA80_VN6D3ECDE5BD9D-part6: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
Error writing block 1542 (Attempt to write block from filesystem resulted in short write).

Yup. Please apply the fix from ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2/2.6.24-rc2-mm1/hot-fixes

Jiri Kosina

2007-11-15 22:05 UTC #63 lore raw

Quoted 6 lines · Andrew Morton

Quoted 4 lines
/dev/disk/by-id/scsi-SATA_HDS722516VLSA80_VN6D3ECDE5BD9D-part6: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
Error writing block 1542 (Attempt to write block from filesystem resulted in short write).
Yup. Please apply the fix from ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2/2.6.24-rc2-mm1/hot-fixes

Right, thanks.

OK, so I confirm that the fix from Dave fixes the lockup that I am obtaining with rc2-mm1 and also the warning from wrong kref reference count (lib/kref.c:33 kref_get()) is gone.

Signature · 1 line

Jiri Kosina

Dave Young

2007-11-16 00:39 UTC #64 lore raw

In reply to Greg KH

Quoted 76 lines · Greg KH

Quoted 43 lines · Greg KH
Quoted 28 lines · Jiri Kosina
Quoted 4 lines · Jiri Kosina
Quoted 2 lines
I'd suspect the driver tree. I think I'll need to do a quick -mm2 without that tree present.
I am just verifying whether reverting kset changes fixes this, will let you know soon.
OK, so I reverted gregkh-driver-kset-convert-block_subsys-to-use-kset_create (which made me also revert gregkh-driver-kobject-remove-subsystem_register-functions and gregkh-driver-kset-remove-decl_subsys-macro so that we compile). Both the error message from lockdep and more importantly the spinlock lockup have gone, and the system with these patches reverted boots for me fine.
Well not that fine, I still see (which is the same backtrace that caused the lockup with plain -rc2-mm1, but doesn't make the machine hang):
floppy0: Floppy io-port 0x03f2 in use
WARNING: at lib/kref.c:33 kref_get()

Call Trace:
 [<ffffffff8035bd43>] kobject_add+0x9b/0x197
 [<ffffffff8035c6e1>] kref_get+0x2f/0x36
 [<ffffffff8035b82f>] kobject_get+0x12/0x17
 [<ffffffff8035bd55>] kobject_add+0xad/0x197
 [<ffffffff802c9a36>] register_disk+0x48/0x205
 [<ffffffff80355cf3>] add_disk+0x34/0x3d
 [<ffffffff8083cd99>] rd_init+0x172/0x1e1
Quoted 8 lines
 [<ffffffff8082063a>] kernel_init+0x175/0x2e6
 [<ffffffff8025193c>] trace_hardirqs_on+0x115/0x139
 [<ffffffff80598769>] trace_hardirqs_on_thunk+0x35/0x3a
 [<ffffffff8025193c>] trace_hardirqs_on+0x115/0x139
 [<ffffffff8020c628>] child_rip+0xa/0x12
 [<ffffffff8020bd3f>] restore_args+0x0/0x30
 [<ffffffff808204c5>] kernel_init+0x0/0x2e6
 [<ffffffff8020c61e>] child_rip+0x0/0x12
someone is trying to call kref_get on a kobject that has not been initialized yet, which could be the reason the newer patches break something, as the pointers are not set up properly with a call to kobject_init() first.
Quoted 4 lines
But, alloc_disk() should have been called on this gendisk for it to work properly at all, unless something is trashing that structure?
I'm way confused...
This patch, as found by Dave Young, should fix the issue:
I'll roll it into my larger patchset so that Andrew will get it automatically next release, but here it is for people to use now.
thanks,
greg k-h
--------------
From: Greg Kroah-Hartman <[email protected]>
Subject: fix bug with adding new block devices in -mm
need to set the kset before initializing the kobject.
---
 block/genhd.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
block/genhd.c +0 -0
@@ -718,9 +718,9 @@ struct gendisk *alloc_disk_node(int mino
                        }
                }

block/genhd.c struct gendisk *alloc_disk_node(int mino

Quoted 10 lines

block/genhd.c +1 -2

                disk->minors = minors;
-               kobject_init(&disk->kobj);
                disk->kobj.kset = block_kset;
                disk->kobj.ktype = &ktype_block;
+               kobject_init(&disk->kobj);
                rand_initialize_disk(disk);
                INIT_WORK(&disk->async_notify,
                        media_change_notify_thread);
 
-

Hi,
Could you please add signed-off by me?

Signed-off-by Dave Young <[email protected]>

Regards
dave

Greg KH

2007-11-16 00:54 UTC #65 lore raw

Quoted 86 lines · Dave Young

Quoted 85 lines · Greg KH
Quoted 43 lines · Greg KH
Quoted 28 lines · Jiri Kosina
Quoted 4 lines · Jiri Kosina
Quoted 2 lines
I'd suspect the driver tree. I think I'll need to do a quick -mm2 without that tree present.
I am just verifying whether reverting kset changes fixes this, will let you know soon.
OK, so I reverted gregkh-driver-kset-convert-block_subsys-to-use-kset_create (which made me also revert gregkh-driver-kobject-remove-subsystem_register-functions and gregkh-driver-kset-remove-decl_subsys-macro so that we compile). Both the error message from lockdep and more importantly the spinlock lockup have gone, and the system with these patches reverted boots for me fine.
Well not that fine, I still see (which is the same backtrace that caused the lockup with plain -rc2-mm1, but doesn't make the machine hang):
floppy0: Floppy io-port 0x03f2 in use
WARNING: at lib/kref.c:33 kref_get()

Call Trace:
 [<ffffffff8035bd43>] kobject_add+0x9b/0x197
 [<ffffffff8035c6e1>] kref_get+0x2f/0x36
 [<ffffffff8035b82f>] kobject_get+0x12/0x17
 [<ffffffff8035bd55>] kobject_add+0xad/0x197
 [<ffffffff802c9a36>] register_disk+0x48/0x205
 [<ffffffff80355cf3>] add_disk+0x34/0x3d
 [<ffffffff8083cd99>] rd_init+0x172/0x1e1
Quoted 8 lines
 [<ffffffff8082063a>] kernel_init+0x175/0x2e6
 [<ffffffff8025193c>] trace_hardirqs_on+0x115/0x139
 [<ffffffff80598769>] trace_hardirqs_on_thunk+0x35/0x3a
 [<ffffffff8025193c>] trace_hardirqs_on+0x115/0x139
 [<ffffffff8020c628>] child_rip+0xa/0x12
 [<ffffffff8020bd3f>] restore_args+0x0/0x30
 [<ffffffff808204c5>] kernel_init+0x0/0x2e6
 [<ffffffff8020c61e>] child_rip+0x0/0x12
someone is trying to call kref_get on a kobject that has not been initialized yet, which could be the reason the newer patches break something, as the pointers are not set up properly with a call to kobject_init() first.
Quoted 4 lines
But, alloc_disk() should have been called on this gendisk for it to work properly at all, unless something is trashing that structure?
I'm way confused...
This patch, as found by Dave Young, should fix the issue:
I'll roll it into my larger patchset so that Andrew will get it automatically next release, but here it is for people to use now.
thanks,
greg k-h
--------------
From: Greg Kroah-Hartman <[email protected]>
Subject: fix bug with adding new block devices in -mm
need to set the kset before initializing the kobject.
---
 block/genhd.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
block/genhd.c +1 -1
@@ -718,9 +718,9 @@ struct gendisk *alloc_disk_node(int mino
                        }
                }
                disk->minors = minors;
-               kobject_init(&disk->kobj);
                disk->kobj.kset = block_kset;
                disk->kobj.ktype = &ktype_block;
+               kobject_init(&disk->kobj);
                rand_initialize_disk(disk);
                INIT_WORK(&disk->async_notify,
                        media_change_notify_thread);

Quoted 5 lines

Quoted 1 line
-
Hi,
Could you please add signed-off by me?
Signed-off-by Dave Young <[email protected]>

Sure, but I've modified the original patch to not include this bug in the first place, so there's really not much to sign off on there, sorry.

I will add your name as helping out with it, if that's ok.

thanks,

greg k-h

Dave Young

2007-11-16 00:55 UTC #66 lore raw

Quoted 92 lines · Greg KH

Quoted 90 lines · Dave Young
Quoted 76 lines · Greg KH
Quoted 43 lines · Greg KH
Quoted 28 lines · Jiri Kosina
Quoted 4 lines · Jiri Kosina
Quoted 2 lines
I'd suspect the driver tree. I think I'll need to do a quick -mm2 without that tree present.
I am just verifying whether reverting kset changes fixes this, will let you know soon.
OK, so I reverted gregkh-driver-kset-convert-block_subsys-to-use-kset_create (which made me also revert gregkh-driver-kobject-remove-subsystem_register-functions and gregkh-driver-kset-remove-decl_subsys-macro so that we compile). Both the error message from lockdep and more importantly the spinlock lockup have gone, and the system with these patches reverted boots for me fine.
Well not that fine, I still see (which is the same backtrace that caused the lockup with plain -rc2-mm1, but doesn't make the machine hang):
floppy0: Floppy io-port 0x03f2 in use
WARNING: at lib/kref.c:33 kref_get()

Call Trace:
 [<ffffffff8035bd43>] kobject_add+0x9b/0x197
 [<ffffffff8035c6e1>] kref_get+0x2f/0x36
 [<ffffffff8035b82f>] kobject_get+0x12/0x17
 [<ffffffff8035bd55>] kobject_add+0xad/0x197
 [<ffffffff802c9a36>] register_disk+0x48/0x205
 [<ffffffff80355cf3>] add_disk+0x34/0x3d
 [<ffffffff8083cd99>] rd_init+0x172/0x1e1
Quoted 8 lines
 [<ffffffff8082063a>] kernel_init+0x175/0x2e6
 [<ffffffff8025193c>] trace_hardirqs_on+0x115/0x139
 [<ffffffff80598769>] trace_hardirqs_on_thunk+0x35/0x3a
 [<ffffffff8025193c>] trace_hardirqs_on+0x115/0x139
 [<ffffffff8020c628>] child_rip+0xa/0x12
 [<ffffffff8020bd3f>] restore_args+0x0/0x30
 [<ffffffff808204c5>] kernel_init+0x0/0x2e6
 [<ffffffff8020c61e>] child_rip+0x0/0x12
someone is trying to call kref_get on a kobject that has not been initialized yet, which could be the reason the newer patches break something, as the pointers are not set up properly with a call to kobject_init() first.
Quoted 4 lines
But, alloc_disk() should have been called on this gendisk for it to work properly at all, unless something is trashing that structure?
I'm way confused...
This patch, as found by Dave Young, should fix the issue:
I'll roll it into my larger patchset so that Andrew will get it automatically next release, but here it is for people to use now.
thanks,
greg k-h
--------------
From: Greg Kroah-Hartman <[email protected]>
Subject: fix bug with adding new block devices in -mm
need to set the kset before initializing the kobject.
---
 block/genhd.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
block/genhd.c +0 -0
@@ -718,9 +718,9 @@ struct gendisk *alloc_disk_node(int mino
                        }
                }
block/genhd.c struct gendisk *alloc_disk_node(int mino
Quoted 10 lines
block/genhd.c +1 -2
                disk->minors = minors;
-               kobject_init(&disk->kobj);
                disk->kobj.kset = block_kset;
                disk->kobj.ktype = &ktype_block;
+               kobject_init(&disk->kobj);
                rand_initialize_disk(disk);
                INIT_WORK(&disk->async_notify,
                        media_change_notify_thread);
 
-
Hi,
Could you please add signed-off by me?

Quoted 7 lines

Quoted 1 line
Signed-off-by Dave Young <[email protected]>
Sure, but I've modified the original patch to not include this bug in the first place, so there's really not much to sign off on there, sorry.
I will add your name as helping out with it, if that's ok.

Ok, thanks.

Regards
dave

Torsten Kaiser

2007-11-14 19:16 UTC #67 lore raw

Quoted 2 lines · Andrew Morton

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2/2.6.24-rc2-mm1/

Breaks nfsv4 in a rather funny way:

treogen ~ # cd /usr/portage/x
treogen x # touch bla
touch: cannot touch `bla': File exists
treogen x # mkdir bla
treogen x # touch bla/bla
touch: cannot touch `bla/bla': File exists
treogen x # ls -lad *
drwxr-xr-x 2 root root 6 Nov 14 20:03 bla
treogen x # ls -la *
total 0
drwxr-xr-x 2 root root 6 Nov 14 20:03 .
drwxr-xr-x 3 root root 16 Nov 14 20:03 ..
treogen x #

So I can create new directories, but not new files. Reading files works normal.

The client is 2.6.24-rc2-mm1, the server 2.6.22-gentoo-r9. The fstab-line from the client:
192.168.2.4:/portage /usr/portage nfs4
rw,noatime,nodiratime,intr 0 0

2.6.23-mm1 as client worked, some 2.6.24-rc1-git? also.

Otherwise the new -mm worked OK for me, no errors visible in the syslog. It even fixed the ACPI Exception from regression bug 9320. Now the output is:

[   83.125873] scsi8 : pata_amd
[   83.125917] scsi9 : pata_amd
[   83.127062] ata9: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
[   83.127064] ata10: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
[   83.194917] ata9.01: ATA-7: Maxtor 6L250R0, BAH41G10, max UDMA/133
[   83.194920] ata9.01: 490234752 sectors, multi 16: LBA48
[   83.194929] ata9: nv_mode_filter: 0x7f39f&0x701f->0x701f,
BIOS=0x7000 (0xc00000) ACPI=0x701f (900:60:0x14)
[   83.197327] ata9.01: configured for UDMA/33
[   83.197348] ata10: port disabled. ignoring.
[   83.197428] scsi 8:0:1:0: Direct-Access     ATA      Maxtor 6L250R0
  BAH4 PQ: 0 ANSI: 5
[   83.197487] sd 8:0:1:0: [sdd] 490234752 512-byte hardware sectors (251000 MB)
[   83.197496] sd 8:0:1:0: [sdd] Write Protect is off
[   83.197498] sd 8:0:1:0: [sdd] Mode Sense: 00 3a 00 00
[   83.197510] sd 8:0:1:0: [sdd] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[   83.197542] sd 8:0:1:0: [sdd] 490234752 512-byte hardware sectors (251000 MB)
[   83.197549] sd 8:0:1:0: [sdd] Write Protect is off
[   83.197551] sd 8:0:1:0: [sdd] Mode Sense: 00 3a 00 00
[   83.197562] sd 8:0:1:0: [sdd] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[   83.197565]  sdd: sdd1 sdd2 sdd3 sdd4 < sdd5 sdd6 >
[   83.222911] sd 8:0:1:0: [sdd] Attached SCSI disk
[   83.222944] sd 8:0:1:0: Attached scsi generic sg3 type 0

Just posting this, if someone is interested in the nv_mode_filter-output... (UDMA/33 is correct, its only a 40-wire cable)

Torsten

Andrew Morton

author maintainer

2007-11-14 20:30 UTC #68 lore raw

Quoted 20 lines · On Wed, 14 Nov 2007 20:16:09 +0100 "Torsten Kaiser"…

Quoted 2 lines · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2/2.6.24-rc2-mm1/
Breaks nfsv4 in a rather funny way:
treogen ~ # cd /usr/portage/x
treogen x # touch bla
touch: cannot touch `bla': File exists
treogen x # mkdir bla
treogen x # touch bla/bla
touch: cannot touch `bla/bla': File exists
treogen x # ls -lad *
drwxr-xr-x 2 root root 6 Nov 14 20:03 bla
treogen x # ls -la *
total 0
drwxr-xr-x 2 root root 6 Nov 14 20:03 .
drwxr-xr-x 3 root root 16 Nov 14 20:03 ..
treogen x #

Quoted 8 lines

So I can create new directories, but not new files. Reading files works normal.
Quoted 1 line
The client is 2.6.24-rc2-mm1, the server 2.6.22-gentoo-r9. The fstab-line from the client:
192.168.2.4:/portage /usr/portage nfs4
rw,noatime,nodiratime,intr 0 0
2.6.23-mm1 as client worked, some 2.6.24-rc1-git? also.

hm. I guess that means I get to do yet another git-bisect. Either the nfs changes or r-o-bind-mounts, I bet.

Quoted 29 lines

Otherwise the new -mm worked OK for me, no errors visible in the syslog. It even fixed the ACPI Exception from regression bug 9320. Now the output is:

[   83.125873] scsi8 : pata_amd
[   83.125917] scsi9 : pata_amd
[   83.127062] ata9: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
[   83.127064] ata10: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
[   83.194917] ata9.01: ATA-7: Maxtor 6L250R0, BAH41G10, max UDMA/133
[   83.194920] ata9.01: 490234752 sectors, multi 16: LBA48
[   83.194929] ata9: nv_mode_filter: 0x7f39f&0x701f->0x701f,
BIOS=0x7000 (0xc00000) ACPI=0x701f (900:60:0x14)
[   83.197327] ata9.01: configured for UDMA/33
[   83.197348] ata10: port disabled. ignoring.
[   83.197428] scsi 8:0:1:0: Direct-Access     ATA      Maxtor 6L250R0
  BAH4 PQ: 0 ANSI: 5
[   83.197487] sd 8:0:1:0: [sdd] 490234752 512-byte hardware sectors (251000 MB)
[   83.197496] sd 8:0:1:0: [sdd] Write Protect is off
[   83.197498] sd 8:0:1:0: [sdd] Mode Sense: 00 3a 00 00
[   83.197510] sd 8:0:1:0: [sdd] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[   83.197542] sd 8:0:1:0: [sdd] 490234752 512-byte hardware sectors (251000 MB)
[   83.197549] sd 8:0:1:0: [sdd] Write Protect is off
[   83.197551] sd 8:0:1:0: [sdd] Mode Sense: 00 3a 00 00
[   83.197562] sd 8:0:1:0: [sdd] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[   83.197565]  sdd: sdd1 sdd2 sdd3 sdd4 < sdd5 sdd6 >
[   83.222911] sd 8:0:1:0: [sdd] Attached SCSI disk
[   83.222944] sd 8:0:1:0: Attached scsi generic sg3 type 0

Quoted 3 lines

Just posting this, if someone is interested in the nv_mode_filter-output... (UDMA/33 is correct, its only a 40-wire cable)

OK, thanks.

Torsten Kaiser

2007-11-14 20:56 UTC #69 lore raw

Quoted 29 lines · Andrew Morton

Quoted 27 lines · On Wed, 14 Nov 2007 20:16:09 +0100 "Torsten Kaiser"…
Quoted 2 lines · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2/2.6.24-rc2-mm1/
Breaks nfsv4 in a rather funny way:
treogen ~ # cd /usr/portage/x
treogen x # touch bla
touch: cannot touch `bla': File exists
treogen x # mkdir bla
treogen x # touch bla/bla
touch: cannot touch `bla/bla': File exists
treogen x # ls -lad *
drwxr-xr-x 2 root root 6 Nov 14 20:03 bla
treogen x # ls -la *
total 0
drwxr-xr-x 2 root root 6 Nov 14 20:03 .
drwxr-xr-x 3 root root 16 Nov 14 20:03 ..
treogen x #
So I can create new directories, but not new files. Reading files works normal.
Quoted 1 line
The client is 2.6.24-rc2-mm1, the server 2.6.22-gentoo-r9. The fstab-line from the client:
192.168.2.4:/portage /usr/portage nfs4
rw,noatime,nodiratime,intr 0 0

Quoted 4 lines

Quoted 1 line
2.6.23-mm1 as client worked, some 2.6.24-rc1-git? also.
hm. I guess that means I get to do yet another git-bisect. Either the nfs changes or r-o-bind-mounts, I bet.

treogen mm-test # git bisect good
Bisecting: 1245 revisions left to test after this [4d88b06571b9d45e9cb52d8ad5dbf196ba280ff3] git-scsi-misc

I'm working on it... ;)

Torsten

Torsten Kaiser

2007-11-14 22:48 UTC #70 lore raw

In reply to Torsten Kaiser

Quoted 29 lines · Andrew Morton

Quoted 27 lines · On Wed, 14 Nov 2007 20:16:09 +0100 "Torsten Kaiser"…
Quoted 2 lines · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2/2.6.24-rc2-mm1/
Breaks nfsv4 in a rather funny way:
treogen ~ # cd /usr/portage/x
treogen x # touch bla
touch: cannot touch `bla': File exists
treogen x # mkdir bla
treogen x # touch bla/bla
touch: cannot touch `bla/bla': File exists
treogen x # ls -lad *
drwxr-xr-x 2 root root 6 Nov 14 20:03 bla
treogen x # ls -la *
total 0
drwxr-xr-x 2 root root 6 Nov 14 20:03 .
drwxr-xr-x 3 root root 16 Nov 14 20:03 ..
treogen x #
So I can create new directories, but not new files. Reading files works normal.
Quoted 1 line
The client is 2.6.24-rc2-mm1, the server 2.6.22-gentoo-r9. The fstab-line from the client:
192.168.2.4:/portage /usr/portage nfs4
rw,noatime,nodiratime,intr 0 0

Quoted 4 lines

Quoted 1 line
2.6.23-mm1 as client worked, some 2.6.24-rc1-git? also.
hm. I guess that means I get to do yet another git-bisect. Either the nfs changes or r-o-bind-mounts, I bet.

Seems like you would lose that bet.

I don't have the time to finish the bisect, but there are only 19 patches remaining and three of them look like the prime suspects:

20709a71062a02d0271424f78c547dc733e863fe use-struct-path-in-struct-svc_expkey b07dd17327f38b9a5401415c0fbf816e6cd0051b use-struct-path-in-struct-svc_export-checkpatch-fixes a0886174a1bc1b7c172d40c1e416ba7e48a35ffd use-struct-path-in-struct-svc_export 62e954810588af549580026c3d8718e7717837d0 d_path-make-get_dcookie-use-a-struct-path-argument-checkpatch-fixes 06719d94df24e67ccecf38cf4c6879188dd3f18a d_path-make-get_dcookie-use-a-struct-path-argument 979a6d93394b28eee31f3322177827ec938eb34f d_path-make-proc_get_link-use-a-struct-path-argument 59b0e6c59449dc2fc2366d54f76470056483f9e6 d_path-use-struct-path-in-struct-avc_audit_data-checkpatch-fixes f15c39b7240e37ba89433aba610bfa10bd22b4f7 d_path-use-struct-path-in-struct-avc_audit_data 84556ff61beaacc32d7bcba3d644d4d8d6539356 d_path-kerneldoc-cleanup 5087403994daedc7bfd338f65b7dc69216b03e2e one-less-parameter-to-__d_path-checkpatch-fixes b610833be56ae170d33d91ee4325b70d38d6f28b one-less-parameter-to-__d_path 7395eaf4a37d80dd657e1b527de0cf9c94b4f866 introduce-path_put-unionfs dde9146c8a1cec65d3d62ff0cbbea03598ccf1f5 embed-a-struct-path-into-struct-nameidata-instead-of-nd-dentrymnt-unionfs 5fc66f255cfc1780ca22b7ddcd2d91d1abd68e48 introduce-path_get-unionfs 0ef3d8718cc6732ed2d8294cee8838bf451bd133 make-set_fs_rootpwd-take-a-struct-path be604962ef9505c13e2ce757c0c557bd2f9fd19e use-struct-path-in-fs_struct b87fbae44dd2eb0fe803f888d8f7fa1fb820553c introduce-path_get 9780697f9e775cbcf62b18780036fbb03b76100f use-path_put-in-a-few-places-instead-of-mntdput 53923d3167a3820ec21ba6464da80395a5d32dce introduce-path_put

(sha1 come from
git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git)

I added Jan Blunck to the recipents, as he wrote
use-struct-path-in-struct-svc_expkey and
use-struct-path-in-struct-svc_export

Torsten

Jan Blunck

2007-11-15 17:36 UTC #71 lore raw

Quoted 7 lines · Torsten Kaiser

Quoted 3 lines
Quoted 3 lines
So I can create new directories, but not new files. Reading files works normal.
Quoted 1 line
The client is 2.6.24-rc2-mm1, the server 2.6.22-gentoo-r9.
I added Jan Blunck to the recipents, as he wrote
use-struct-path-in-struct-svc_expkey and
use-struct-path-in-struct-svc_export

These patches only change the server code. Hard to imagine how this could break the client. The other patches are pure cleanups only.

Regards,
Jan

Signature · 1 line

Jan Blunck <[email protected]>

Torsten Kaiser

2007-11-15 18:37 UTC #72 lore raw

Quoted 4 lines · Jan Blunck

Quoted 2 lines · Torsten Kaiser
Quoted 2 lines
Quoted 2 lines
So I can create new directories, but not new files. Reading files works normal.
Quoted 1 line

Quoted 8 lines

Quoted 5 lines
Quoted 1 line
Quoted 1 line
The client is 2.6.24-rc2-mm1, the server 2.6.22-gentoo-r9.
I added Jan Blunck to the recipents, as he wrote
use-struct-path-in-struct-svc_expkey and
use-struct-path-in-struct-svc_export
These patches only change the server code. Hard to imagine how this could break the client. The other patches are pure cleanups only.

Sorry to have bothered you. But these were the only ones that touched any nfs code.
But this list was wrong anyway.

I just found out that I botched the bisect, now doing the wrong part again. (compile error scrolled of the screen and I copied/tested the same kernel again)

Torsten

Torsten Kaiser

2007-11-15 21:24 UTC #73 lore raw

In reply to Jan Blunck

Quoted 4 lines · Jan Blunck

Quoted 2 lines · Torsten Kaiser
Quoted 2 lines
Quoted 2 lines
So I can create new directories, but not new files. Reading files works normal.
Quoted 1 line

Quoted 8 lines

Quoted 5 lines
Quoted 1 line
Quoted 1 line
The client is 2.6.24-rc2-mm1, the server 2.6.22-gentoo-r9.
I added Jan Blunck to the recipents, as he wrote
use-struct-path-in-struct-svc_expkey and
use-struct-path-in-struct-svc_export
These patches only change the server code. Hard to imagine how this could break the client. The other patches are pure cleanups only.

While the next bisect proved that these patches are innocent, I'm still blaming you for my problems. ;)

The problem with the first bisect-try was, that everything between
bisect-good: r-o-bind-mounts-elevate-write-count-over-calls-to-vfs_rename and
bisect-bad: use-struct-path-in-struct-svc_export
did not compile like this:

CC [M] fs/nfsd/vfs.o
fs/nfsd/vfs.c: In function 'nfsd_rename':
fs/nfsd/vfs.c:1695: error: request for member 'mnt' in something not a structure or union
make[2]: *** [fs/nfsd/vfs.o] Error 1
make[1]: *** [fs/nfsd] Error 2
make: *** [fs] Error 2

This is cause by: nfsd-fix-wrong-mnt_writer-count-in-rename

With this patch reverted I was able to finish the bisect:

Good: move-struct-path-into-its-own-header
...: embed-a-struct-path-into-struct-nameidata-instead-of-nd-dentrymnt
Bad: embed-a-struct-path-into-struct-nameidata-instead-of-nd-dentrymnt-checkpatch-fixes

As you also wrote embed-a-struct-path-into-struct-nameidata-instead-of-nd-dentrymnt , I would like to ask you to take another look at it.

The only thing that looks suspicious to me in that patch is the following change in nfs4_atomic_open(), nfs4_open_revalidate() and nfs4_proc_create()

- struct path path = {
- .mnt = nd->mnt,
- .dentry = dentry,
- };
+ struct path path = nd->path;

This changes the path.dentry from the explizit parameter 'dentry' to the embedded dentry from the parameter 'nd'.

Hope this helps.

Torsten

Andrew Morton

author maintainer

2007-11-15 21:36 UTC #74 lore raw

Quoted 10 lines · On Thu, 15 Nov 2007 22:24:12 +0100 "Torsten Kaiser"…

The problem with the first bisect-try was, that everything between
bisect-good: r-o-bind-mounts-elevate-write-count-over-calls-to-vfs_rename and
bisect-bad: use-struct-path-in-struct-svc_export
did not compile like this:
CC [M] fs/nfsd/vfs.o
fs/nfsd/vfs.c: In function 'nfsd_rename':
fs/nfsd/vfs.c:1695: error: request for member 'mnt' in something not a structure or union

argh. I'd incorrectly worked out that nfsd-fix-wrong-mnt_writer-count-in-rename.patch was a fix against r-o-bind-mounts-elevate-write-count-over-calls-to-vfs_rename.patch however it is in fact a fix against use-struct-path-in-struct-svc_export.patch.

My life sucks.

Torsten Kaiser

2007-11-16 05:29 UTC #75 lore raw

Quoted 14 lines · Andrew Morton

Quoted 10 lines · On Thu, 15 Nov 2007 22:24:12 +0100 "Torsten Kaiser"…
The problem with the first bisect-try was, that everything between
bisect-good: r-o-bind-mounts-elevate-write-count-over-calls-to-vfs_rename and
bisect-bad: use-struct-path-in-struct-svc_export
did not compile like this:
CC [M] fs/nfsd/vfs.o
fs/nfsd/vfs.c: In function 'nfsd_rename':
fs/nfsd/vfs.c:1695: error: request for member 'mnt' in something not a structure or union

Quoted 7 lines

argh. I'd incorrectly worked out that nfsd-fix-wrong-mnt_writer-count-in-rename.patch was a fix against r-o-bind-mounts-elevate-write-count-over-calls-to-vfs_rename.patch however it is in fact a fix against use-struct-path-in-struct-svc_export.patch.
My life sucks.

I think the placement was correct, but the patch itself was made against a tree that already contained the changes from use-struct-path-in-struct-svc_export.patch. nfsd-fix-wrong-mnt_writer-count-in-rename.patch should have used the old naming ex_mnt and only use-struct-path-in-struct-svc_export.patch should have changed it to ex_path.mnt.

Torsten

Jan Blunck

2007-11-16 14:03 UTC #76 lore raw

Quoted 2 lines · Torsten Kaiser

While the next bisect proved that these patches are innocent, I'm still blaming you for my problems. ;)

Quoted 10 lines

The only thing that looks suspicious to me in that patch is the following change in nfs4_atomic_open(), nfs4_open_revalidate() and nfs4_proc_create()
(quoted diff) +1 -4
-	struct path path = {
-		.mnt = nd->mnt,
-		.dentry = dentry,
-	};
+	struct path path = nd->path;

Quoted 2 lines

This changes the path.dentry from the explizit parameter 'dentry' to the embedded dentry from the parameter 'nd'.

Ouch! You are totally right. This really looks wrong and I even don't remember how that went into the patch. Can you test if the following patch fixes the problem? (BTW: thanks for the detailed analysis)

Thanks,
Jan

---

Subject: Embed a struct path into struct nameidata breakes NFSv4

I accidently break NFSv4. Here is the original report by Torsten Kaiser:

Quoted 15 lines

Quoted 15 lines
Breaks nfsv4 in a rather funny way:
treogen ~ # cd /usr/portage/x
treogen x # touch bla
touch: cannot touch `bla': File exists
treogen x # mkdir bla
treogen x # touch bla/bla
touch: cannot touch `bla/bla': File exists
treogen x # ls -lad *
drwxr-xr-x 2 root root 6 Nov 14 20:03 bla
treogen x # ls -la *
total 0
drwxr-xr-x 2 root root 6 Nov 14 20:03 .
drwxr-xr-x 3 root root 16 Nov 14 20:03 ..
treogen x #

Signed-off-by Jan Blunck <[email protected]>

---
 fs/nfs/nfs4proc.c |   15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

fs/nfs/nfs4proc.c +12 -3

Index: b/fs/nfs/nfs4proc.c
===================================================================
@@ -1372,7 +1372,10 @@ out_close:
 struct dentry *
 nfs4_atomic_open(struct inode *dir, struct dentry *dentry, struct nameidata *nd)
 {
-	struct path path = nd->path;
+	struct path path = {
+		.mnt = nd->path.mnt,
+		.dentry = dentry,
+	};
 	struct iattr attr;
 	struct rpc_cred *cred;
 	struct nfs4_state *state;

@@ -1411,7 +1414,10 @@ nfs4_atomic_open(struct inode *dir, stru
 int
 nfs4_open_revalidate(struct inode *dir, struct dentry *dentry, int openflags, struct nameidata *nd)
 {
-	struct path path = nd->path;
+	struct path path = {
+		.mnt = nd->path.mnt,
+		.dentry = dentry,
+	};
 	struct rpc_cred *cred;
 	struct nfs4_state *state;

@@ -1860,7 +1866,10 @@ static int
 nfs4_proc_create(struct inode *dir, struct dentry *dentry, struct iattr *sattr,
                  int flags, struct nameidata *nd)
 {
-	struct path path = nd->path;
+	struct path path = {
+		.mnt = nd->path.mnt,
+		.dentry = dentry,
+	};
 	struct nfs4_state *state;
 	struct rpc_cred *cred;
 	int status = 0;

Torsten Kaiser

2007-11-16 20:11 UTC #77 lore raw

Quoted 14 lines · Jan Blunck

Quoted 10 lines · Torsten Kaiser
The only thing that looks suspicious to me in that patch is the following change in nfs4_atomic_open(), nfs4_open_revalidate() and nfs4_proc_create()
(quoted diff) +1 -4
-     struct path path = {
-             .mnt = nd->mnt,
-             .dentry = dentry,
-     };
+     struct path path = nd->path;
Quoted 2 lines
This changes the path.dentry from the explizit parameter 'dentry' to the embedded dentry from the parameter 'nd'.

Quoted 6 lines

Ouch! You are totally right. This really looks wrong and I even don't remember how that went into the patch. Can you test if the following patch fixes the problem? (BTW: thanks for the detailed analysis)
Thanks,
Jan

This patch fixes the above nfs problem, I can create files again.

But shortly after starting to use the nfs share my system locked up nearly completely.

I was using emerge (Gentoos package manager) to upgrade a package, according to its output it just was finished downloading it (via wget onto the nfs share) and the next step should normally be a checksumming of the new file. emerge did not print anything out, so it hang either at the end of the download, or during the checksumming.

The desktop froze completely, I was no longer able to move the mouse. The system still responded to SysRq and ping, but logging in via ssh was not possible.

I captured SysRq+W on a serial console, then used SysRq+P:

[  944.142371] SysRq : Show Regs
[  944.145415] CPU 3:
[  944.147500] Modules linked in: radeon drm nfsd exportfs ipv6

w83792d tuner tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx tea5761 tvaudio msp3400 bttv ir_common compat_ioctl32 videobuf_dma_sg videobuf_core btcx_risc tveeprom videodev usbhid v4l2_common v4l1_compat hid sg i2c_nforce2 pata_amd

[  944.175225] Pid: 605, comm: rpciod/3 Not tainted 2.6.24-rc2-mm1 #4
[  944.181573] RIP: 0010:[<ffffffff805b0542>]  [<ffffffff805b0542>]
_spin_lock_irqsave+0x12/0x30
[  944.190342] RSP: 0018:ffff81007ef33e28  EFLAGS: 00000286
[  944.195801] RAX: 0000000000000286 RBX: ffff81007ef33e60 RCX: 0000000000000000
[  944.203115] RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff81011e107960
[  944.210440] RBP: ffff81011cc6c588 R08: ffff8100db918130 R09: ffff81011cc6c540
[  944.217774] R10: 0000000000000000 R11: ffffffff80266390 R12: ffff8100d2d693a8
[  944.225098] R13: ffff81011cc6c588 R14: ffff8100d2d693a8 R15: ffffffff80302726
[  944.232424] FS:  00007f9e739d96f0(0000) GS:ffff81011ff12700(0000)
knlGS:0000000000000000
[  944.240717] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[  944.246625] CR2: 0000000001b691d0 CR3: 0000000069861000 CR4: 00000000000006e0
[  944.253948] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  944.261273] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  944.268606]
[  944.268607] Call Trace:
[  944.272646]  [<ffffffff8022cf4d>] __wake_up+0x2d/0x70
[  944.277827]  [<ffffffff802f5e6e>] nfs_free_unlinkdata+0x1e/0x50
[  944.283908]  [<ffffffff80593f66>] rpc_release_calldata+0x26/0x50
[  944.290098]  [<ffffffff80594930>] rpc_async_schedule+0x0/0x10
[  944.296015]  [<ffffffff80245cec>] run_workqueue+0xcc/0x170
[  944.301651]  [<ffffffff802467a0>] worker_thread+0x0/0xb0
[  944.307109]  [<ffffffff802467a0>] worker_thread+0x0/0xb0
[  944.312548]  [<ffffffff8024680d>] worker_thread+0x6d/0xb0
[  944.318092]  [<ffffffff8024a140>] autoremove_wake_function+0x0/0x30
[  944.324535]  [<ffffffff802467a0>] worker_thread+0x0/0xb0
[  944.329974]  [<ffffffff802467a0>] worker_thread+0x0/0xb0
[  944.335431]  [<ffffffff80249d5b>] kthread+0x4b/0x80
[  944.340421]  [<ffffffff8020ca28>] child_rip+0xa/0x12
[  944.345518]  [<ffffffff80249d10>] kthread+0x0/0x80
[  944.350428]  [<ffffffff8020ca1e>] child_rip+0x0/0x12
[  944.355522]

A short time after that the soft lockup detector kicked in serveral times:

[  966.712167] BUG: soft lockup - CPU#3 stuck for 11s! [rpciod/3:605]
[  966.718522] CPU 3:
[  966.720589] Modules linked in: radeon drm nfsd exportfs ipv6

[  966.748306] Pid: 605, comm: rpciod/3 Not tainted 2.6.24-rc2-mm1 #4
[  966.754653] RIP: 0010:[<ffffffff805b0542>]  [<ffffffff805b0542>]
_spin_lock_irqsave+0x12/0x30
[  966.763424] RSP: 0018:ffff81007ef33e28  EFLAGS: 00000286
[  966.768879] RAX: 0000000000000286 RBX: ffff81007ef33e60 RCX: 0000000000000000
[  966.776204] RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff81011e107960
[  966.783511] RBP: ffff81011cc6c588 R08: ffff8100db918130 R09: ffff81011cc6c540
[  966.790837] R10: 0000000000000000 R11: ffffffff80266390 R12: ffff8100d2d693a8
[  966.798170] R13: ffff81011cc6c588 R14: ffff8100d2d693a8 R15: ffffffff80302726
[  966.805505] FS:  00007f9e739d96f0(0000) GS:ffff81011ff12700(0000)
knlGS:0000000000000000
[  966.813805] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[  966.819703] CR2: 0000000001b691d0 CR3: 0000000069861000 CR4: 00000000000006e0
[  966.827039] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  966.834362] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  966.841687]
[  966.841687] Call Trace:
[  966.845728]  [<ffffffff8022cf4d>] __wake_up+0x2d/0x70
[  966.850900]  [<ffffffff802f5e6e>] nfs_free_unlinkdata+0x1e/0x50
[  966.857004]  [<ffffffff80593f66>] rpc_release_calldata+0x26/0x50
[  966.863161]  [<ffffffff80594930>] rpc_async_schedule+0x0/0x10
[  966.869078]  [<ffffffff80245cec>] run_workqueue+0xcc/0x170
[  966.874705]  [<ffffffff802467a0>] worker_thread+0x0/0xb0
[  966.880163]  [<ffffffff802467a0>] worker_thread+0x0/0xb0
[  966.885610]  [<ffffffff8024680d>] worker_thread+0x6d/0xb0
[  966.891148]  [<ffffffff8024a140>] autoremove_wake_function+0x0/0x30
[  966.897606]  [<ffffffff802467a0>] worker_thread+0x0/0xb0
[  966.903045]  [<ffffffff802467a0>] worker_thread+0x0/0xb0
[  966.908485]  [<ffffffff80249d5b>] kthread+0x4b/0x80
[  966.913484]  [<ffffffff8020ca28>] child_rip+0xa/0x12
[  966.918579]  [<ffffffff80249d10>] kthread+0x0/0x80
[  966.923498]  [<ffffffff8020ca1e>] child_rip+0x0/0x12
[  966.928584]

I will not include the output from SysRq+W, because it looks uninteresting and broken, it no longer seems to print the names of the blocke processed...

[  932.591037] SysRq : Show Blocked State
[  932.594896]  ffff81007e807df0 0000000000000086 00000000000081a4
0000000100000001
[  932.602539]  0000000000000000 00000000000008f7 ffffffff80816b00
ffffffff80816b00
[  932.610149]  ffffffff80812f00 ffffffff80816b00 0000000047336c47
000000001cca6e17
[  932.617595] Call Trace:
[  932.620307]  [<ffffffff805b03d7>] __down+0xa7/0x11e
[  932.625303]  [<ffffffff8022d480>] default_wake_function+0x0/0x10
[  932.631468]  [<ffffffff805b0055>] __down_failed+0x35/0x3a
[  932.637012]  [<ffffffff803870d0>] dummy_file_permission+0x0/0x10
[  932.643177]  [<ffffffff805b0715>] lock_kernel+0x25/0x30
[  932.648546]  [<ffffffff803f0d8c>] tty_write+0x18c/0x250
[  932.653910]  [<ffffffff803f3760>] write_chan+0x0/0x3b0
[  932.659184]  [<ffffffff80293469>] vfs_write+0xe9/0x170
[  932.664459]  [<ffffffff80293b03>] sys_write+0x53/0x90
[  932.669642]  [<ffffffff8020bc0e>] system_call+0x7e/0x83
[  932.675011]

Quoted 68 lines

---

Subject: Embed a struct path into struct nameidata breakes NFSv4

I accidently break NFSv4. Here is the original report by Torsten Kaiser:

Quoted 15 lines

Quoted 15 lines
Breaks nfsv4 in a rather funny way:
treogen ~ # cd /usr/portage/x
treogen x # touch bla
touch: cannot touch `bla': File exists
treogen x # mkdir bla
treogen x # touch bla/bla
touch: cannot touch `bla/bla': File exists
treogen x # ls -lad *
drwxr-xr-x 2 root root 6 Nov 14 20:03 bla
treogen x # ls -la *
total 0
drwxr-xr-x 2 root root 6 Nov 14 20:03 .
drwxr-xr-x 3 root root 16 Nov 14 20:03 ..
treogen x #

Signed-off-by Jan Blunck <[email protected]>

---
 fs/nfs/nfs4proc.c |   15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

Index: b/fs/nfs/nfs4proc.c
===================================================================

fs/nfs/nfs4proc.c +12 -3

@@ -1372,7 +1372,10 @@ out_close:
 struct dentry *
 nfs4_atomic_open(struct inode *dir, struct dentry *dentry, struct nameidata *nd)
 {
-       struct path path = nd->path;
+       struct path path = {
+               .mnt = nd->path.mnt,
+               .dentry = dentry,
+       };
        struct iattr attr;
        struct rpc_cred *cred;
        struct nfs4_state *state;

@@ -1411,7 +1414,10 @@ nfs4_atomic_open(struct inode *dir, stru
 int
 nfs4_open_revalidate(struct inode *dir, struct dentry *dentry, int openflags, struct nameidata *nd)
 {
-       struct path path = nd->path;
+       struct path path = {
+               .mnt = nd->path.mnt,
+               .dentry = dentry,
+       };
        struct rpc_cred *cred;
        struct nfs4_state *state;

@@ -1860,7 +1866,10 @@ static int
 nfs4_proc_create(struct inode *dir, struct dentry *dentry, struct iattr *sattr,
                  int flags, struct nameidata *nd)
 {
-       struct path path = nd->path;
+       struct path path = {
+               .mnt = nd->path.mnt,
+               .dentry = dentry,
+       };
        struct nfs4_state *state;
        struct rpc_cred *cred;
        int status = 0;

Jiri Slaby

2007-11-14 20:24 UTC #78 lore raw

broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 1 line · Andrew Morton

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2/2.6.24-rc2-mm1/

Doesn't suspend for me (neither broken-out-2007-11-13-04-14 did) on x86_64. echo mem >/sys/power/state
causes shut down of disk(s) and blinking cursor on 1,1 position. The last working was 2.6.23-rc8-mm2. I haven't tested 2.6.23-mm1, since it didn't work for me.

As usual, I don't know how to debug this and what other info is needed, any thoughts?

regards,

Signature · 2 lines

Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University

Andrew Morton

author maintainer

2007-11-14 20:36 UTC #79 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 12 lines · On Wed, 14 Nov 2007 21:24:39 +0100 Jiri Slaby <[email protected]> wrote:

Quoted 1 line · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2/2.6.24-rc2-mm1/
Doesn't suspend for me (neither broken-out-2007-11-13-04-14 did) on x86_64. echo mem >/sys/power/state
causes shut down of disk(s) and blinking cursor on 1,1 position. The last working was 2.6.23-rc8-mm2. I haven't tested 2.6.23-mm1, since it didn't work for me.
As usual, I don't know how to debug this and what other info is needed, any thoughts?

http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt
would be ideal, please. It's pretty quick. I did it about six times yesterday evening :(

Rafael J. Wysocki

2007-11-14 21:31 UTC #80 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 11 lines · Jiri Slaby

Quoted 1 line · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2/2.6.24-rc2-mm1/
Doesn't suspend for me (neither broken-out-2007-11-13-04-14 did) on x86_64. echo mem >/sys/power/state
causes shut down of disk(s) and blinking cursor on 1,1 position. The last working was 2.6.23-rc8-mm2. I haven't tested 2.6.23-mm1, since it didn't work for me.
As usual, I don't know how to debug this and what other info is needed, any thoughts?

Does the current mainline work?

Rafael

Jiri Slaby

2007-11-15 23:59 UTC #81 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 10 lines · Rafael J. Wysocki

Quoted 7 lines · Jiri Slaby
Quoted 1 line · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2/2.6.24-rc2-mm1/
Doesn't suspend for me (neither broken-out-2007-11-13-04-14 did) on x86_64. echo mem >/sys/power/state
causes shut down of disk(s) and blinking cursor on 1,1 position. The last working was 2.6.23-rc8-mm2. I haven't tested 2.6.23-mm1, since it didn't work for me.
Does the current mainline work?

Yes.

The offending -mm patch is gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch

2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when the patch is applied.

regards,

Signature · 2 lines

Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University

Jiri Slaby

2007-11-15 23:59 UTC #82 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 10 lines · Rafael J. Wysocki

Quoted 7 lines · Jiri Slaby
Quoted 1 line · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2/2.6.24-rc2-mm1/
Doesn't suspend for me (neither broken-out-2007-11-13-04-14 did) on x86_64. echo mem >/sys/power/state
causes shut down of disk(s) and blinking cursor on 1,1 position. The last working was 2.6.23-rc8-mm2. I haven't tested 2.6.23-mm1, since it didn't work for me.
Does the current mainline work?

Yes.

The offending -mm patch is gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch

2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when the patch is applied.

regards,

Signature · 2 lines

Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University

Greg KH

2007-11-16 00:38 UTC #83 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 12 lines · Jiri Slaby

Quoted 10 lines · Rafael J. Wysocki
Quoted 7 lines · Jiri Slaby
Quoted 1 line · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2/2.6.24-rc2-mm1/
Doesn't suspend for me (neither broken-out-2007-11-13-04-14 did) on x86_64. echo mem >/sys/power/state
causes shut down of disk(s) and blinking cursor on 1,1 position. The last working was 2.6.23-rc8-mm2. I haven't tested 2.6.23-mm1, since it didn't work for me.
Does the current mainline work?

Quoted 7 lines

Yes.
The offending -mm patch is gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when the patch is applied.

Thanks for tracking this down. Alan, any thoughts?

thanks,

greg k-h

Greg KH

2007-11-16 00:44 UTC #84 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 12 lines · Jiri Slaby

Quoted 10 lines · Rafael J. Wysocki
Quoted 7 lines · Jiri Slaby
Quoted 1 line · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2/2.6.24-rc2-mm1/
Doesn't suspend for me (neither broken-out-2007-11-13-04-14 did) on x86_64. echo mem >/sys/power/state
causes shut down of disk(s) and blinking cursor on 1,1 position. The last working was 2.6.23-rc8-mm2. I haven't tested 2.6.23-mm1, since it didn't work for me.
Does the current mainline work?

Quoted 7 lines

Yes.
The offending -mm patch is gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when the patch is applied.

Thanks for tracking this down. Alan, any thoughts?

thanks,

greg k-h

Alan Stern

maintainer

2007-11-16 16:10 UTC #85 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 7 lines · Greg KH

Quoted 5 lines
The offending -mm patch is gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when the patch is applied.
Thanks for tracking this down. Alan, any thoughts?

It's a driver problem somewhere. Probably not one of the most common drivers because I don't see the same problem here (but then I'm not testing -mm).

The thing to do is figure out which driver is causing the problem. Jiri, try enabling CONFIG_DEBUG_DRIVER. If there's also a config option to prevent the console from being suspended, set it as well. Then you should be able to tell which driver is making trouble.

Alan Stern

maintainer

2007-11-16 16:10 UTC #86 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

In reply to Greg KH

Quoted 7 lines · Greg KH

Quoted 5 lines
The offending -mm patch is gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when the patch is applied.
Thanks for tracking this down. Alan, any thoughts?

It's a driver problem somewhere. Probably not one of the most common drivers because I don't see the same problem here (but then I'm not testing -mm).

Alan Stern

Jiri Slaby

2007-11-17 15:08 UTC #87 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 7 lines · Alan Stern

Quoted 5 lines · Greg KH
Quoted 5 lines
The offending -mm patch is gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when the patch is applied.

Quoted 8 lines

Quoted 1 line
Thanks for tracking this down. Alan, any thoughts?
It's a driver problem somewhere. Probably not one of the most common drivers because I don't see the same problem here (but then I'm not testing -mm).
The thing to do is figure out which driver is causing the problem. Jiri, try enabling CONFIG_DEBUG_DRIVER.

Sadly no output.

Quoted 2 lines

If there's also a config
option to prevent the console from being suspended, set it as well.

no_suspend_console kernel parameter has no effect (why?).

Quoted 1 line

Then you should be able to tell which driver is making trouble.

I think no unusual hardware inside:

00:00.0 Host bridge: Intel Corporation 82G33/G31/P35 Express DRAM Controller (rev 02)
Subsystem: Intel Corporation 82G33/G31/P35 Express DRAM Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort+ >SERR- <PERR-
Latency: 0
Capabilities: [e0] Vendor Specific Information
00: 86 80 c0 29 06 00 90 20 02 00 00 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 c0 29
30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00

00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 02) (prog-if 00 [VGA])
Subsystem: Intel Corporation 82G33/G31 Express Integrated Graphics
Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 0: Memory at ffa80000 (32-bit, non-prefetchable) [size=512K] Region 1: I/O ports at ec00 [size=8]
Region 2: Memory at d0000000 (32-bit, prefetchable) [size=256M] Region 3: Memory at ff900000 (32-bit, non-prefetchable) [size=1M]
Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0
Enable-
Address: 00000000 Data: 0000
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 86 80 c2 29 07 00 90 00 02 00 00 03 00 00 00 00
10: 00 00 a8 ff 01 ec 00 00 08 00 00 d0 00 00 90 ff
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 c2 29
30: 00 00 00 00 90 00 00 00 00 00 00 00 0a 01 00 00

00:03.0 Communication controller: Intel Corporation 82G33/G31/P35 Express MEI Controller (rev 02)
Subsystem: Intel Corporation 82G33/G31/P35 Express MEI Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 10
Region 0: Memory at ffa7bc00 (64-bit, non-prefetchable) [size=16]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [8c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Enable-

                Address: 0000000000000000  Data: 0000

00: 86 80 c4 29 06 00 10 00 02 00 80 07 00 00 80 00 10: 04 bc a7 ff 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 c4 29 30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 00 00

00:03.2 IDE interface: Intel Corporation 82G33/G31/P35 Express PT IDER Controller (rev 02) (prog-if 85 [Master SecO PriO])
Subsystem: Intel Corporation 82G33/G31/P35 Express PT IDER Controller
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-

        Latency: 0
        Interrupt: pin C routed to IRQ 12
        Region 0: I/O ports at e880 [size=8]
        Region 1: I/O ports at e800 [size=4]
        Region 2: I/O ports at e480 [size=8]
        Region 3: I/O ports at e400 [size=4]
        Region 4: I/O ports at e080 [size=16]
        Capabilities: [c8] Power Management version 3
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA

PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Enable-

                Address: 0000000000000000  Data: 0000

00: 86 80 c6 29 05 00 b0 00 02 85 01 01 00 00 00 00 10: 81 e8 00 00 01 e8 00 00 81 e4 00 00 01 e4 00 00 20: 81 e0 00 00 00 00 00 00 00 00 00 00 86 80 c6 29 30: 00 00 00 00 c8 00 00 00 00 00 00 00 0c 03 00 00

00:03.3 Serial controller: Intel Corporation 82G33/G31/P35 Express Serial KT Controller (rev 02) (prog-if 02 [16550])
Subsystem: Intel Corporation 82G33/G31/P35 Express Serial KT Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 17
Region 0: I/O ports at e000 [size=8]
Region 1: Memory at ffa7a000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [c8] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Enable-

                Address: 0000000000000000  Data: 0000

00: 86 80 c7 29 07 00 b0 00 02 02 00 07 00 00 00 00 10: 01 e0 00 00 00 a0 a7 ff 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 c7 29 30: 00 00 00 00 c8 00 00 00 00 00 00 00 05 02 00 00

00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02)
Subsystem: Intel Corporation Unknown device 0000
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 318
Region 0: Memory at ffa40000 (32-bit, non-prefetchable) [size=128K] Region 1: Memory at ffa79000 (32-bit, non-prefetchable) [size=4K] Region 2: I/O ports at dc00 [size=32]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Enable+
Address: 00000000fee0300c Data: 4191
Capabilities: [e0] Vendor Specific Information
00: 86 80 bd 10 07 04 10 00 02 00 00 02 00 00 00 00
10: 00 00 a4 ff 00 90 a7 ff 01 dc 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 00 00
30: 00 00 00 00 c8 00 00 00 00 00 00 00 0f 01 00 00

00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02) (prog-if 00 [UHCI])
Subsystem: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 4: I/O ports at d880 [size=32]
Capabilities: [50] Vendor Specific Information
00: 86 80 37 29 05 00 90 02 02 00 03 0c 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 81 d8 00 00 00 00 00 00 00 00 00 00 86 80 37 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 00 00

00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 02) (prog-if 00 [UHCI])
Subsystem: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 21
Region 4: I/O ports at d800 [size=32]
Capabilities: [50] Vendor Specific Information
00: 86 80 38 29 05 00 90 02 02 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 d8 00 00 00 00 00 00 00 00 00 00 86 80 38 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0e 02 00 00

00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 02) (prog-if 00 [UHCI])
Subsystem: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin C routed to IRQ 18
Region 4: I/O ports at d480 [size=32]
Capabilities: [50] Vendor Specific Information
00: 86 80 39 29 05 00 90 02 02 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 81 d4 00 00 00 00 00 00 00 00 00 00 86 80 39 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0c 03 00 00

00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02) (prog-if 20 [EHCI])
Subsystem: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin D routed to IRQ 19
Region 0: Memory at ffa7b400 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port
Capabilities: [98] Vendor Specific Information
00: 86 80 3c 29 06 00 90 02 02 20 03 0c 00 00 00 00
10: 00 b4 a7 ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 3c 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 03 04 00 00

00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02)
Subsystem: Intel Corporation 82801I (ICH9 Family) HD Audio Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 22
Region 0: Memory at ffa70000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express Unknown type IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s <64ns, L1 <1us
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
Link: Supported Speed unknown, Width x0, ASPM unknown, Port 0
Link: Latency L0s <64ns, L1 <1us
Link: ASPM Disabled CommClk- ExtSynch-
Link: Speed unknown, Width x0
Capabilities: [100] Virtual Channel
Capabilities: [130] Unknown (5)
00: 86 80 3e 29 06 00 10 00 02 00 03 04 08 00 00 00
10: 04 00 a7 ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 3e 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 07 01 00 00

00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI])
Subsystem: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 23
Region 4: I/O ports at d400 [size=32]
Capabilities: [50] Vendor Specific Information
00: 86 80 34 29 05 00 90 02 02 00 03 0c 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 d4 00 00 00 00 00 00 00 00 00 00 86 80 34 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 00 00

00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI])
Subsystem: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 19
Region 4: I/O ports at d080 [size=32]
Capabilities: [50] Vendor Specific Information
00: 86 80 35 29 05 00 90 02 02 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 81 d0 00 00 00 00 00 00 00 00 00 00 86 80 35 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 03 02 00 00

00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 02) (prog-if 00 [UHCI])
Subsystem: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin D routed to IRQ 16
Region 4: I/O ports at d000 [size=32]
Capabilities: [50] Vendor Specific Information
00: 86 80 36 29 05 00 90 02 02 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 d0 00 00 00 00 00 00 00 00 00 00 86 80 36 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 04 00 00

00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 02) (prog-if 20 [EHCI])
Subsystem: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 23
Region 0: Memory at ffa7b000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port
Capabilities: [98] Vendor Specific Information
00: 86 80 3a 29 06 00 90 02 02 20 03 0c 00 00 00 00
10: 00 b0 a7 ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 3a 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 00 00

00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92) (prog-if 01 [Subtractive decode])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 Memory behind bridge: ff600000-ff6fffff
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: [50] Subsystem: Intel Corporation 82801 PCI Bridge
00: 86 80 4e 24 06 01 10 00 92 01 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 20 f0 00 80 22
20: 60 ff 60 ff f1 ff 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 50 00 00 00 00 00 00 00 ff 00 02 00

00:1f.0 ISA bridge: Intel Corporation Unknown device 2910 (rev 02)
Subsystem: Intel Corporation Unknown device 2910
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: [e0] Vendor Specific Information
00: 86 80 10 29 07 00 10 02 02 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 10 29
30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00

00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller (rev 02) (prog-if 01 [AHCI 1.0])
Subsystem: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA
AHCI Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-

        Latency: 0
        Interrupt: pin B routed to IRQ 319
        Region 0: I/O ports at cc00 [size=8]
        Region 1: I/O ports at c880 [size=4]
        Region 2: I/O ports at c800 [size=8]
        Region 3: I/O ports at c480 [size=4]
        Region 4: I/O ports at c400 [size=32]
        Region 5: Memory at ffa78800 (32-bit, non-prefetchable) [size=2K]
        Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/4

Enable+
Address: fee0300c Data: 4169
Capabilities: [70] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a8] #12 [0010]
Capabilities: [b0] Vendor Specific Information
00: 86 80 22 29 07 04 b0 02 02 01 06 01 00 00 00 00 10: 01 cc 00 00 81 c8 00 00 01 c8 00 00 81 c4 00 00 20: 01 c4 00 00 00 88 a7 ff 00 00 00 00 86 80 22 29 30: 00 00 00 00 80 00 00 00 00 00 00 00 03 02 00 00

00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)
Subsystem: Intel Corporation 82801I (ICH9 Family) SMBus Controller
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-

        Interrupt: pin C routed to IRQ 18
        Region 0: Memory at ffa7b800 (64-bit, non-prefetchable) [size=256]
        Region 4: I/O ports at 0400 [size=32]

00: 86 80 30 29 03 00 80 02 02 00 05 0c 00 00 00 00 10: 04 b8 a7 ff 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 04 00 00 00 00 00 00 00 00 00 00 86 80 30 29 30: 00 00 00 00 00 00 00 00 00 00 00 00 03 03 00 00

00:1f.5 IDE interface: Intel Corporation 82801I (ICH9 Family) 2 port SATA IDE Controller (rev 02) (prog-if 85 [Master SecO PriO])
Subsystem: Intel Corporation 82801I (ICH9 Family) 2 port SATA IDE Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-

        Latency: 0
        Interrupt: pin B routed to IRQ 19
        Region 0: I/O ports at c000 [size=8]
        Region 1: I/O ports at bc00 [size=4]
        Region 2: I/O ports at b880 [size=8]
        Region 3: I/O ports at b800 [size=4]
        Region 4: I/O ports at b480 [size=16]
        Region 5: I/O ports at b400 [size=16]
        Capabilities: [70] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA

PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b0] Vendor Specific Information
00: 86 80 26 29 07 00 b0 02 02 85 01 01 00 00 00 00 10: 01 c0 00 00 01 bc 00 00 81 b8 00 00 01 b8 00 00 20: 81 b4 00 00 01 b4 00 00 00 00 00 00 86 80 26 29 30: 00 00 00 00 70 00 00 00 00 00 00 00 03 02 00 00

00:1f.6 Signal processing controller: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem (rev 02)
Subsystem: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Interrupt: pin C routed to IRQ 12
Region 0: Memory at ffa6f000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 86 80 32 29 02 00 10 00 02 00 80 11 00 00 00 00
10: 04 f0 a6 ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 32 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0c 03 00 00

01:00.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
Subsystem: Wistron NeWeb Corp. CM9 Wireless a/b/g MiniPCI Adapter
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 168 (2500ns min, 7000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 21
Region 0: Memory at ff6f0000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
00: 8c 16 13 00 16 00 90 02 01 00 00 02 08 a8 00 00
10: 00 00 6f ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 01 50 00 00 5f 18 12 10
30: 00 00 00 00 44 00 00 00 00 00 00 00 0e 01 0a 1c

Plugged usb devices:

Bus 004 Device 007: ID 045e:00f0 Microsoft Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00

  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x045e Microsoft Corp.
  idProduct          0x00f0
  bcdDevice            1.01
  iManufacturer           1 Microsoft Corporation
  iProduct                2 Microsoft � Laser Mouse 6000
  iSerial                 0
  bNumConfigurations      1

Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Devices
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 2 Mouse
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 33 US
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 59
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 10

Bus 004 Device 006: ID 0458:004c KYE Systems Corp. (Mouse Systems) Slimstar Pro Keyboard
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10

  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x0458 KYE Systems Corp. (Mouse Systems)
  idProduct          0x004c Slimstar Pro Keyboard
  bcdDevice            1.01
  iManufacturer           1 ABBHOME
  iProduct                2 USB Keyboard
  iSerial                 0
  bNumConfigurations      1

Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 59
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 50mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Devices
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 1 Keyboard
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 65
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Devices
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 2 Mouse
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 104
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10

Bus 004 Device 005: ID 04b4:2050 Cypress Semiconductor Corp. Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10

  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         0 Full speed (or root) hub
  bMaxPacketSize0         8
  idVendor           0x04b4 Cypress Semiconductor Corp.
  idProduct          0x2050
  bcdDevice            0.01
  iManufacturer           1 Bella Corporation
  iProduct                2 GBella Corporation DV Keyboard
  iSerial                 0
  bNumConfigurations      1

Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 3
wHubCharacteristic 0x000d
Per-port power switching
Compound device
Per-port overcurrent protection
bPwrOn2PwrGood 50 * 2 milli seconds
bHubContrCurrent 25 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0x60
Hub Port Status:
Port 1: 0000.0103 power enable connect Port 2: 0000.0303 lowspeed power enable connect Port 3: 0000.0100 power

regards,

Signature · 2 lines

Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University

Jiri Slaby

2007-11-17 15:08 UTC #88 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

In reply to Alan Stern

Quoted 7 lines · Alan Stern

Quoted 5 lines · Greg KH
Quoted 5 lines
The offending -mm patch is gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when the patch is applied.

Quoted 8 lines

Quoted 1 line
Thanks for tracking this down. Alan, any thoughts?
It's a driver problem somewhere. Probably not one of the most common drivers because I don't see the same problem here (but then I'm not testing -mm).
The thing to do is figure out which driver is causing the problem. Jiri, try enabling CONFIG_DEBUG_DRIVER.

Sadly no output.

Quoted 2 lines

If there's also a config
option to prevent the console from being suspended, set it as well.

no_suspend_console kernel parameter has no effect (why?).

Quoted 1 line

Then you should be able to tell which driver is making trouble.

I think no unusual hardware inside:

                Address: 0000000000000000  Data: 0000

        Latency: 0
        Interrupt: pin C routed to IRQ 12
        Region 0: I/O ports at e880 [size=8]
        Region 1: I/O ports at e800 [size=4]
        Region 2: I/O ports at e480 [size=8]
        Region 3: I/O ports at e400 [size=4]
        Region 4: I/O ports at e080 [size=16]
        Capabilities: [c8] Power Management version 3
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA

PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Enable-

                Address: 0000000000000000  Data: 0000

                Address: 0000000000000000  Data: 0000

        Latency: 0
        Interrupt: pin B routed to IRQ 319
        Region 0: I/O ports at cc00 [size=8]
        Region 1: I/O ports at c880 [size=4]
        Region 2: I/O ports at c800 [size=8]
        Region 3: I/O ports at c480 [size=4]
        Region 4: I/O ports at c400 [size=32]
        Region 5: Memory at ffa78800 (32-bit, non-prefetchable) [size=2K]
        Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/4

        Interrupt: pin C routed to IRQ 18
        Region 0: Memory at ffa7b800 (64-bit, non-prefetchable) [size=256]
        Region 4: I/O ports at 0400 [size=32]

        Latency: 0
        Interrupt: pin B routed to IRQ 19
        Region 0: I/O ports at c000 [size=8]
        Region 1: I/O ports at bc00 [size=4]
        Region 2: I/O ports at b880 [size=8]
        Region 3: I/O ports at b800 [size=4]
        Region 4: I/O ports at b480 [size=16]
        Region 5: I/O ports at b400 [size=16]
        Capabilities: [70] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA

Plugged usb devices:

Bus 004 Device 007: ID 045e:00f0 Microsoft Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00

  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x045e Microsoft Corp.
  idProduct          0x00f0
  bcdDevice            1.01
  iManufacturer           1 Microsoft Corporation
  iProduct                2 Microsoft � Laser Mouse 6000
  iSerial                 0
  bNumConfigurations      1

Bus 004 Device 006: ID 0458:004c KYE Systems Corp. (Mouse Systems) Slimstar Pro Keyboard
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10

  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x0458 KYE Systems Corp. (Mouse Systems)
  idProduct          0x004c Slimstar Pro Keyboard
  bcdDevice            1.01
  iManufacturer           1 ABBHOME
  iProduct                2 USB Keyboard
  iSerial                 0
  bNumConfigurations      1

Bus 004 Device 005: ID 04b4:2050 Cypress Semiconductor Corp. Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10

  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         0 Full speed (or root) hub
  bMaxPacketSize0         8
  idVendor           0x04b4 Cypress Semiconductor Corp.
  idProduct          0x2050
  bcdDevice            0.01
  iManufacturer           1 Bella Corporation
  iProduct                2 GBella Corporation DV Keyboard
  iSerial                 0
  bNumConfigurations      1

regards,

Signature · 2 lines

Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University

Jiri Slaby

2007-11-17 15:12 UTC #89 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 5 lines · Jiri Slaby

Quoted 2 lines · Alan Stern
If there's also a config
option to prevent the console from being suspended, set it as well.
no_suspend_console kernel parameter has no effect (why?).

Eh, no, this (/proc/cmdline):
ro root=/dev/md1 reboo1 vga=1 2 no_console_suspend

regards,

Signature · 2 lines

Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University

Jiri Slaby

2007-11-17 15:12 UTC #90 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 5 lines · Jiri Slaby

Quoted 2 lines · Alan Stern
If there's also a config
option to prevent the console from being suspended, set it as well.
no_suspend_console kernel parameter has no effect (why?).

Eh, no, this (/proc/cmdline):
ro root=/dev/md1 reboo1 vga=1 2 no_console_suspend

regards,

Signature · 2 lines

Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University

Alan Stern

maintainer

2007-11-17 16:13 UTC #91 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 4 lines · Jiri Slaby

Quoted 2 lines
The thing to do is figure out which driver is causing the problem. Jiri, try enabling CONFIG_DEBUG_DRIVER.
Sadly no output.

Guess I'll have to try running 2.6.24-rc2-mm1 on my own system. In the meantime, you can try adding some printk statements to drivers/base/power/main.c. In particular, see whether lock_all_devices() gets called from device_suspend(), whether it returns, and how far dpm_suspend() manages to get.

Alan Stern

maintainer

2007-11-17 16:13 UTC #92 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 4 lines · Jiri Slaby

Quoted 2 lines
The thing to do is figure out which driver is causing the problem. Jiri, try enabling CONFIG_DEBUG_DRIVER.
Sadly no output.

Alan Stern

Rafael J. Wysocki

2007-11-17 20:20 UTC #93 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 17 lines · Jiri Slaby

Quoted 7 lines · Alan Stern
Quoted 5 lines · Greg KH
Quoted 5 lines
The offending -mm patch is gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when the patch is applied.
Quoted 8 lines
Quoted 1 line
Thanks for tracking this down. Alan, any thoughts?
It's a driver problem somewhere. Probably not one of the most common drivers because I don't see the same problem here (but then I'm not testing -mm).
The thing to do is figure out which driver is causing the problem. Jiri, try enabling CONFIG_DEBUG_DRIVER.

Quoted 6 lines

Sadly no output.
Quoted 2 lines
If there's also a config
option to prevent the console from being suspended, set it as well.
no_suspend_console kernel parameter has no effect (why?).

I'm not sure.

Please try to set CONFIG_PM_VERBOSE.

Alan Stern

maintainer

2007-11-17 21:58 UTC #94 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 20 lines · Rafael J. Wysocki

Quoted 19 lines · Jiri Slaby
Quoted 7 lines · Alan Stern
Quoted 5 lines · Greg KH
Quoted 5 lines
The offending -mm patch is gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when the patch is applied.
Quoted 8 lines
Quoted 1 line
Thanks for tracking this down. Alan, any thoughts?
It's a driver problem somewhere. Probably not one of the most common drivers because I don't see the same problem here (but then I'm not testing -mm).
The thing to do is figure out which driver is causing the problem. Jiri, try enabling CONFIG_DEBUG_DRIVER.
Sadly no output.

Quoted 8 lines

Quoted 4 lines
Quoted 2 lines
If there's also a config
option to prevent the console from being suspended, set it as well.
no_suspend_console kernel parameter has no effect (why?).
I'm not sure.
Please try to set CONFIG_PM_VERBOSE.

I finally got 2.6.24-rc2-mm1 working. Andrew, how come those two recent patches from Greg and Kay (the ones changing alloc_disk_node() and system_bus_init()) aren't in your hot-fixes directory?

There's still a problem. During bootup I get this:

	floppy0: Floppy io-port 0x03f2 in use

That's not supposed to happen; the floppy disk should be working perfectly. Is this a known problem?

Back to the main topic... My system hibernates and resumes with no apparent problem. Jiri, it looks like you'll have to do some debug tracing of the routines in drivers/base/power/main.c.

Alan Stern

maintainer

2007-11-17 21:59 UTC #95 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 20 lines · Rafael J. Wysocki

Quoted 19 lines · Jiri Slaby
Quoted 7 lines · Alan Stern
Quoted 5 lines · Greg KH
Quoted 5 lines
The offending -mm patch is gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when the patch is applied.
Quoted 8 lines
Quoted 1 line
Thanks for tracking this down. Alan, any thoughts?
It's a driver problem somewhere. Probably not one of the most common drivers because I don't see the same problem here (but then I'm not testing -mm).
The thing to do is figure out which driver is causing the problem. Jiri, try enabling CONFIG_DEBUG_DRIVER.
Sadly no output.

Quoted 8 lines

Quoted 4 lines
Quoted 2 lines
If there's also a config
option to prevent the console from being suspended, set it as well.
no_suspend_console kernel parameter has no effect (why?).
I'm not sure.
Please try to set CONFIG_PM_VERBOSE.

I finally got 2.6.24-rc2-mm1 working. Andrew, how come those two recent patches from Greg and Kay (the ones changing alloc_disk_node() and system_bus_init()) aren't in your hot-fixes directory?

There's still a problem. During bootup I get this:

	floppy0: Floppy io-port 0x03f2 in use

That's not supposed to happen; the floppy disk should be working perfectly. Is this a known problem?

Back to the main topic... My system hibernates and resumes with no apparent problem. Jiri, it looks like you'll have to do some debug tracing of the routines in drivers/base/power/main.c.

Alan Stern

Jiri Slaby

2007-11-18 12:42 UTC #96 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Alan Stern napsal(a):

Quoted 6 lines · Rafael J. Wysocki

Quoted 5 lines · Jiri Slaby
Quoted 4 lines · Alan Stern
Quoted 2 lines
The thing to do is figure out which driver is causing the problem. Jiri, try enabling CONFIG_DEBUG_DRIVER.
Sadly no output.

Nice update scripts wiped kern.* from syslog config file out, hence no output before.

Quoted 3 lines

Back to the main topic... My system hibernates and resumes with no apparent problem. Jiri, it looks like you'll have to do some debug tracing of the routines in drivers/base/power/main.c.

Beside this two nothing strange:

dpm_suspend: b 00:06

WARNING: at /home/l/latest/bughunt/kernel/resource.c:185 __release_resource()

Call Trace:
 [<ffffffff8023f7b5>] release_resource+0xb5/0xf0
 [<ffffffff8036cda0>] pnp_release_resources+0x70/0x130
 [<ffffffff8036db85>] pnp_stop_dev+0x45/0x90
 [<ffffffff8036c942>] pnp_bus_suspend+0x92/0xb0
 [<ffffffff803b9f73>] suspend_device+0x113/0x180
 [<ffffffff803ba330>] device_suspend+0x200/0x320
 [<ffffffff80266905>] suspend_devices_and_enter+0xa5/0x170
 [<ffffffff80266bd9>] enter_state+0x209/0x270
 [<ffffffff80266cef>] state_store+0xaf/0xf0
 [<ffffffff8032ca67>] kobj_attr_store+0x17/0x20
 [<ffffffff802e459e>] sysfs_write_file+0xce/0x140
 [<ffffffff80299cc7>] vfs_write+0xc7/0x170
 [<ffffffff8029a360>] sys_write+0x50/0x90
 [<ffffffff8020bcde>] system_call+0x7e/0x83

WARNING: at /home/l/latest/bughunt/kernel/resource.c:189 __release_resource()

Call Trace:
 [<ffffffff8023f7e0>] release_resource+0xe0/0xf0
 [<ffffffff8036cda0>] pnp_release_resources+0x70/0x130
 [<ffffffff8036db85>] pnp_stop_dev+0x45/0x90
 [<ffffffff8036c942>] pnp_bus_suspend+0x92/0xb0
 [<ffffffff803b9f73>] suspend_device+0x113/0x180
 [<ffffffff803ba330>] device_suspend+0x200/0x320
 [<ffffffff80266905>] suspend_devices_and_enter+0xa5/0x170
 [<ffffffff80266bd9>] enter_state+0x209/0x270
 [<ffffffff80266cef>] state_store+0xaf/0xf0
 [<ffffffff8032ca67>] kobj_attr_store+0x17/0x20
 [<ffffffff802e459e>] sysfs_write_file+0xce/0x140
 [<ffffffff80299cc7>] vfs_write+0xc7/0x170
 [<ffffffff8029a360>] sys_write+0x50/0x90
 [<ffffffff8020bcde>] system_call+0x7e/0x83

...
dpm_suspend: b 0000:00:1f.5
ACPI Error (psargs-0355): [FZHD] Namespace lookup failure, AE_NOT_FOUND ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.SAT1.CHN0._GTM] (Node FFFF81007D000220), AE_NOT_FOUND ACPI Error (psargs-0355): [FZHD] Namespace lookup failure, AE_NOT_FOUND ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.SAT1.CHN1._GTM] (Node FFFF81007D000360), AE_NOT_FOUND

It's stuck at _cpu_down (enter_state -> suspend_devices_and_enter -> disable_nonboot_cpus -> _cpu_down) after calling raw_notifier_call_chain

        printk("%s: s\n", __func__);
        /* Wait for it to sleep (leaving idle task). */
        while (!idle_cpu(cpu))
                yield();

        printk("%s: t\n", __func__);
        /* This actually kills the CPU. */
        __cpu_die(cpu);

        printk("%s: u\n", __func__);
        BUBAK=1;
        /* CPU is completely dead: tell everyone.  Too late to complain. */
        if (raw_notifier_call_chain(&cpu_chain, CPU_DEAD | mod,
                                    hcpu) == NOTIFY_BAD)
                BUG();
        BUBAK=0;

        printk("%s: v\n", __func__);

See shot of prints here:
http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png

notifier_call_chain looks like:

        while (nb && nr_to_call) {
                next_nb = rcu_dereference(nb->next);
                ret = nb->notifier_call(nb, val, v);
                if (unlikely(BUBAK && cnt < 20 && (ret != lastr ||
                                lastp != nb->notifier_call))) {
                        printk("%s: c %p %d\n", __func__, nb->notifier_call,
                                        ret);
                        lastr = ret;
                        lastp = nb->notifier_call;
                        cnt++;
                }

                if (nr_calls)
                        (*nr_calls)++;

                if ((ret & NOTIFY_STOP_MASK) == NOTIFY_STOP_MASK)
                        break;
                nb = next_nb;
                nr_to_call--;
        }

System.map is here if you are curoius what are the pointers from the snapshot:
http://www.fi.muni.cz/~xslaby/sklad/System.map

regards,

Signature · 2 lines

http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz

Jiri Slaby

2007-11-18 12:42 UTC #97 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

In reply to Alan Stern

Alan Stern napsal(a):

Quoted 6 lines · Rafael J. Wysocki

Quoted 5 lines · Jiri Slaby
Quoted 4 lines · Alan Stern
Quoted 2 lines
The thing to do is figure out which driver is causing the problem. Jiri, try enabling CONFIG_DEBUG_DRIVER.
Sadly no output.

Nice update scripts wiped kern.* from syslog config file out, hence no output before.

Quoted 3 lines

Back to the main topic... My system hibernates and resumes with no apparent problem. Jiri, it looks like you'll have to do some debug tracing of the routines in drivers/base/power/main.c.

Beside this two nothing strange:

dpm_suspend: b 00:06

WARNING: at /home/l/latest/bughunt/kernel/resource.c:185 __release_resource()

Call Trace:
 [<ffffffff8023f7b5>] release_resource+0xb5/0xf0
 [<ffffffff8036cda0>] pnp_release_resources+0x70/0x130
 [<ffffffff8036db85>] pnp_stop_dev+0x45/0x90
 [<ffffffff8036c942>] pnp_bus_suspend+0x92/0xb0
 [<ffffffff803b9f73>] suspend_device+0x113/0x180
 [<ffffffff803ba330>] device_suspend+0x200/0x320
 [<ffffffff80266905>] suspend_devices_and_enter+0xa5/0x170
 [<ffffffff80266bd9>] enter_state+0x209/0x270
 [<ffffffff80266cef>] state_store+0xaf/0xf0
 [<ffffffff8032ca67>] kobj_attr_store+0x17/0x20
 [<ffffffff802e459e>] sysfs_write_file+0xce/0x140
 [<ffffffff80299cc7>] vfs_write+0xc7/0x170
 [<ffffffff8029a360>] sys_write+0x50/0x90
 [<ffffffff8020bcde>] system_call+0x7e/0x83

WARNING: at /home/l/latest/bughunt/kernel/resource.c:189 __release_resource()

Call Trace:
 [<ffffffff8023f7e0>] release_resource+0xe0/0xf0
 [<ffffffff8036cda0>] pnp_release_resources+0x70/0x130
 [<ffffffff8036db85>] pnp_stop_dev+0x45/0x90
 [<ffffffff8036c942>] pnp_bus_suspend+0x92/0xb0
 [<ffffffff803b9f73>] suspend_device+0x113/0x180
 [<ffffffff803ba330>] device_suspend+0x200/0x320
 [<ffffffff80266905>] suspend_devices_and_enter+0xa5/0x170
 [<ffffffff80266bd9>] enter_state+0x209/0x270
 [<ffffffff80266cef>] state_store+0xaf/0xf0
 [<ffffffff8032ca67>] kobj_attr_store+0x17/0x20
 [<ffffffff802e459e>] sysfs_write_file+0xce/0x140
 [<ffffffff80299cc7>] vfs_write+0xc7/0x170
 [<ffffffff8029a360>] sys_write+0x50/0x90
 [<ffffffff8020bcde>] system_call+0x7e/0x83

It's stuck at _cpu_down (enter_state -> suspend_devices_and_enter -> disable_nonboot_cpus -> _cpu_down) after calling raw_notifier_call_chain

        printk("%s: s\n", __func__);
        /* Wait for it to sleep (leaving idle task). */
        while (!idle_cpu(cpu))
                yield();

        printk("%s: t\n", __func__);
        /* This actually kills the CPU. */
        __cpu_die(cpu);

        printk("%s: u\n", __func__);
        BUBAK=1;
        /* CPU is completely dead: tell everyone.  Too late to complain. */
        if (raw_notifier_call_chain(&cpu_chain, CPU_DEAD | mod,
                                    hcpu) == NOTIFY_BAD)
                BUG();
        BUBAK=0;

        printk("%s: v\n", __func__);

See shot of prints here:
http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png

notifier_call_chain looks like:

        while (nb && nr_to_call) {
                next_nb = rcu_dereference(nb->next);
                ret = nb->notifier_call(nb, val, v);
                if (unlikely(BUBAK && cnt < 20 && (ret != lastr ||
                                lastp != nb->notifier_call))) {
                        printk("%s: c %p %d\n", __func__, nb->notifier_call,
                                        ret);
                        lastr = ret;
                        lastp = nb->notifier_call;
                        cnt++;
                }

                if (nr_calls)
                        (*nr_calls)++;

                if ((ret & NOTIFY_STOP_MASK) == NOTIFY_STOP_MASK)
                        break;
                nb = next_nb;
                nr_to_call--;
        }

System.map is here if you are curoius what are the pointers from the snapshot:
http://www.fi.muni.cz/~xslaby/sklad/System.map

regards,

Signature · 2 lines

http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz

Jiri Slaby

2007-11-18 13:06 UTC #98 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 2 lines · Jiri Slaby

See shot of prints here:
http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png

BTW output from that tree minus the patch:
_cpu_down: s
_cpu_down: t
CPU 1 is now offline
SMP alternatives: switching to UP code _cpu_down: u
notifier_call_chain: c FFFFFFFF80232370 1
notifier_call_chain: c FFFFFFFF8026EF10 1
notifier_call_chain: c FFFFFFFF8024B8F0 1
notifier_call_chain: c FFFFFFFF802419E0 1
notifier_call_chain: c FFFFFFFF80255B50 1
notifier_call_chain: c FFFFFFFF80250C40 1
notifier_call_chain: c FFFFFFFF8028E8F0 1
notifier_call_chain: c FFFFFFFF802B59C0 1
notifier_call_chain: c FFFFFFFF80323460 1
notifier_call_chain: c FFFFFFFF80270990 0
notifier_call_chain: c FFFFFFFF8023D5D0 1
notifier_call_chain: c FFFFFFFF80266090 1
notifier_call_chain: c FFFFFFFF802320A0 1
notifier_call_chain: c FFFFFFFF80249DA0 1
notifier_call_chain: c FFFFFFFF80318440 1
notifier_call_chain: c FFFFFFFF8047BE80 1
notifier_call_chain: c FFFFFFFF80212F40 0
notifier_call_chain: c FFFFFFFF80216350 1
notifier_call_chain: c FFFFFFFF80217220 1
notifier_call_chain: c FFFFFFFF80218120 1 _cpu_down: v
_cpu_down: w
_cpu_down: x
_cpu_down: y
_cpu_down: z
disable_nonboot_cpus: 3 0

regards,

Signature · 2 lines

Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University

Jiri Slaby

2007-11-18 13:06 UTC #99 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 2 lines · Jiri Slaby

See shot of prints here:
http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png

regards,

Signature · 2 lines

Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University

Rafael J. Wysocki

2007-11-18 13:24 UTC #100 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 5 lines · Jiri Slaby

Quoted 2 lines · Jiri Slaby
See shot of prints here:
http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png
BTW output from that tree minus the patch:

Hm, it looks like one of the CPU hotplug notifiers is doing something wrong.

Can you try to see what happens (with the patch applied) if thermal_throttle_cpu_callback() is not registered?

Quoted 31 lines

_cpu_down: s
_cpu_down: t
CPU 1 is now offline
SMP alternatives: switching to UP code _cpu_down: u
notifier_call_chain: c FFFFFFFF80232370 1
notifier_call_chain: c FFFFFFFF8026EF10 1
notifier_call_chain: c FFFFFFFF8024B8F0 1
notifier_call_chain: c FFFFFFFF802419E0 1
notifier_call_chain: c FFFFFFFF80255B50 1
notifier_call_chain: c FFFFFFFF80250C40 1
notifier_call_chain: c FFFFFFFF8028E8F0 1
notifier_call_chain: c FFFFFFFF802B59C0 1
notifier_call_chain: c FFFFFFFF80323460 1
notifier_call_chain: c FFFFFFFF80270990 0
notifier_call_chain: c FFFFFFFF8023D5D0 1
notifier_call_chain: c FFFFFFFF80266090 1
notifier_call_chain: c FFFFFFFF802320A0 1
notifier_call_chain: c FFFFFFFF80249DA0 1
notifier_call_chain: c FFFFFFFF80318440 1
notifier_call_chain: c FFFFFFFF8047BE80 1
notifier_call_chain: c FFFFFFFF80212F40 0
notifier_call_chain: c FFFFFFFF80216350 1
notifier_call_chain: c FFFFFFFF80217220 1
notifier_call_chain: c FFFFFFFF80218120 1 _cpu_down: v
_cpu_down: w
_cpu_down: x
_cpu_down: y
_cpu_down: z
disable_nonboot_cpus: 3 0

Jiri Slaby

2007-11-18 13:53 UTC #101 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 10 lines · Rafael J. Wysocki

Quoted 4 lines · Jiri Slaby
Quoted 2 lines · Jiri Slaby
See shot of prints here:
http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png
BTW output from that tree minus the patch:
Hm, it looks like one of the CPU hotplug notifiers is doing something wrong.
Can you try to see what happens (with the patch applied) if thermal_throttle_cpu_callback() is not registered?

After commenting out
//device_initcall(thermal_throttle_init_device);
it looks like this:
http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png

regards,

Signature · 2 lines

Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University

Jiri Slaby

2007-11-18 13:54 UTC #102 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 10 lines · Rafael J. Wysocki

Quoted 4 lines · Jiri Slaby
Quoted 2 lines · Jiri Slaby
See shot of prints here:
http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png
BTW output from that tree minus the patch:
Hm, it looks like one of the CPU hotplug notifiers is doing something wrong.
Can you try to see what happens (with the patch applied) if thermal_throttle_cpu_callback() is not registered?

After commenting out
//device_initcall(thermal_throttle_init_device);
it looks like this:
http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png

regards,

Signature · 2 lines

Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University

Rafael J. Wysocki

2007-11-18 14:46 UTC #103 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 9 lines · Jiri Slaby

Quoted 8 lines · Rafael J. Wysocki
Quoted 4 lines · Jiri Slaby
Quoted 2 lines · Jiri Slaby
See shot of prints here:
http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png
BTW output from that tree minus the patch:
Hm, it looks like one of the CPU hotplug notifiers is doing something wrong.

Quoted 7 lines

Quoted 2 lines
Can you try to see what happens (with the patch applied) if thermal_throttle_cpu_callback() is not registered?
After commenting out
//device_initcall(thermal_throttle_init_device);
it looks like this:
http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png

Can you also make the new System-map available, please?

Jiri Slaby

2007-11-18 14:49 UTC #104 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 1 line · Rafael J. Wysocki

Can you also make the new System-map available, please?

Sure:
http://www.fi.muni.cz/~xslaby/sklad/System.map1

Jiri Slaby

2007-11-18 14:49 UTC #105 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

In reply to Rafał J. Wysocki

Quoted 1 line · Rafael J. Wysocki

Can you also make the new System-map available, please?

Sure:
http://www.fi.muni.cz/~xslaby/sklad/System.map1

Rafał J. Wysocki

2007-11-18 15:05 UTC #106 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 5 lines · Jiri Slaby

Quoted 1 line · Rafael J. Wysocki
Can you also make the new System-map available, please?
Sure:
http://www.fi.muni.cz/~xslaby/sklad/System.map1

The last notifier called in http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png
is apparently cpu_swap_callback() which is not called in
http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png .

Can you verify that cpu_swap_callback() gets called if the patch is not applied?

Jiri Slaby

2007-11-18 15:15 UTC #107 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 7 lines · Rafał J. Wysocki

Quoted 4 lines · Jiri Slaby
Quoted 1 line · Rafael J. Wysocki
Can you also make the new System-map available, please?
Sure:
http://www.fi.muni.cz/~xslaby/sklad/System.map1
The last notifier called in http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png

Last... Note, that it's only first 20 invokations of notifiers, there are bazillion of them when I remove the condition '< 20'.

Quoted 5 lines

is apparently cpu_swap_callback() which is not called in
http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png .
Can you verify that cpu_swap_callback() gets called if the patch is not applied?

Does this still apply?

Jiri Slaby

2007-11-18 15:15 UTC #108 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 7 lines · Rafał J. Wysocki

Quoted 4 lines · Jiri Slaby
Quoted 1 line · Rafael J. Wysocki
Can you also make the new System-map available, please?
Sure:
http://www.fi.muni.cz/~xslaby/sklad/System.map1
The last notifier called in http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png

Last... Note, that it's only first 20 invokations of notifiers, there are bazillion of them when I remove the condition '< 20'.

Quoted 5 lines

is apparently cpu_swap_callback() which is not called in
http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png .
Can you verify that cpu_swap_callback() gets called if the patch is not applied?

Does this still apply?

Alan Stern

maintainer

2007-11-18 17:07 UTC #109 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 12 lines · Jiri Slaby

Quoted 7 lines · RafaÅ‚ J. Wysocki
Quoted 4 lines · Jiri Slaby
Quoted 1 line · Rafael J. Wysocki
Can you also make the new System-map available, please?
Sure:
http://www.fi.muni.cz/~xslaby/sklad/System.map1
The last notifier called in http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png
Last... Note, that it's only first 20 invokations of notifiers, there are bazillion of them when I remove the condition '< 20'.

Quoted 7 lines

Quoted 5 lines
is apparently cpu_swap_callback() which is not called in
http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png .
Can you verify that cpu_swap_callback() gets called if the patch is not applied?
Does this still apply?

You'll get more useful results if you redo your changes to notifier_call_chain(). Have it print out the address of the routine _before_ making the call, and don't limit it to 20. That way you'll know exactly which notifier routine ends up hanging.

Alan Stern

maintainer

2007-11-18 17:07 UTC #110 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 12 lines · Jiri Slaby

Quoted 7 lines · RafaÅ‚ J. Wysocki
Quoted 4 lines · Jiri Slaby
Quoted 1 line · Rafael J. Wysocki
Can you also make the new System-map available, please?
Sure:
http://www.fi.muni.cz/~xslaby/sklad/System.map1
The last notifier called in http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png
Last... Note, that it's only first 20 invokations of notifiers, there are bazillion of them when I remove the condition '< 20'.

Quoted 7 lines

Quoted 5 lines
is apparently cpu_swap_callback() which is not called in
http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png .
Can you verify that cpu_swap_callback() gets called if the patch is not applied?
Does this still apply?

Alan Stern

Jiri Slaby

2007-11-18 19:09 UTC #111 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 4 lines · Alan Stern

You'll get more useful results if you redo your changes to notifier_call_chain(). Have it print out the address of the routine _before_ making the call, and don't limit it to 20. That way you'll know exactly which notifier routine ends up hanging.

The problem is, that notifier_call_chain is called again and again zillion times by somebody else...

Anyway you led me to another idea:
* _cpu_down

        printk("%s: u\n", __func__);
        BUBAK=1;
        /* CPU is completely dead: tell everyone.  Too late to complain. */
        if (raw_notifier_call_chain(&cpu_chain, CPU_DEAD | 0x88000 | mod,
                                    hcpu) == NOTIFY_BAD)
                BUG();
        BUBAK=0;
-----
* notifier_call_chain
        unsigned int a = val & 0x88000;
        unsigned int yes = a == 0x88000;

        nb = rcu_dereference(*nl);

        if (a && a != 0x88000)
                printk("Somebody calls with val: %lx\n", val);
        else
                val &= ~0x88000;

        while (nb && nr_to_call) {
                next_nb = rcu_dereference(nb->next);
                if (unlikely(BUBAK && yes))
                        printk("%s: %p\n", __func__, nb->notifier_call);
                ret = nb->notifier_call(nb, val, v);

-----
gives coretemp_cpu_callback -> coretemp_device_remove -> platform_device_unregister, so coretemp seems to be what I have and you don't.

Rafael J. Wysocki

2007-11-18 22:10 UTC #112 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 8 lines · Jiri Slaby

Quoted 4 lines · Alan Stern
You'll get more useful results if you redo your changes to notifier_call_chain(). Have it print out the address of the routine _before_ making the call, and don't limit it to 20. That way you'll know exactly which notifier routine ends up hanging.
The problem is, that notifier_call_chain is called again and again zillion times by somebody else...

You can use a global variable to switch the logging only before the CPU hotunplug done by the suspend code. You just need to hack disable_nonboot_cpus() for that.

Jiri Slaby

2007-11-18 22:12 UTC #113 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 3 lines · Rafael J. Wysocki

You can use a global variable to switch the logging only before the CPU hotunplug done by the suspend code. You just need to hack disable_nonboot_cpus() for that.

If I understand you correctly, that's what BUBAK variable is there for. But it is still called again and again while the suspend code runs...

regards,

Signature · 2 lines

Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University

Jiri Slaby

2007-11-18 22:13 UTC #114 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 3 lines · Rafael J. Wysocki

You can use a global variable to switch the logging only before the CPU hotunplug done by the suspend code. You just need to hack disable_nonboot_cpus() for that.

If I understand you correctly, that's what BUBAK variable is there for. But it is still called again and again while the suspend code runs...

regards,

Signature · 2 lines

Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University

Rafael J. Wysocki

2007-11-18 22:24 UTC #115 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 6 lines · Jiri Slaby

Quoted 3 lines · Rafael J. Wysocki
You can use a global variable to switch the logging only before the CPU hotunplug done by the suspend code. You just need to hack disable_nonboot_cpus() for that.
If I understand you correctly, that's what BUBAK variable is there for.

Ah, yes.

-ETOOTIRED

Quoted 1 line

But it is still called again and again while the suspend code runs...

You can count the number of calls and then make it print the information for the last, say, 20 of them.

Greetings,
Rafael

Rafael J. Wysocki

2007-11-18 22:42 UTC #116 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 6 lines · Jiri Slaby

Quoted 3 lines · Rafael J. Wysocki
You can use a global variable to switch the logging only before the CPU hotunplug done by the suspend code. You just need to hack disable_nonboot_cpus() for that.
If I understand you correctly, that's what BUBAK variable is there for.

Ah, yes.

-ETOOTIRED

Quoted 1 line

But it is still called again and again while the suspend code runs...

You can count the number of calls and then make it print the information for the last, say, 20 of them.

Greetings,
Rafael

Jiri Slaby

2007-11-18 22:27 UTC #117 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h‹b7844286fb8c9fce6f65d8288aeb09d03a5e0d

Aah, we probably should let coretemp people known.

Whole thread:
http://marc.info/?t=119507205800001&r=1&w=2

Quoted 35 lines · Jiri Slaby

Quoted 4 lines · Alan Stern
You'll get more useful results if you redo your changes to notifier_call_chain(). Have it print out the address of the routine _before_ making the call, and don't limit it to 20. That way you'll know exactly which notifier routine ends up hanging.
The problem is, that notifier_call_chain is called again and again zillion times by somebody else...
Anyway you led me to another idea:
* _cpu_down
        printk("%s: u\n", __func__);
        BUBAK=1;
        /* CPU is completely dead: tell everyone.  Too late to complain. */
        if (raw_notifier_call_chain(&cpu_chain, CPU_DEAD | 0x88000 | mod,
                                    hcpu) == NOTIFY_BAD)
                BUG();
        BUBAK=0;
-----
* notifier_call_chain
        unsigned int a = val & 0x88000;
        unsigned int yes = a == 0x88000;

        nb = rcu_dereference(*nl);

        if (a && a != 0x88000)
                printk("Somebody calls with val: %lx\n", val);
        else
                val &= ~0x88000;

        while (nb && nr_to_call) {
                next_nb = rcu_dereference(nb->next);
                if (unlikely(BUBAK && yes))
                        printk("%s: %p\n", __func__, nb->notifier_call);
                ret = nb->notifier_call(nb, val, v);

Quoted 3 lines

-----
gives coretemp_cpu_callback -> coretemp_device_remove -> platform_device_unregister, so coretemp seems to be what I have and you don't.

Just in case you are curious:
http://www.fi.muni.cz/~xslaby/sklad/susp_hang3.diff
produces:
http://www.fi.muni.cz/~xslaby/sklad/susp_hang3.png

Alan Stern

maintainer

2007-11-19 03:04 UTC #118 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 2 lines · Jiri Slaby

Quoted 2 lines
gives coretemp_cpu_callback -> coretemp_device_remove -> platform_device_unregister, so coretemp seems to be what I have and you don't.

Yes.

For the coretemp developers: coretemp_cpu_callback() needs to be more careful about what it does. During a system sleep transition (suspend, hibernate, resume) it isn't possible to register or unregister a device. Attempts to register will fail and attempts to unregister will block until the system sleep is over -- and for this callback that means hanging.

It's not clear what the best way is to fix this. Perhaps the CPU notification should be sent along with a special flag indicating that the CPU transition is part of a system sleep (although this seems racy). Perhaps the driver should notice when a system sleep begins, and defer all CPU-change handling until after the sleep is over.

Alan Stern

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Rudolf Marek

2007-11-19 20:01 UTC #119 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Hello all,

Quoted 11 lines

Quoted 2 lines
Quoted 2 lines
gives coretemp_cpu_callback -> coretemp_device_remove -> platform_device_unregister, so coretemp seems to be what I have and you don't.
Yes.
For the coretemp developers: coretemp_cpu_callback() needs to be more careful about what it does. During a system sleep transition (suspend, hibernate, resume) it isn't possible to register or unregister a device. Attempts to register will fail and attempts to unregister will block until the system sleep is over -- and for this callback that means hanging.

Well I wrote the driver. Thanks for the clarification. If I recall correctly I looked how this part should be done from others drivers. Now while checking what happened to the file, seems Rafael added something related.

Quoted 5 lines

It's not clear what the best way is to fix this. Perhaps the CPU notification should be sent along with a special flag indicating that the CPU transition is part of a system sleep (although this seems racy). Perhaps the driver should notice when a system sleep begins, and defer all CPU-change handling until after the sleep is over.

maybe it does exist? CPU_DOWN_PREPARE ?

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cpu-hotplug.txt;hb=HEAD

Unfortunately I'm not very familiar with this, calling the coretemp_device_remove from CPU_DOWN_PREPARE would help? Looking at microcode driver, seems it just hide sysfs interface from user.

Thanks,
Rudolf

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Alan Stern

maintainer

2007-11-19 20:27 UTC #120 lore raw

Re: broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 13 lines · Rudolf Marek

Hello all,
Quoted 11 lines
Quoted 2 lines
Quoted 2 lines
gives coretemp_cpu_callback -> coretemp_device_remove -> platform_device_unregister, so coretemp seems to be what I have and you don't.
Yes.
For the coretemp developers: coretemp_cpu_callback() needs to be more careful about what it does. During a system sleep transition (suspend, hibernate, resume) it isn't possible to register or unregister a device. Attempts to register will fail and attempts to unregister will block until the system sleep is over -- and for this callback that means hanging.

Quoted 5 lines

Well I wrote the driver. Thanks for the clarification. If I recall correctly I looked how this part should be done from others drivers. Now while checking what happened to the file, seems Rafael added something related.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h‹b7844286fb8c9fce6f65d8288aeb09d03a5e0d

That does look like it was meant for exactly this sort of situation.

Quoted 6 lines

Quoted 5 lines
It's not clear what the best way is to fix this. Perhaps the CPU notification should be sent along with a special flag indicating that the CPU transition is part of a system sleep (although this seems racy). Perhaps the driver should notice when a system sleep begins, and defer all CPU-change handling until after the sleep is over.

Quoted 7 lines

maybe it does exist? CPU_DOWN_PREPARE ?
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cpu-hotplug.txt;hb=HEAD
Unfortunately I'm not very familiar with this, calling the coretemp_device_remove from CPU_DOWN_PREPARE would help? Looking at microcode driver, seems it just hide sysfs interface from user.

I'm not sure exactly what you want to do here. But it seems like a waste to unregister the coretemp devices at the start of a system sleep and then register them back at the end.

Could you simply leave the devices registered throughout the entire sleep? Of course, at the end you would have to check that all the CPUs really did come back up, and unregister the devices for the CPUs that are still offline.

Alan Stern

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Mark M. Hoffman

2007-11-20 13:15 UTC #121 lore raw

Re: [lm-sensors] broken suspend [Was: 2.6.24-rc2-mm1]

Hi all:

Quoted 15 lines · Alan Stern

Quoted 13 lines · Rudolf Marek
Hello all,
Quoted 11 lines
Quoted 2 lines
Quoted 2 lines
gives coretemp_cpu_callback -> coretemp_device_remove -> platform_device_unregister, so coretemp seems to be what I have and you don't.
Yes.
For the coretemp developers: coretemp_cpu_callback() needs to be more careful about what it does. During a system sleep transition (suspend, hibernate, resume) it isn't possible to register or unregister a device. Attempts to register will fail and attempts to unregister will block until the system sleep is over -- and for this callback that means hanging.

Quoted 21 lines

Quoted 5 lines
Well I wrote the driver. Thanks for the clarification. If I recall correctly I looked how this part should be done from others drivers. Now while checking what happened to the file, seems Rafael added something related.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h‹b7844286fb8c9fce6f65d8288aeb09d03a5e0d
That does look like it was meant for exactly this sort of situation.
Quoted 13 lines
Quoted 5 lines
It's not clear what the best way is to fix this. Perhaps the CPU notification should be sent along with a special flag indicating that the CPU transition is part of a system sleep (although this seems racy). Perhaps the driver should notice when a system sleep begins, and defer all CPU-change handling until after the sleep is over.
maybe it does exist? CPU_DOWN_PREPARE ?
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cpu-hotplug.txt;hb=HEAD
Unfortunately I'm not very familiar with this, calling the coretemp_device_remove from CPU_DOWN_PREPARE would help? Looking at microcode driver, seems it just hide sysfs interface from user.

AFAICT from that documentation, it would have been better to unregister the device on CPU_DOWN_PREPARE anyway. CPU_DEAD seems to be too late - it's already gone by then.

Quoted 8 lines

I'm not sure exactly what you want to do here. But it seems like a waste to unregister the coretemp devices at the start of a system sleep and then register them back at the end.
Could you simply leave the devices registered throughout the entire sleep? Of course, at the end you would have to check that all the CPUs really did come back up, and unregister the devices for the CPUs that are still offline.

Is it possible to unregister a driver on CPU_DOWN_PREPARE_FROZEN? If so, then the simplest fix would be the patch below (Jiri: feel free to try it). Otherwise it would take a bit of refactoring to bring the sysfs interface down/up for suspend/resume.

commit ce9c7b78c839a6304696d90083eac08baad524ce

Author: Mark M. Hoffman <[email protected]>
Date:   Tue Nov 20 07:51:50 2007 -0500

hwmon: (coretemp) fix suspend/resume hang

Signed-off-by Mark M. Hoffman <[email protected]>

drivers/hwmon/coretemp.c +4 -2

index 5c82ec7..afe2d31 100644
@@ -338,10 +338,12 @@ static int coretemp_cpu_callback(struct notifier_block *nfb,
 	switch (action) {
 	case CPU_ONLINE:
 	case CPU_ONLINE_FROZEN:
+	case CPU_DOWN_FAILED:
+	case CPU_DOWN_FAILED_FROZEN:
 		coretemp_device_add(cpu);
 		break;
-	case CPU_DEAD:
-	case CPU_DEAD_FROZEN:
+	case CPU_DOWN_PREPARE:
+	case CPU_DOWN_PREPARE_FROZEN:
 		coretemp_device_remove(cpu);
 		break;
 	}

Signature · 8 lines

Mark M. Hoffman
[email protected]


_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Rafael J. Wysocki

2007-11-20 23:43 UTC #122 lore raw

Re: [lm-sensors] broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 48 lines · Mark M. Hoffman

Hi all:
Quoted 15 lines · Alan Stern
Quoted 13 lines · Rudolf Marek
Hello all,
Quoted 11 lines
Quoted 2 lines
Quoted 2 lines
gives coretemp_cpu_callback -> coretemp_device_remove -> platform_device_unregister, so coretemp seems to be what I have and you don't.
Yes.
For the coretemp developers: coretemp_cpu_callback() needs to be more careful about what it does. During a system sleep transition (suspend, hibernate, resume) it isn't possible to register or unregister a device. Attempts to register will fail and attempts to unregister will block until the system sleep is over -- and for this callback that means hanging.
Quoted 21 lines
Quoted 5 lines
Well I wrote the driver. Thanks for the clarification. If I recall correctly I looked how this part should be done from others drivers. Now while checking what happened to the file, seems Rafael added something related.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8bb7844286fb8c9fce6f65d8288aeb09d03a5e0d
That does look like it was meant for exactly this sort of situation.
Quoted 13 lines
Quoted 5 lines
It's not clear what the best way is to fix this. Perhaps the CPU notification should be sent along with a special flag indicating that the CPU transition is part of a system sleep (although this seems racy). Perhaps the driver should notice when a system sleep begins, and defer all CPU-change handling until after the sleep is over.
maybe it does exist? CPU_DOWN_PREPARE ?
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cpu-hotplug.txt;hb=HEAD
Unfortunately I'm not very familiar with this, calling the coretemp_device_remove from CPU_DOWN_PREPARE would help? Looking at microcode driver, seems it just hide sysfs interface from user.
AFAICT from that documentation, it would have been better to unregister the device on CPU_DOWN_PREPARE anyway. CPU_DEAD seems to be too late - it's already gone by then.
Quoted 4 lines
I'm not sure exactly what you want to do here. But it seems like a waste to unregister the coretemp devices at the start of a system sleep and then register them back at the end.

Quoted 6 lines

Quoted 4 lines
Could you simply leave the devices registered throughout the entire sleep? Of course, at the end you would have to check that all the CPUs really did come back up, and unregister the devices for the CPUs that are still offline.
Is it possible to unregister a driver on CPU_DOWN_PREPARE_FROZEN?

No. In that case the suspend core is holding the device's mutex and your attempt to unregister it will deadlock with it.

Do you _have_ _to_ unregister the device at all? Why don't you just leave it registered on CPU_DOWN_PREPARE_FROZEN? The CPU is not going away physically in this case and it's _guaranteed_ that _cpu_up() will be called on it as soon as the hibernation image is ready or we are back from suspend.

Quoted 11 lines

If so, then the simplest fix would be the patch below (Jiri: feel free to try it). Otherwise it would take a bit of refactoring to bring the sysfs interface down/up for suspend/resume.
commit ce9c7b78c839a6304696d90083eac08baad524ce
Author: Mark M. Hoffman <[email protected]>
Date:   Tue Nov 20 07:51:50 2007 -0500
hwmon: (coretemp) fix suspend/resume hang
Signed-off-by Mark M. Hoffman <[email protected]>

I'd do it like this:

drivers/hwmon/coretemp.c static int coretemp_cpu_callback(struct notifier_block *nfb, · line 342

Quoted 10 lines

drivers/hwmon/coretemp.c +1 -0

index 5c82ec7..afe2d31 100644
@@ -338,10 +338,12 @@ static int coretemp_cpu_callback(struct notifier_block *nfb,
 	switch (action) {
 	case CPU_ONLINE:
 	case CPU_ONLINE_FROZEN:
+	case CPU_DOWN_FAILED:
 		coretemp_device_add(cpu);

+ case CPU_DOWN_FAILED_FROZEN:

drivers/hwmon/coretemp.c static int coretemp_cpu_callback(struct notifier_block *nfb, · line 347

Quoted 5 lines

drivers/hwmon/coretemp.c +1 -2

 		break;
-	case CPU_DEAD:
-	case CPU_DEAD_FROZEN:
+	case CPU_DOWN_PREPARE:
 		coretemp_device_remove(cpu);

+ case CPU_DOWN_PREPARE_FROZEN:

drivers/hwmon/coretemp.c static int coretemp_cpu_callback(struct notifier_block *nfb, · line 347

Quoted 2 lines

drivers/hwmon/coretemp.c +0 -0
 		break;
 	}

Greetings,
Rafael

Signature · 1 line

"Premature optimization is the root of all evil." - Donald Knuth

Alan Stern

maintainer

2007-11-21 15:54 UTC #123 lore raw

Re: [lm-sensors] broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 9 lines · Rafael J. Wysocki

Quoted 1 line
Is it possible to unregister a driver on CPU_DOWN_PREPARE_FROZEN?
No. In that case the suspend core is holding the device's mutex and your attempt to unregister it will deadlock with it.
Do you _have_ _to_ unregister the device at all? Why don't you just leave it registered on CPU_DOWN_PREPARE_FROZEN? The CPU is not going away physically in this case and it's _guaranteed_ that _cpu_up() will be called on it as soon as the hibernation image is ready or we are back from suspend.

This leaves the device registered if for some reason the number of CPUs after resuming from hibernation is smaller than the number of CPUs before hibernation. Of course, in theory that's never supposed to happen...

Alan Stern

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Rafael J. Wysocki

2007-11-21 19:02 UTC #124 lore raw

Re: [lm-sensors] broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 12 lines · Alan Stern

Quoted 9 lines · Rafael J. Wysocki
Quoted 1 line
Is it possible to unregister a driver on CPU_DOWN_PREPARE_FROZEN?
No. In that case the suspend core is holding the device's mutex and your attempt to unregister it will deadlock with it.
Do you _have_ _to_ unregister the device at all? Why don't you just leave it registered on CPU_DOWN_PREPARE_FROZEN? The CPU is not going away physically in this case and it's _guaranteed_ that _cpu_up() will be called on it as soon as the hibernation image is ready or we are back from suspend.

Quoted 4 lines

This leaves the device registered if for some reason the number of CPUs after resuming from hibernation is smaller than the number of CPUs before hibernation. Of course, in theory that's never supposed to happen...

Yes, that clearly would be a bug.

Rafael

Rafael J. Wysocki

2007-11-21 19:19 UTC #125 lore raw

Re: [lm-sensors] broken suspend [Was: 2.6.24-rc2-mm1]

In reply to Alan Stern

Quoted 12 lines · Alan Stern

Quoted 9 lines · Rafael J. Wysocki
Quoted 1 line
Is it possible to unregister a driver on CPU_DOWN_PREPARE_FROZEN?
No. In that case the suspend core is holding the device's mutex and your attempt to unregister it will deadlock with it.
Do you _have_ _to_ unregister the device at all? Why don't you just leave it registered on CPU_DOWN_PREPARE_FROZEN? The CPU is not going away physically in this case and it's _guaranteed_ that _cpu_up() will be called on it as soon as the hibernation image is ready or we are back from suspend.

Quoted 4 lines

This leaves the device registered if for some reason the number of CPUs after resuming from hibernation is smaller than the number of CPUs before hibernation. Of course, in theory that's never supposed to happen...

Yes, that clearly would be a bug.

Rafael

Alan Stern

maintainer

2007-11-21 15:54 UTC #126 lore raw

Re: [lm-sensors] broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 9 lines · Rafael J. Wysocki

Quoted 1 line
Is it possible to unregister a driver on CPU_DOWN_PREPARE_FROZEN?
No. In that case the suspend core is holding the device's mutex and your attempt to unregister it will deadlock with it.
Do you _have_ _to_ unregister the device at all? Why don't you just leave it registered on CPU_DOWN_PREPARE_FROZEN? The CPU is not going away physically in this case and it's _guaranteed_ that _cpu_up() will be called on it as soon as the hibernation image is ready or we are back from suspend.

Alan Stern

Jiri Slaby

2007-11-26 08:57 UTC #127 lore raw

Re: [lm-sensors] broken suspend [Was: 2.6.24-rc2-mm1]

Quoted 28 lines · Rafael J. Wysocki

Quoted 7 lines · Mark M. Hoffman
commit ce9c7b78c839a6304696d90083eac08baad524ce
Author: Mark M. Hoffman <[email protected]>
Date:   Tue Nov 20 07:51:50 2007 -0500
hwmon: (coretemp) fix suspend/resume hang
Signed-off-by Mark M. Hoffman <[email protected]>
I'd do it like this:
Quoted 10 lines
drivers/hwmon/coretemp.c +1 -0
index 5c82ec7..afe2d31 100644
@@ -338,10 +338,12 @@ static int coretemp_cpu_callback(struct notifier_block *nfb,
 	switch (action) {
 	case CPU_ONLINE:
 	case CPU_ONLINE_FROZEN:
+	case CPU_DOWN_FAILED:
 		coretemp_device_add(cpu);
drivers/hwmon/coretemp.c +1 -0
+	case CPU_DOWN_FAILED_FROZEN: 
Quoted 5 lines
drivers/hwmon/coretemp.c +1 -2
 		break;
-	case CPU_DEAD:
-	case CPU_DEAD_FROZEN:
+	case CPU_DOWN_PREPARE:
 		coretemp_device_remove(cpu);
drivers/hwmon/coretemp.c +1 -0
+	case CPU_DOWN_PREPARE_FROZEN:

Quoted 2 lines

drivers/hwmon/coretemp.c static int coretemp_cpu_callback(struct notifier_block *nfb, · line 347
Quoted 2 lines
drivers/hwmon/coretemp.c +0 -0
 		break;
 	}

Sorry for the delay, this (trimmed version) solves the problem!

thanks,

Signature · 7 lines

Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Jiri Slaby

2007-11-26 08:57 UTC #128 lore raw

Re: [lm-sensors] broken suspend [Was: 2.6.24-rc2-mm1]