Re: 2.6.17-rc5-mm3

Re: 2.6.17-rc5-mm3

[Martin Bligh]

panic on NUMA-Q during LTP. Was fine in -mm2.

BUG: unable to handle kernel paging request at virtual address 22222232
  printing eip:
c012cf84
*pde = 25b5a001
*pte = 00000000
Oops: 0000 [#1]
SMP
last sysfs file: /devices/pci0000:00/0000:00:0a.0/resource
Modules linked in:
CPU:    12
EIP:    0060:[<c012cf84>]    Not tainted VLI
EFLAGS: 00010002   (2.6.17-rc5-mm3-autokern1 #1)
EIP is at check_deadlock+0x19/0xe1
eax: 00000001   ebx: e4453030   ecx: 00000000   edx: e4008000
esi: 22222222   edi: 00000001   ebp: 22222222   esp: e47ebec0
ds: 007b   es: 007b   ss: 0068
Process mkdir09 (pid: 18319, threadinfo=e47ea000 task=e5f91ab0)
Stack: e4453030 22222222 00000000 e459231c c012d015 22222222 00000001 
e4008000
        e459231c e47ea000 e47ebf1c e5f91ab0 c012d1ce e459231c 00000000 
e47ea000
        e47ebf1c e459231c 00000246 c02f1d74 e459231c e47ebf1c e47ea000 
e47ebf1c
Call Trace:
  [<c012d015>] check_deadlock+0xaa/0xe1
  [<c012d1ce>] debug_mutex_add_waiter+0x4a/0x5c
  [<c02f1d74>] __mutex_lock_slowpath+0x9e/0x1cb
  [<c01648a9>] do_rmdir+0x67/0xc2
  [<c02001da>] __put_user_4+0x12/0x18
  [<c016490f>] sys_rmdir+0xb/0xe
  [<c02f2f1f>] syscall_call+0x7/0xb
Code: 0c 68 60 07 31 c0 e8 22 c0 fe ff 58 fa 5b 5e 5f 5d c3 55 83 3d cc 
11 36 c0 00 57 56 53 8b 6c 24 14 8b 7c 24 18 0f 84 c1 00 00 00 <8b> 55 
10 31 c0 85 d2 0f 84 b6 00 00 00 8b 1a 31 f6 8b 83 c4 04
EIP: [<c012cf84>] check_deadlock+0x19/0xe1 SS:ESP 0068:e47ebec0

Re: 2.6.17-rc5-mm3

[Ingo Molnar]

* Martin Bligh <mbligh@google.com> wrote:

> panic on NUMA-Q during LTP. Was fine in -mm2.
> 
> BUG: unable to handle kernel paging request at virtual address 22222232

> EIP is at check_deadlock+0x19/0xe1
> eax: 00000001   ebx: e4453030   ecx: 00000000   edx: e4008000
> esi: 22222222   edi: 00000001   ebp: 22222222   esp: e47ebec0

again these 0x22222222 entries on the stack. What on earth does this? 
Andy got a similar crash on x86_64, with a 0x2222222222222222 entry ...

nothing of our magic values are 0x22 or 0x222222222.

	Ingo

Re: 2.6.17-rc5-mm3

[Randy.Dunlap]

On Mon, 5 Jun 2006 21:44:22 +0200 Ingo Molnar wrote:

> 
> * Martin Bligh <mbligh@google.com> wrote:
> 
> > panic on NUMA-Q during LTP. Was fine in -mm2.
> > 
> > BUG: unable to handle kernel paging request at virtual address 22222232
> 
> > EIP is at check_deadlock+0x19/0xe1
> > eax: 00000001   ebx: e4453030   ecx: 00000000   edx: e4008000
> > esi: 22222222   edi: 00000001   ebp: 22222222   esp: e47ebec0
> 
> again these 0x22222222 entries on the stack. What on earth does this? 
> Andy got a similar crash on x86_64, with a 0x2222222222222222 entry ...
> 
> nothing of our magic values are 0x22 or 0x222222222.

kernel/mutex-debug.c:
void debug_mutex_free_waiter(struct mutex_waiter *waiter)
{
	DEBUG_WARN_ON(!list_empty(&waiter->list));
	memset(waiter, 0x22, sizeof(*waiter));
}

---
~Randy

Re: 2.6.17-rc5-mm3

[Ingo Molnar]

* Randy.Dunlap <rdunlap@xenotime.net> wrote:

> > > panic on NUMA-Q during LTP. Was fine in -mm2.
> > > 
> > > BUG: unable to handle kernel paging request at virtual address 22222232
> > 
> > > EIP is at check_deadlock+0x19/0xe1
> > > eax: 00000001   ebx: e4453030   ecx: 00000000   edx: e4008000
> > > esi: 22222222   edi: 00000001   ebp: 22222222   esp: e47ebec0
> > 
> > again these 0x22222222 entries on the stack. What on earth does this? 
> > Andy got a similar crash on x86_64, with a 0x2222222222222222 entry ...
> > 
> > nothing of our magic values are 0x22 or 0x222222222.
> 
> kernel/mutex-debug.c:
> void debug_mutex_free_waiter(struct mutex_waiter *waiter)
> {
> 	DEBUG_WARN_ON(!list_empty(&waiter->list));
> 	memset(waiter, 0x22, sizeof(*waiter));
> }

ah!!! that's indeed a hint. Will take a look tomorrow.

	Ingo

Re: 2.6.17-rc5-mm3

[Dave Jones]

On Mon, Jun 05, 2006 at 01:00:39PM -0700, Randy.Dunlap wrote:
 > On Mon, 5 Jun 2006 21:44:22 +0200 Ingo Molnar wrote:
 > 
 > > 
 > > * Martin Bligh <mbligh@google.com> wrote:
 > > 
 > > > panic on NUMA-Q during LTP. Was fine in -mm2.
 > > > 
 > > > BUG: unable to handle kernel paging request at virtual address 22222232
 > > 
 > > > EIP is at check_deadlock+0x19/0xe1
 > > > eax: 00000001   ebx: e4453030   ecx: 00000000   edx: e4008000
 > > > esi: 22222222   edi: 00000001   ebp: 22222222   esp: e47ebec0
 > > 
 > > again these 0x22222222 entries on the stack. What on earth does this? 
 > > Andy got a similar crash on x86_64, with a 0x2222222222222222 entry ...
 > > 
 > > nothing of our magic values are 0x22 or 0x222222222.
 > 
 > kernel/mutex-debug.c:
 > void debug_mutex_free_waiter(struct mutex_waiter *waiter)
 > {
 > 	DEBUG_WARN_ON(!list_empty(&waiter->list));
 > 	memset(waiter, 0x22, sizeof(*waiter));
 > }

Documentation/magic-number.txt sounds so promising, but we scatter definitions
of numbers all over the place. (No mention of the slab poison values,
or similar numbers there for eg, and various pointers to _other_ lists
of magic numbers).

		Dave

-- 
http://www.codemonkey.org.uk

Re: 2.6.17-rc5-mm3

[Ingo Molnar]

* Dave Jones <davej@redhat.com> wrote:

>  > kernel/mutex-debug.c:
>  > void debug_mutex_free_waiter(struct mutex_waiter *waiter)
>  > {
>  > 	DEBUG_WARN_ON(!list_empty(&waiter->list));
>  > 	memset(waiter, 0x22, sizeof(*waiter));
>  > }
> 
> Documentation/magic-number.txt sounds so promising, but we scatter 
> definitions of numbers all over the place. (No mention of the slab 
> poison values, or similar numbers there for eg, and various pointers 
> to _other_ lists of magic numbers).

we've also got include/linux/poison.h - i'll move this value there.

	Ingo

Re: 2.6.17-rc5-mm3

[Randy.Dunlap]

On Mon, 5 Jun 2006 16:05:54 -0400 Dave Jones wrote:

> On Mon, Jun 05, 2006 at 01:00:39PM -0700, Randy.Dunlap wrote:
>  > On Mon, 5 Jun 2006 21:44:22 +0200 Ingo Molnar wrote:
>  > 
>  > > 
>  > > * Martin Bligh <mbligh@google.com> wrote:
>  > > 
>  > > > panic on NUMA-Q during LTP. Was fine in -mm2.
>  > > > 
>  > > > BUG: unable to handle kernel paging request at virtual address 22222232
>  > > 
>  > > > EIP is at check_deadlock+0x19/0xe1
>  > > > eax: 00000001   ebx: e4453030   ecx: 00000000   edx: e4008000
>  > > > esi: 22222222   edi: 00000001   ebp: 22222222   esp: e47ebec0
>  > > 
>  > > again these 0x22222222 entries on the stack. What on earth does this? 
>  > > Andy got a similar crash on x86_64, with a 0x2222222222222222 entry ...
>  > > 
>  > > nothing of our magic values are 0x22 or 0x222222222.
>  > 
>  > kernel/mutex-debug.c:
>  > void debug_mutex_free_waiter(struct mutex_waiter *waiter)
>  > {
>  > 	DEBUG_WARN_ON(!list_empty(&waiter->list));
>  > 	memset(waiter, 0x22, sizeof(*waiter));
>  > }
> 
> Documentation/magic-number.txt sounds so promising, but we scatter definitions
> of numbers all over the place. (No mention of the slab poison values,
> or similar numbers there for eg, and various pointers to _other_ lists
> of magic numbers).

I have a few more that I can add to include/linux/poison.h, like this one
above (only in -mm at present).

./include/linux/libata.h:#define ATA_TAG_POISON		0xfafbfcfdU

./arch/ppc/8260_io/fcc_enet.c:1918:	memset((char *)(&(immap->im_dprambase[(mem_addr+64)])), 0x88, 32);
./drivers/usb/mon/mon_text.c:429:	memset(mem, 0xe5, sizeof(struct mon_event_text));

./kernel/mutex-debug.c:384:	memset(waiter, 0x11, sizeof(*waiter));
./kernel/mutex-debug.c:400:	memset(waiter, 0x22, sizeof(*waiter));

./security/keys/key.c:985:			memset(&key->payload, 0xbd, sizeof(key->payload));

./drivers/char/ftape/lowlevel/ftape-ctl.c:738:		memset(ft_buffer[i]->address, 0xAA, FT_BUFF_SIZE);

./drivers/block/sx8.c:/* 0xf is just arbitrary, non-zero noise; this is sorta like poisoning */


---
~Randy

[PATCH] poison: add & use more constants

[Randy.Dunlap]

From: Randy Dunlap <rdunlap@xenotime.net>

Add more poison values to include/linux/poison.h.
It's not clear to me whether some others should be added or not,
so I haven't added any of these:

./include/linux/libata.h:#define ATA_TAG_POISON		0xfafbfcfdU
./arch/ppc/8260_io/fcc_enet.c:1918:	memset((char *)(&(immap->im_dprambase[(mem_addr+64)])), 0x88, 32);
./drivers/usb/mon/mon_text.c:429:	memset(mem, 0xe5, sizeof(struct mon_event_text));
./drivers/char/ftape/lowlevel/ftape-ctl.c:738:		memset(ft_buffer[i]->address, 0xAA, FT_BUFF_SIZE);
./drivers/block/sx8.c:/* 0xf is just arbitrary, non-zero noise; this is sorta like poisoning */

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
 include/linux/poison.h |    7 +++++++
 kernel/mutex-debug.c   |    5 +++--
 security/keys/key.c    |    3 ++-
 3 files changed, 12 insertions(+), 3 deletions(-)

--- linux-2617-rc5mm3.orig/include/linux/poison.h
+++ linux-2617-rc5mm3/include/linux/poison.h
@@ -45,6 +45,13 @@
 /********** drivers/atm/ **********/
 #define ATM_POISON_FREE		0x12
 
+/********** kernel/mutexes **********/
+#define MUTEX_DEBUG_INIT	0x11
+#define MUTEX_DEBUG_FREE	0x22
+
+/********** security/ **********/
+#define KEY_DESTROY		0xbd
+
 /********** sound/oss/ **********/
 #define OSS_POISON_FREE		0xAB
 
--- linux-2617-rc5mm3.orig/kernel/mutex-debug.c
+++ linux-2617-rc5mm3/kernel/mutex-debug.c
@@ -16,6 +16,7 @@
 #include <linux/sched.h>
 #include <linux/delay.h>
 #include <linux/module.h>
+#include <linux/poison.h>
 #include <linux/spinlock.h>
 #include <linux/kallsyms.h>
 #include <linux/interrupt.h>
@@ -155,7 +156,7 @@ void debug_mutex_set_owner(struct mutex 
 
 void debug_mutex_lock_common(struct mutex *lock, struct mutex_waiter *waiter)
 {
-	memset(waiter, 0x11, sizeof(*waiter));
+	memset(waiter, MUTEX_DEBUG_INIT, sizeof(*waiter));
 	waiter->magic = waiter;
 	INIT_LIST_HEAD(&waiter->list);
 }
@@ -171,7 +172,7 @@ void debug_mutex_wake_waiter(struct mute
 void debug_mutex_free_waiter(struct mutex_waiter *waiter)
 {
 	DEBUG_WARN_ON(!list_empty(&waiter->list));
-	memset(waiter, 0x22, sizeof(*waiter));
+	memset(waiter, MUTEX_DEBUG_FREE, sizeof(*waiter));
 }
 
 void debug_mutex_add_waiter(struct mutex *lock, struct mutex_waiter *waiter,
--- linux-2617-rc5mm3.orig/security/keys/key.c
+++ linux-2617-rc5mm3/security/keys/key.c
@@ -11,6 +11,7 @@
 
 #include <linux/module.h>
 #include <linux/init.h>
+#include <linux/poison.h>
 #include <linux/sched.h>
 #include <linux/slab.h>
 #include <linux/security.h>
@@ -986,7 +987,7 @@ void unregister_key_type(struct key_type
 		if (key->type == ktype) {
 			if (ktype->destroy)
 				ktype->destroy(key);
-			memset(&key->payload, 0xbd, sizeof(key->payload));
+			memset(&key->payload, KEY_DESTROY, sizeof(key->payload));
 		}
 	}
 



---

Re: [PATCH] poison: add & use more constants

[Steven Rostedt]

On Mon, 2006-06-05 at 13:54 -0700, Randy.Dunlap wrote:
> From: Randy Dunlap <rdunlap@xenotime.net>
> 
> Add more poison values to include/linux/poison.h.
> It's not clear to me whether some others should be added or not,
> so I haven't added any of these:
> 
> ./include/linux/libata.h:#define ATA_TAG_POISON		0xfafbfcfdU
> ./arch/ppc/8260_io/fcc_enet.c:1918:	memset((char *)(&(immap->im_dprambase[(mem_addr+64)])), 0x88, 32);
> ./drivers/usb/mon/mon_text.c:429:	memset(mem, 0xe5, sizeof(struct mon_event_text));
> ./drivers/char/ftape/lowlevel/ftape-ctl.c:738:		memset(ft_buffer[i]->address, 0xAA, FT_BUFF_SIZE);
> ./drivers/block/sx8.c:/* 0xf is just arbitrary, non-zero noise; this is sorta like poisoning */

You don't have my personal favorite?  From AIX that would poison pages
with 0xdeadbeef  :)

-- Steve

[patch, -rc5-mm3] better lock debugging: remove mutex deadlock checking code

[Ingo Molnar]

* Randy.Dunlap <rdunlap@xenotime.net> wrote:

> BUG: unable to handle kernel paging request at virtual address 22222232

ok, this was a big thinko on my part, and it was right before our eyes. 
Mutex deadlock checking relied on the 'big mutex debugging lock', but 
that one is gone now - so mutex deadlock checking became racy (as your 
crashes nicely pinpointed that). The races are more likely with an 
increasing number of CPUs.

so the patch below finishes the cleanup i started: it removes deadlock 
checking from the mutex code and lets the lock validator do that. This 
should also be (much) faster on SMP, because the lock validator is 
lockless in the fastpath. (if CONFIG_DEBUG_LOCKDEP is disabled)

	Ingo

----------------
Subject: better lock debugging: remove mutex deadlock checking code
From: Ingo Molnar <mingo@elte.hu>

with the lock validator we detect mutex deadlocks (and more), the mutex
deadlock checking code is both redundant and slower. So remove it.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 kernel/mutex-debug.c |  126 ---------------------------------------------------
 lib/Kconfig.debug    |    8 ---
 2 files changed, 1 insertion(+), 133 deletions(-)

Index: linux/kernel/mutex-debug.c
===================================================================
--- linux.orig/kernel/mutex-debug.c
+++ linux/kernel/mutex-debug.c
@@ -23,128 +23,6 @@
 
 #include "mutex-debug.h"
 
-static void printk_task(struct task_struct *p)
-{
-	if (p)
-		printk("%16s:%5d [%p, %3d]", p->comm, p->pid, p, p->prio);
-	else
-		printk("<none>");
-}
-
-static void printk_ti(struct thread_info *ti)
-{
-	if (ti)
-		printk_task(ti->task);
-	else
-		printk("<none>");
-}
-
-static void printk_lock(struct mutex *lock, int print_owner)
-{
-#ifdef CONFIG_PROVE_MUTEX_LOCKING
-	printk(" [%p] {%s}\n", lock, lock->dep_map.name);
-#else
-	printk(" [%p]\n", lock);
-#endif
-
-	if (print_owner && lock->owner) {
-		printk(".. held by:  ");
-		printk_ti(lock->owner);
-		printk("\n");
-	}
-}
-
-static void report_deadlock(struct task_struct *task, struct mutex *lock,
-			    struct mutex *lockblk)
-{
-	printk("\n%s/%d is trying to acquire this lock:\n",
-		current->comm, current->pid);
-	printk_lock(lock, 1);
-	debug_show_held_locks(current);
-
-	if (lockblk) {
-		printk("but %s/%d is deadlocking current task %s/%d!\n\n",
-			task->comm, task->pid, current->comm, current->pid);
-		printk("\n%s/%d is blocked on this lock:\n",
-			task->comm, task->pid);
-		printk_lock(lockblk, 1);
-
-		debug_show_held_locks(task);
-
-		printk("\n%s/%d's [blocked] stackdump:\n\n",
-			task->comm, task->pid);
-		show_stack(task, NULL);
-	}
-
-	printk("\n%s/%d's [current] stackdump:\n\n",
-		current->comm, current->pid);
-	dump_stack();
-	debug_show_all_locks();
-	printk("[ turning off deadlock detection. Please report this. ]\n\n");
-	local_irq_disable();
-}
-
-/*
- * Recursively check for mutex deadlocks:
- */
-static int check_deadlock(struct mutex *lock, int depth, struct thread_info *ti)
-{
-	struct mutex *lockblk;
-	struct task_struct *task;
-
-	if (!debug_locks)
-		return 0;
-
-	ti = lock->owner;
-	if (!ti)
-		return 0;
-
-	task = ti->task;
-	/*
-	 * In the PROVE_MUTEX_LOCKING we are tracking all held
-	 * locks already, which allows us to optimize this:
-	 */
-#ifdef CONFIG_PROVE_MUTEX_LOCKING
-	if (!task->lockdep_depth)
-		return 0;
-#endif
-	lockblk = NULL;
-	if (task->blocked_on)
-		lockblk = task->blocked_on->lock;
-
-	/* Self-deadlock: */
-	if (current == task) {
-		debug_locks_off();
-		if (depth)
-			return 1;
-		printk("\n==========================================\n");
-		printk(  "[ BUG: lock recursion deadlock detected! |\n");
-		printk(  "------------------------------------------\n");
-		report_deadlock(task, lock, NULL);
-		return 0;
-	}
-
-	/* Ugh, something corrupted the lock data structure? */
-	if (depth > 20) {
-		debug_locks_off();
-		printk("\n===========================================\n");
-		printk(  "[ BUG: infinite lock dependency detected!? |\n");
-		printk(  "-------------------------------------------\n");
-		report_deadlock(task, lock, lockblk);
-		return 0;
-	}
-
-	/* Recursively check for dependencies: */
-	if (lockblk && check_deadlock(lockblk, depth+1, ti)) {
-		printk("\n============================================\n");
-		printk(  "[ BUG: circular locking deadlock detected! ]\n");
-		printk(  "--------------------------------------------\n");
-		report_deadlock(task, lock, lockblk);
-		return 0;
-	}
-	return 0;
-}
-
 /*
  * Must be called with lock->wait_lock held.
  */
@@ -178,9 +56,7 @@ void debug_mutex_add_waiter(struct mutex
 			    struct thread_info *ti)
 {
 	SMP_DEBUG_WARN_ON(!spin_is_locked(&lock->wait_lock));
-#ifdef CONFIG_DEBUG_MUTEX_DEADLOCKS
-	check_deadlock(lock, 0, ti);
-#endif
+
 	/* Mark the current thread as blocked on the lock: */
 	ti->task->blocked_on = waiter;
 	waiter->lock = lock;
Index: linux/lib/Kconfig.debug
===================================================================
--- linux.orig/lib/Kconfig.debug
+++ linux/lib/Kconfig.debug
@@ -164,14 +164,6 @@ config DEBUG_MUTEX_ALLOC
 	 (kfree(), kmem_cache_free(), free_pages(), vfree(), etc.),
 	 or whether there is any lock held during task exit.
 
-config DEBUG_MUTEX_DEADLOCKS
-	bool "Detect mutex related deadlocks"
-	default y
-	depends on DEBUG_MUTEXES
-	help
-	 This feature will automatically detect and report mutex related
-	 deadlocks, as they happen.
-
 config DEBUG_RT_MUTEXES
 	bool "RT Mutex debugging, deadlock detection"
 	default y

Re: [patch, -rc5-mm3] better lock debugging: remove mutex deadlock checking code

[Andy Whitcroft]

Ingo Molnar wrote:
> * Randy.Dunlap <rdunlap@xenotime.net> wrote:
> 
> 
>>BUG: unable to handle kernel paging request at virtual address 22222232
> 
> 
> ok, this was a big thinko on my part, and it was right before our eyes. 
> Mutex deadlock checking relied on the 'big mutex debugging lock', but 
> that one is gone now - so mutex deadlock checking became racy (as your 
> crashes nicely pinpointed that). The races are more likely with an 
> increasing number of CPUs.
> 
> so the patch below finishes the cleanup i started: it removes deadlock 
> checking from the mutex code and lets the lock validator do that. This 
> should also be (much) faster on SMP, because the lock validator is 
> lockless in the fastpath. (if CONFIG_DEBUG_LOCKDEP is disabled)
> 
> 	Ingo
> 
> ----------------
> Subject: better lock debugging: remove mutex deadlock checking code
> From: Ingo Molnar <mingo@elte.hu>
> 
> with the lock validator we detect mutex deadlocks (and more), the mutex
> deadlock checking code is both redundant and slower. So remove it.
> 
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
>  kernel/mutex-debug.c |  126 ---------------------------------------------------
>  lib/Kconfig.debug    |    8 ---
>  2 files changed, 1 insertion(+), 133 deletions(-)
> 
> Index: linux/kernel/mutex-debug.c
> ===================================================================
> --- linux.orig/kernel/mutex-debug.c
> +++ linux/kernel/mutex-debug.c
> @@ -23,128 +23,6 @@
>  
>  #include "mutex-debug.h"
>  
> -static void printk_task(struct task_struct *p)
> -{
> -	if (p)
> -		printk("%16s:%5d [%p, %3d]", p->comm, p->pid, p, p->prio);
> -	else
> -		printk("<none>");
> -}
> -
> -static void printk_ti(struct thread_info *ti)
> -{
> -	if (ti)
> -		printk_task(ti->task);
> -	else
> -		printk("<none>");
> -}
> -
> -static void printk_lock(struct mutex *lock, int print_owner)
> -{
> -#ifdef CONFIG_PROVE_MUTEX_LOCKING
> -	printk(" [%p] {%s}\n", lock, lock->dep_map.name);
> -#else
> -	printk(" [%p]\n", lock);
> -#endif
> -
> -	if (print_owner && lock->owner) {
> -		printk(".. held by:  ");
> -		printk_ti(lock->owner);
> -		printk("\n");
> -	}
> -}
> -
> -static void report_deadlock(struct task_struct *task, struct mutex *lock,
> -			    struct mutex *lockblk)
> -{
> -	printk("\n%s/%d is trying to acquire this lock:\n",
> -		current->comm, current->pid);
> -	printk_lock(lock, 1);
> -	debug_show_held_locks(current);
> -
> -	if (lockblk) {
> -		printk("but %s/%d is deadlocking current task %s/%d!\n\n",
> -			task->comm, task->pid, current->comm, current->pid);
> -		printk("\n%s/%d is blocked on this lock:\n",
> -			task->comm, task->pid);
> -		printk_lock(lockblk, 1);
> -
> -		debug_show_held_locks(task);
> -
> -		printk("\n%s/%d's [blocked] stackdump:\n\n",
> -			task->comm, task->pid);
> -		show_stack(task, NULL);
> -	}
> -
> -	printk("\n%s/%d's [current] stackdump:\n\n",
> -		current->comm, current->pid);
> -	dump_stack();
> -	debug_show_all_locks();
> -	printk("[ turning off deadlock detection. Please report this. ]\n\n");
> -	local_irq_disable();
> -}
> -
> -/*
> - * Recursively check for mutex deadlocks:
> - */
> -static int check_deadlock(struct mutex *lock, int depth, struct thread_info *ti)
> -{
> -	struct mutex *lockblk;
> -	struct task_struct *task;
> -
> -	if (!debug_locks)
> -		return 0;
> -
> -	ti = lock->owner;
> -	if (!ti)
> -		return 0;
> -
> -	task = ti->task;
> -	/*
> -	 * In the PROVE_MUTEX_LOCKING we are tracking all held
> -	 * locks already, which allows us to optimize this:
> -	 */
> -#ifdef CONFIG_PROVE_MUTEX_LOCKING
> -	if (!task->lockdep_depth)
> -		return 0;
> -#endif
> -	lockblk = NULL;
> -	if (task->blocked_on)
> -		lockblk = task->blocked_on->lock;
> -
> -	/* Self-deadlock: */
> -	if (current == task) {
> -		debug_locks_off();
> -		if (depth)
> -			return 1;
> -		printk("\n==========================================\n");
> -		printk(  "[ BUG: lock recursion deadlock detected! |\n");
> -		printk(  "------------------------------------------\n");
> -		report_deadlock(task, lock, NULL);
> -		return 0;
> -	}
> -
> -	/* Ugh, something corrupted the lock data structure? */
> -	if (depth > 20) {
> -		debug_locks_off();
> -		printk("\n===========================================\n");
> -		printk(  "[ BUG: infinite lock dependency detected!? |\n");
> -		printk(  "-------------------------------------------\n");
> -		report_deadlock(task, lock, lockblk);
> -		return 0;
> -	}
> -
> -	/* Recursively check for dependencies: */
> -	if (lockblk && check_deadlock(lockblk, depth+1, ti)) {
> -		printk("\n============================================\n");
> -		printk(  "[ BUG: circular locking deadlock detected! ]\n");
> -		printk(  "--------------------------------------------\n");
> -		report_deadlock(task, lock, lockblk);
> -		return 0;
> -	}
> -	return 0;
> -}
> -
>  /*
>   * Must be called with lock->wait_lock held.
>   */
> @@ -178,9 +56,7 @@ void debug_mutex_add_waiter(struct mutex
>  			    struct thread_info *ti)
>  {
>  	SMP_DEBUG_WARN_ON(!spin_is_locked(&lock->wait_lock));
> -#ifdef CONFIG_DEBUG_MUTEX_DEADLOCKS
> -	check_deadlock(lock, 0, ti);
> -#endif
> +
>  	/* Mark the current thread as blocked on the lock: */
>  	ti->task->blocked_on = waiter;
>  	waiter->lock = lock;
> Index: linux/lib/Kconfig.debug
> ===================================================================
> --- linux.orig/lib/Kconfig.debug
> +++ linux/lib/Kconfig.debug
> @@ -164,14 +164,6 @@ config DEBUG_MUTEX_ALLOC
>  	 (kfree(), kmem_cache_free(), free_pages(), vfree(), etc.),
>  	 or whether there is any lock held during task exit.
>  
> -config DEBUG_MUTEX_DEADLOCKS
> -	bool "Detect mutex related deadlocks"
> -	default y
> -	depends on DEBUG_MUTEXES
> -	help
> -	 This feature will automatically detect and report mutex related
> -	 deadlocks, as they happen.
> -
>  config DEBUG_RT_MUTEXES
>  	bool "RT Mutex debugging, deadlock detection"
>  	default y

I'll shove this one in for testing too.  Results on TKO as I have them.

-apw

Re: [patch, -rc5-mm3] better lock debugging: remove mutex deadlock checking code

[Andy Whitcroft]

Andy Whitcroft wrote:
> Ingo Molnar wrote:
> 
>>* Randy.Dunlap <rdunlap@xenotime.net> wrote:
>>
>>
>>
>>>BUG: unable to handle kernel paging request at virtual address 22222232
>>
>>
>>ok, this was a big thinko on my part, and it was right before our eyes. 
>>Mutex deadlock checking relied on the 'big mutex debugging lock', but 
>>that one is gone now - so mutex deadlock checking became racy (as your 
>>crashes nicely pinpointed that). The races are more likely with an 
>>increasing number of CPUs.
>>
>>so the patch below finishes the cleanup i started: it removes deadlock 
>>checking from the mutex code and lets the lock validator do that. This 
>>should also be (much) faster on SMP, because the lock validator is 
>>lockless in the fastpath. (if CONFIG_DEBUG_LOCKDEP is disabled)
>>
>>	Ingo
>>
>>----------------
>>Subject: better lock debugging: remove mutex deadlock checking code
>>From: Ingo Molnar <mingo@elte.hu>
>>
>>with the lock validator we detect mutex deadlocks (and more), the mutex
>>deadlock checking code is both redundant and slower. So remove it.
>>
>>Signed-off-by: Ingo Molnar <mingo@elte.hu>
>>---
>> kernel/mutex-debug.c |  126 ---------------------------------------------------
>> lib/Kconfig.debug    |    8 ---
>> 2 files changed, 1 insertion(+), 133 deletions(-)
>>
>>Index: linux/kernel/mutex-debug.c
>>===================================================================
>>--- linux.orig/kernel/mutex-debug.c
>>+++ linux/kernel/mutex-debug.c
>>@@ -23,128 +23,6 @@
>> 
>> #include "mutex-debug.h"
>> 
>>-static void printk_task(struct task_struct *p)
>>-{
>>-	if (p)
>>-		printk("%16s:%5d [%p, %3d]", p->comm, p->pid, p, p->prio);
>>-	else
>>-		printk("<none>");
>>-}
>>-
>>-static void printk_ti(struct thread_info *ti)
>>-{
>>-	if (ti)
>>-		printk_task(ti->task);
>>-	else
>>-		printk("<none>");
>>-}
>>-
>>-static void printk_lock(struct mutex *lock, int print_owner)
>>-{
>>-#ifdef CONFIG_PROVE_MUTEX_LOCKING
>>-	printk(" [%p] {%s}\n", lock, lock->dep_map.name);
>>-#else
>>-	printk(" [%p]\n", lock);
>>-#endif
>>-
>>-	if (print_owner && lock->owner) {
>>-		printk(".. held by:  ");
>>-		printk_ti(lock->owner);
>>-		printk("\n");
>>-	}
>>-}
>>-
>>-static void report_deadlock(struct task_struct *task, struct mutex *lock,
>>-			    struct mutex *lockblk)
>>-{
>>-	printk("\n%s/%d is trying to acquire this lock:\n",
>>-		current->comm, current->pid);
>>-	printk_lock(lock, 1);
>>-	debug_show_held_locks(current);
>>-
>>-	if (lockblk) {
>>-		printk("but %s/%d is deadlocking current task %s/%d!\n\n",
>>-			task->comm, task->pid, current->comm, current->pid);
>>-		printk("\n%s/%d is blocked on this lock:\n",
>>-			task->comm, task->pid);
>>-		printk_lock(lockblk, 1);
>>-
>>-		debug_show_held_locks(task);
>>-
>>-		printk("\n%s/%d's [blocked] stackdump:\n\n",
>>-			task->comm, task->pid);
>>-		show_stack(task, NULL);
>>-	}
>>-
>>-	printk("\n%s/%d's [current] stackdump:\n\n",
>>-		current->comm, current->pid);
>>-	dump_stack();
>>-	debug_show_all_locks();
>>-	printk("[ turning off deadlock detection. Please report this. ]\n\n");
>>-	local_irq_disable();
>>-}
>>-
>>-/*
>>- * Recursively check for mutex deadlocks:
>>- */
>>-static int check_deadlock(struct mutex *lock, int depth, struct thread_info *ti)
>>-{
>>-	struct mutex *lockblk;
>>-	struct task_struct *task;
>>-
>>-	if (!debug_locks)
>>-		return 0;
>>-
>>-	ti = lock->owner;
>>-	if (!ti)
>>-		return 0;
>>-
>>-	task = ti->task;
>>-	/*
>>-	 * In the PROVE_MUTEX_LOCKING we are tracking all held
>>-	 * locks already, which allows us to optimize this:
>>-	 */
>>-#ifdef CONFIG_PROVE_MUTEX_LOCKING
>>-	if (!task->lockdep_depth)
>>-		return 0;
>>-#endif
>>-	lockblk = NULL;
>>-	if (task->blocked_on)
>>-		lockblk = task->blocked_on->lock;
>>-
>>-	/* Self-deadlock: */
>>-	if (current == task) {
>>-		debug_locks_off();
>>-		if (depth)
>>-			return 1;
>>-		printk("\n==========================================\n");
>>-		printk(  "[ BUG: lock recursion deadlock detected! |\n");
>>-		printk(  "------------------------------------------\n");
>>-		report_deadlock(task, lock, NULL);
>>-		return 0;
>>-	}
>>-
>>-	/* Ugh, something corrupted the lock data structure? */
>>-	if (depth > 20) {
>>-		debug_locks_off();
>>-		printk("\n===========================================\n");
>>-		printk(  "[ BUG: infinite lock dependency detected!? |\n");
>>-		printk(  "-------------------------------------------\n");
>>-		report_deadlock(task, lock, lockblk);
>>-		return 0;
>>-	}
>>-
>>-	/* Recursively check for dependencies: */
>>-	if (lockblk && check_deadlock(lockblk, depth+1, ti)) {
>>-		printk("\n============================================\n");
>>-		printk(  "[ BUG: circular locking deadlock detected! ]\n");
>>-		printk(  "--------------------------------------------\n");
>>-		report_deadlock(task, lock, lockblk);
>>-		return 0;
>>-	}
>>-	return 0;
>>-}
>>-
>> /*
>>  * Must be called with lock->wait_lock held.
>>  */
>>@@ -178,9 +56,7 @@ void debug_mutex_add_waiter(struct mutex
>> 			    struct thread_info *ti)
>> {
>> 	SMP_DEBUG_WARN_ON(!spin_is_locked(&lock->wait_lock));
>>-#ifdef CONFIG_DEBUG_MUTEX_DEADLOCKS
>>-	check_deadlock(lock, 0, ti);
>>-#endif
>>+
>> 	/* Mark the current thread as blocked on the lock: */
>> 	ti->task->blocked_on = waiter;
>> 	waiter->lock = lock;
>>Index: linux/lib/Kconfig.debug
>>===================================================================
>>--- linux.orig/lib/Kconfig.debug
>>+++ linux/lib/Kconfig.debug
>>@@ -164,14 +164,6 @@ config DEBUG_MUTEX_ALLOC
>> 	 (kfree(), kmem_cache_free(), free_pages(), vfree(), etc.),
>> 	 or whether there is any lock held during task exit.
>> 
>>-config DEBUG_MUTEX_DEADLOCKS
>>-	bool "Detect mutex related deadlocks"
>>-	default y
>>-	depends on DEBUG_MUTEXES
>>-	help
>>-	 This feature will automatically detect and report mutex related
>>-	 deadlocks, as they happen.
>>-
>> config DEBUG_RT_MUTEXES
>> 	bool "RT Mutex debugging, deadlock detection"
>> 	default y
> 
> 
> I'll shove this one in for testing too.  Results on TKO as I have them.
> 
> -apw
> 

This is definatly clearing up a bunch of problems with the current -mm.

-apw

Re: [patch, -rc5-mm3] better lock debugging: remove mutex deadlock checking code

[Ingo Molnar]

* Andy Whitcroft <apw@shadowen.org> wrote:

> > I'll shove this one in for testing too.  Results on TKO as I have them.
> 
> This is definatly clearing up a bunch of problems with the current 
> -mm.

great! Thanks for testing this out, this bug was the scariest pending 
one.

	Ingo

Re: [patch, -rc5-mm3] better lock debugging: remove mutex deadlock checking code

[Andy Whitcroft]

Ingo Molnar wrote:
> * Randy.Dunlap <rdunlap@xenotime.net> wrote:
> 
> 
>>BUG: unable to handle kernel paging request at virtual address 22222232
> 
> 
> ok, this was a big thinko on my part, and it was right before our eyes. 
> Mutex deadlock checking relied on the 'big mutex debugging lock', but 
> that one is gone now - so mutex deadlock checking became racy (as your 
> crashes nicely pinpointed that). The races are more likely with an 
> increasing number of CPUs.
> 
> so the patch below finishes the cleanup i started: it removes deadlock 
> checking from the mutex code and lets the lock validator do that. This 
> should also be (much) faster on SMP, because the lock validator is 
> lockless in the fastpath. (if CONFIG_DEBUG_LOCKDEP is disabled)
> 
> 	Ingo
> 
> ----------------
> Subject: better lock debugging: remove mutex deadlock checking code
> From: Ingo Molnar <mingo@elte.hu>
> 
> with the lock validator we detect mutex deadlocks (and more), the mutex
> deadlock checking code is both redundant and slower. So remove it.
> 
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---

Ok, this patch in combination with either fix for the swap max bug are
showing passes across the board.

Acked-by: Andy Whitcroft <apw@shadowen.org>

-apw

2.6.17-rc5-mm3

[Andrew Morton]

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm3/

- Lots of PCI and USB updates

- The various lock validator, stack backtracing and IRQ management problems
  are converging, but we're not quite there yet.



Boilerplate:

- See the `hot-fixes' directory for any important updates to this patchset.

- 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 v2.6.16-rc2-mm1

- -mm kernel commit activity can be reviewed by subscribing to the
  mm-commits mailing list.

        echo "subscribe mm-commits" | mail majordomo@vger.kernel.org

- If you hit a bug in -mm and it is not obvious which patch caused it, it is
  most valuable if you can perform a bisection search to identify which patch
  introduced the bug.  Instructions for this process are at

        http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt

  But beware that this process takes some time (around ten rebuilds and
  reboots), so consider reporting the bug first and if we cannot immediately
  identify the faulty patch, then perform the bisection search.

- When reporting bugs, please try to Cc: the relevant maintainer and mailing
  list on any email.




Changes since 2.6.17-rc5-mm2:


 origin.patch
 git-acpi.patch
 git-agpgart.patch
 git-alsa.patch
 git-audit-master.patch
 git-block.patch
 git-cifs.patch
 git-cpufreq.patch
 git-cpufreq-fixup.patch
 git-dvb.patch
 git-gfs2.patch
 git-ia64.patch
 git-infiniband.patch
 git-intelfb.patch
 git-klibc.patch
 git-hdrcleanup.patch
 git-hdrinstall.patch
 git-libata-all.patch
 git-mips.patch
 git-mtd.patch
 git-netdev-all.patch
 git-net.patch
 git-nfs.patch
 git-powerpc.patch
 git-rbtree.patch
 git-sas.patch
 git-pcmcia.patch
 git-scsi-target.patch
 git-supertrak.patch
 git-watchdog.patch
 git-cryptodev.patch

 git trees

-drivers-usb-core-devioc-dereference-userspace-pointer.patch
-nbd-endian-annotations.patch
-cifs-build-fix.patch
-git-cifs-kconfig-fix.patch
-cifs-do-not-overwrite-aops-elements.patch
-scx200_acb-use-pci-i-o-resource-when-appropriate-fix.patch
-git-mtd-cs553x_nand-build-fix.patch
-pmf_register_irq_client-gives-sleep-with-locks-held-warning.patch
-64-bit-resources-arch-powerpc-changes-update.patch
-fix-pciehp-compile-issue-when-config_acpi-is-not.patch
-gregkh-pci-pci-64-bit-resources-drivers-others-changes-amba-fix.patch
-i386-export-memory-more-than-4g-through-proc-iomem.patch
-pci-pci-64-bit-resources-arch-changes-update.patch
-improve-pci-config-space-writeback.patch
-reverse-pci-config-space-restore-order.patch
-pci-add-pci_assign_resource_fixed-allow-fixed-address.patch
-add-a-enable-sysfs-attribute-to-the-pci-devices-to-allow.patch
-fix-recovery-path-from-errors-during-pcie_init.patch
-move-various-pci-ids-to-header-file.patch
-kconfigurable-resources-core-changes.patch
-kconfigurable-resources-core-changes-i386-fix.patch
-kconfigurable-resources-core-changes-fix.patch
-kconfigurable-resources-driver-pci-changes.patch
-kconfigurable-resources-driver-others-changes.patch
-kconfigurable-resources-arch-dependent-changes-arch-a-i.patch
-kconfigurable-resources-arch-dependent-changes-arch-a-i-fix.patch
-kconfigurable-resources-arch-dependent-changes-arch-j-p.patch
-kconfigurable-resources-arch-dependent-changes-arch-q-z.patch
-typesh-sector_t-and-blkcnt_t-arent-for-userspace.patch
-allow-msi-to-work-on-kexec-kernel.patch
-pci-disable-msi-mode-in-pci_disable_device.patch
-pci-dont-move-ioapics-below-pci-bridge.patch
-git-scsi-rc-fixes.patch
-scsi-properly-count-the-number-of-pages-in-scsi_req_map_sg-fix.patch
-revert-gregkh-usb-usb-ohci-avoids-root-hub-timer-polling.patch
-gregkh-usb-usb-serial-mos7720-powerpc-wrokaround.patch
-usb-add-sierra-wireless-mc5720-id-to-airprimec.patch
-usb-negative-index-in-drivers-usb-host-isp116x-hcdc.patch
-xfs-sparc32-build-fix.patch
-add-pci_cap_id_vndr.patch

 Merged into mainline or a subsystem tree

+alpha-smp-irq-routing-fix.patch
+fs-nameic-call-to-file_permission-under-a-spinlock-in-do_lookup_path.patch
+fs-nameic-call-to-file_permission-under-a-spinlock-in-do_lookup_path-fix.patch
+pmf_register_irq_client-gives-sleep-with-locks-held-warning.patch
+implement-get--set-tso-for-forcedeth-driver.patch
+fix-hpet-operation-on-32-bit-nvidia-platforms.patch
+fix-hpet-operation-on-32-bit-nvidia-platforms-build-fix.patch
+fix-hpet-operation-on-64-bit-nvidia-platforms.patch
+maintainers-add-entries-for-bnx2-and-tg3.patch
+sbp2-fix-check-of-return-value-of.patch
+sata_sil24-sii3124-sata-driver-endian-problem.patch
+m48t86-ia64-build-fix.patch
+m68k-get_user-build-fix.patch
+uml-add-asm-irqflagsh.patch
+uml-fix-wall_to_monotonic-initialization.patch
+uml-fix-a-typo-in-do_uml_initcalls.patch
+uml-__user-annotation-in-arch_prctl.patch
+uml-more-__user-annotations.patch
+uml-add-ffreestanding-to-cflags.patch

 2.6.17 queue

+kevent-add-new-uevent.patch

 Required for acpi-dock-driver.patch

-acpi-dock-driver-v3.patch
-acpi-dock-driver-v4.patch
-acpi-dock-driver-interface-fixups.patch

 Folded into acpi-dock-driver.patch

-acpiphp-use-new-dock-driver-fix.patch
-acpiphp-use-new-dock-driver-v2.patch

 Folded into acpiphp-use-new-dock-driver.patch

-acpi-atlas-acpi-driver-v2-tidy.patch

 Folded into acpi-atlas-acpi-driver.patch

+acpi-atlas-acpi-driver-fix.patch

 Fix acpi-atlas-acpi-driver.patch

+ieee1394-video1394-be-quiet.patch
+ieee1394-ohci1394c-function-calls-without.patch
+ieee1394-sbp2-make-tsb42aa9-workaround-specific.patch
+ieee1394-semaphore-to-mutex-conversion.patch
+ieee1394-raw1394-fix-whitespace-after-x86_64.patch
+ieee1394-ieee1394-ohci1394-cycletoolong.patch
+ieee1394-ieee1394-support-for-slow-links-or-slow.patch
+ieee1394-ieee1394-save-ram-by-using-a-single.patch
+ieee1394-sbp2-remove-manipulation-of-inquiry.patch
+ieee1394-sbp2-log-number-of-supported-concurrent.patch
+ieee1394-ieee1394-extend-lowlevel-api-for.patch
+ieee1394-ohci1394-set-address-range-properties.patch
+ieee1394-ohci1394-make-phys_dma-parameter.patch
+ieee1394-sbp2-sbp2-remove-ohci1394-specific.patch
+ieee1394-sbp2-fix-s800-transfers-if-phys_dma-is.patch
+ieee1394-update-feature-removal-of-obsolete.patch
+ieee1394-sbp2-provide-helptext-for.patch
+ieee1394-sbp2-kconfig-fix.patch
+ieee1394-sbp2-use-__attribute__packed-for.patch
+ieee1394-sbp2-fix-deregistration-of-status-fifo-address-space.patch
+ieee1394-add-preprocessor-constant-for-invalid-csr.patch
+eth1394-endian-fixes.patch

 ieee1394 updates

-ieee1394_core-switch-to-kthread-api-fix.patch

 Folded into ieee1394_core-switch-to-kthread-api.patch

-input-fix-oops-on-mk712-load.patch

 Dropped

-via-pmu-add-input-device-tidy.patch

 Folded into via-pmu-add-input-device.patch

-input-powermac-cleanup-of-mac_hid-and-support-for-ctrlclick-and-commandclick-update.patch

 Folded into input-powermac-cleanup-of-mac_hid-and-support-for-ctrlclick-and-commandclick.patch

-input-logitech-trackman-trackball-support.patch

 Dropped (I think)

-input-new-force-feedback-interface-fix.patch

 Folded into input-new-force-feedback-interface.patch

+kconfig-integrate-split-config-into-silentoldconfig-fix.patch

 Folded into kconfig-integrate-split-config-into-silentoldconfig.patch

+kbuild-obj-dirs-is-calculated-incorrectly-if-hostprogs-y-is-defined.patch
+fix-make-rpm-for-powerpc.patch

 kbuild fixes

+revert-sata_sil24-sii3124-sata-driver-endian-problem.patch

 Revert earlier patch so that git-libata-all applies OK.

+libata-add-missing-data_xfer-for-pata_pdc2027x-and-pdc_adma-fix.patch

 Fix libata-add-missing-data_xfer-for-pata_pdc2027x-and-pdc_adma.patch

+prevent-au1xmmcc-breakage-on-non-au1200-alchemy.patch

 mmc driver fix

+myri10ge-alpha-build-fix.patch

 Fix git-netdev-all.patch

+forcedeth-config-ring-sizes.patch
+forcedeth-config-flow-control.patch
+forcedeth-config-phy.patch
+forcedeth-config-wol.patch
+forcedeth-config-csum.patch
+forcedeth-config-statistics.patch
+forcedeth-config-diagnostics.patch
+forcedeth-config-module-parameters.patch
+forcedeth-config-version.patch
+forcedeth-new-device-ids.patch
+forcedeth-typecast-cleanup.patch

 forcedeth updates

+lock-validator-netlinkc-netlink_table_grab-fix.patch

 netlink locking fix

+recent-match-fix-sleeping-function-called-from-invalid-context.patch
+recent-match-missing-refcnt-initialization.patch

 netfilter fixes

-fix-for-serial-uart-lockup.patch

 Dropped.

+gregkh-pci-pci-add-pci_cap_id_vndr.patch
+gregkh-pci-pci-fix-pciehp-compile-issue-when-config_acpi-is-not-enabled.patch
+gregkh-pci-pci-64-bit-resource-fixup-pci-resource-dbg-code-to-handle-size-change.patch
+gregkh-pci-pci-64-bit-resource-fix-amba-build-warning.patch
+gregkh-pci-pci-64-bit-resources-fix-pnp-sysfs-interface.patch
+gregkh-pci-pci-64-bit-resources-arch-powerpc-changes-update.patch
+gregkh-pci-kconfigurable-resources-core-changes.patch
+gregkh-pci-kconfigurable-resources-driver-pci-changes.patch
+gregkh-pci-kconfigurable-resources-driver-others-changes.patch
+gregkh-pci-kconfigurable-resources-arch-dependent-changes.patch
+gregkh-pci-kconfigurable-resources-arch-dependent-changes-arch.patch
+gregkh-pci-kconfigurable-resources-arch-dependent-changes-arch-q-z.patch
+gregkh-pci-i386-export-memory-more-than-4g-through-proc-iomem.patch
+gregkh-pci-pci-error-handling-on-pci-device-resume.patch
+gregkh-pci-pci-ignore-pre-set-64-bit-bars-on-32-bit-platforms.patch
+gregkh-pci-pciehp-dont-call-pci_enable_dev.patch
+gregkh-pci-pci-improve-pci-config-space-writeback.patch
+gregkh-pci-pci-reverse-pci-config-space-restore-order.patch
+gregkh-pci-pci-add-pci_assign_resource_fixed-allow-fixed-address-assignments.patch
+gregkh-pci-pci-add-a-enable-sysfs-attribute-to-the-pci-devices-to-allow-userspace-to-enable-devices-without-doing-foul-direct-access.patch
+gregkh-pci-pci-don-t-enable-device-if-already-enabled.patch
+gregkh-pci-pci-acpi-rename-the-functions-to-avoid-multiple-instances.patch
+gregkh-pci-acpi_pcihp-fix-programming-_hpp-values.patch
+gregkh-pci-acpi_pcihp-remove-improper-error-message-about-oshp.patch
+gregkh-pci-acpi_pcihp-add-support-for-_hpx.patch
+gregkh-pci-pciehp-fix-programming-hotplug-parameters.patch
+gregkh-pci-shpc-cleanup-shpc-register-access.patch
+gregkh-pci-shpc-cleanup-shpc-logical-slot-register-access.patch
+gregkh-pci-shpc-cleanup-shpc-logical-slot-register-bits-access.patch
+gregkh-pci-shpc-fix-shpc-logical-slot-register-bits-access.patch
+gregkh-pci-shpc-fix-shpc-contoller-serr-int-register-bits-access.patch
+gregkh-pci-shpchp-mask-global-serr-and-intr-at-controller-release-time.patch
+gregkh-pci-shpchp-create-shpchpd-at-controller-probe-time.patch
+gregkh-pci-pci-i386-x86_84-disable-pci-resource-decode-on-device-disable.patch
+gregkh-pci-sgi-hotplug-incorrect-power-status.patch
+gregkh-pci-pci-bus-parity-status-broken-hardware-attribute-edac-foundation.patch
+gregkh-pci-pci-hotplug-fix-recovery-path-from-errors-during-pcie_init.patch
+gregkh-pci-pciehp-replace-pci_find_slot-with-pci_get_slot.patch
+gregkh-pci-pciehp-add-missing-pci_dev_put.patch
+gregkh-pci-pciehp-implement-get_address-callback.patch
+gregkh-pci-shpchp-remove-unnecessary-hpc_ctlr_handle-check.patch
+gregkh-pci-shpchp-cleanup-interrupt-handler.patch
+gregkh-pci-shpchp-cleanup-shpc-commands.patch
+gregkh-pci-shpchp-cleanup-interrupt-polling-timer.patch
+gregkh-pci-shpchp-remove-unused-hpc_evelnt_lock.patch
+gregkh-pci-shpchp-cleanup-improper-info-messages.patch
+gregkh-pci-pci-move-various-pci-ids-to-header-file.patch
+gregkh-pci-pci-amd-8131-msi-quirk-called-too-late-bus_flags-not-inherited.patch
+gregkh-pci-pci-allow-msi-to-work-on-kexec-kernel.patch
+gregkh-pci-pci-disable-msi-mode-in-pci_disable_device.patch
+gregkh-pci-pci-hotplug-fake-null-pointer-dereferences-in-ibm-hot-plug-controller-driver.patch
+gregkh-pci-pci-cleanup-unused-variable-about-msi-driver.patch
+gregkh-pci-pci-don-t-move-ioapics-below-pci-bridge.patch
+gregkh-pci-pci-remove-unneeded-msi-code.patch
+gregkh-pci-pci-clean-up-pci-documentation-to-be-more-specific.patch
+gregkh-pci-pci-fix-race-with-pci_walk_bus-and-pci_destroy_dev.patch
+gregkh-pci-pci-test-that-drivers-properly-call-pci_set_master.patch

 PCI tree updates

+revert-gregkh-pci-pci-test-that-drivers-properly-call-pci_set_master.patch
+gregkh-pci-kconfigurable-resources-arch-dependent-changes-arm-fix.patch
+gregkh-pci-pci-64-bit-resources-core-changes-mips-fix.patch

 Unbreak it.

-bogus-disk-geometry-on-large-disks-warning-fix.patch

 Folded into bogus-disk-geometry-on-large-disks.patch

-areca-raid-linux-scsi-driver-update6-for-2617-rc1-mm3.patch
-areca-raid-linux-scsi-driver-update6-for-2617-rc1-mm3-externs-go-in-headers.patch

 Folded into areca-raid-linux-scsi-driver.patch

+git-scsi-target-fixup.patch

 Fix reject in git-scsi-target.patch.

+gregkh-usb-usb-whiteheat-fix-firmware-spurious-errors.patch
+gregkh-usb-usb-add-sierra-wireless-mc5720-id-to-airprime.c.patch
+gregkh-usb-usb-negative-index-in-drivers-usb-host-isp116x-hcd.c.patch
+gregkh-usb-usb-cdc_ether-recognize-olympus-r1000.patch
+gregkh-usb-usbcore-port-reset-for-composite-devices.patch
+gregkh-usb-usb-hub-use-usb_reset_composite_device.patch
+gregkh-usb-usb-storage-use-usb_reset_composite_device.patch
+gregkh-usb-usbhid-use-usb_reset_composite_device.patch
+gregkh-usb-usbcore-recovery-from-set-configuration-failure.patch
+gregkh-usb-usb-drivers-usb-core-devio.c-dereferences-a-userspace-pointer.patch
+gregkh-usb-usb-new-devices-for-the-option-driver.patch

 USB tree updates

+x86_64-mm-acpi-blacklist-xw9300.patch
+x86_64-mm-apic-support-for-extended-apic-interrupt.patch
+x86_64-mm-mce_amd-relocate-sysfs-files.patch
+x86_64-mm-mce_amd-support-for-family-0x10-processors.patch
+x86_64-mm-mce_amd-cleanup.patch
+x86_64-mm-miscellaneous-mm-initc-fixes.patch

 x86_64 tree updates

+fall-back-to-old-style-call-trace-if-no-unwinding.patch
+allow-unwinder-to-build-without-module-support.patch

 Fix it.

+mm-slabc-fix-early-init-assumption.patch

 slab fix

+tiacx-ia64-fix.patch

 wireless driver fix

+selinux-add-hooks-for-key-subsystem.patch

 Wire the key management subsystem into selinux.

+powerpc-vdso-updates.patch

 powerpc update

+remove-empty-node-at-boot-time.patch

 NUMA fixlet.

+jbd-fix-bug-in-journal_commit_transaction-fix.patch

 Fix jbd-fix-bug-in-journal_commit_transaction.patch

+ufs-easy-debug.patch
+ufs-little-directory-lookup-optimization.patch
+ufs-i_blocks-wrong-count.patch
+ufs-unlock_super-without-lock.patch
+ufs-zero-metadata.patch
+ufs-printk-warning-fixes.patch

 More UFS fixes

-inotify-kernel-api.patch
-inotify-kernel-api-fix.patch
+inotify-split-kernel-api-from-userspace-support.patch
+inotify-add-names-inode-to-event-handler.patch
+inotify-add-interfaces-to-kernel-api.patch
+inotify-allow-watch-removal-from-event-handler.patch
+inotify-update-kernel-documentation.patch

 Updated inotify patch series

+lock-validator-introduce-warn_on_oncecond-speedup.patch

 Fix lock-validator-introduce-warn_on_oncecond.patch

+add-max6902-rtc-support-update.patch

 Fix add-max6902-rtc-support.patch

+nbd-endian-annotations.patch
+epoll-use-unlocked-wqueue-operations.patch

 misc updates

+per-task-delay-accounting-taskstats-interface-fix-2.patch

 Fix per-task-delay-accounting-taskstats-interface-fix-1.patch

+sched-fix-smt-nice-lock-contention-and-optimization.patch
+sched-fix-smt-nice-lock-contention-and-optimization-tidy.patch

 CPu scheduler scability improvements.

+namespaces-utsname-sysctl-hack-cleanup-2-fix.patch

 Fix namespaces-utsname-sysctl-hack-cleanup-2.patch

+reiser4-hardirq-include-fix.patch

 Fix reiser4.patch

+skeletonfb-remove-duplicate-module-init-exit-license-lines.patch
+neofb-fix-unblank-logic-interfering-with-lid-toggled-backlight.patch

 fbdev updates

+statistics-infrastructure-prerequisite-timestamp-fix.patch

 Fix statistics-infrastructure-prerequisite-timestamp.patch

+genirq-msi-fixes-2.patch

 Fix genirq-core.patch

+genirq-add-irq-chip-support-fix.patch

 Fix genirq-add-irq-chip-support.patch

+genirq-add-chip-eoi-fastack-fasteoi-fix.patch

 Fix genirq-add-chip-eoi-fastack-fasteoi.patch

+lock-validator-floppyc-irq-release-fix-fix.patch

 Fix lock-validator-floppyc-irq-release-fix.patch

+lock-validator-locking-api-self-tests-self-test-fix.patch

 Fix lock-validator-locking-api-self-tests.patch

+lock-validator-beautify-x86_64-stacktraces-fix-2.patch
+lock-validator-beautify-x86_64-stacktraces-fix-3.patch
+lock-validator-beautify-x86_64-stacktraces-fix-4.patch

 Fix lock-validator-beautify-x86_64-stacktraces.patch some more.

+lock-validator-x86_64-irqflags-trace-entrys-fix.patch

 Fix lock-validator-irqtrace-cleanup-include-asm-x86_64-irqflagsh.patch

+lock-validator-core-early_boot_irqs_-build-fix.patch
+lock-validator-core-fix-compiler-warning.patch

 Fix lock-validator-core.patch

+lock-validator-special-locking-serio.patch
+lockdep-add-i_mutex-ordering-annotations-to-the-sunrpc.patch
+lockdep-add-parent-child-annotations-to-usbfs.patch

 lockdep workarounds

+i386-remove-multi-entry-backtraces.patch

 More work on x86 backtraces.


All 1492 patches:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm2/patch-list

Re: 2.6.17-rc5-mm3

[Barry K. Nathan]

When I build ACPI processor support as a module, I get this:

  MODPOST
WARNING: drivers/acpi/processor.o - Section mismatch: reference to
.init.data: from .text between 'acpi_processor_power_init' (at offset
0xfb0) and 'acpi_safe_halt'

(This is also true of -mm2, but I didn't get a chance to report it
before -mm3 was released. Before then, I built it into the kernel and
not as a module.)

and I still get this:
WARNING: "scsi_tgt_queue_command" [drivers/scsi/libsrp.ko] undefined!
-- 
-Barry K. Nathan <barryn@pobox.com>

Re: 2.6.17-rc5-mm3

[Andrew Morton]

On Sun, 4 Jun 2006 02:38:03 -0700
"Barry K. Nathan" <barryn@pobox.com> wrote:

> When I build ACPI processor support as a module, I get this:
> 
>   MODPOST
> WARNING: drivers/acpi/processor.o - Section mismatch: reference to
> .init.data: from .text between 'acpi_processor_power_init' (at offset
> 0xfb0) and 'acpi_safe_halt'

yup.  The code in there is actually correct (assuming
acpi_processor_power_init()'s first invokation is at initcall-time).

Maybe we'll do something to kill the warning, once we're down to the last
few thousand of them ;)


> (This is also true of -mm2, but I didn't get a chance to report it
> before -mm3 was released. Before then, I built it into the kernel and
> not as a module.)
> 
> and I still get this:
> WARNING: "scsi_tgt_queue_command" [drivers/scsi/libsrp.ko] undefined!

git-scsi-target Kconfig snafu.  I passed it over to James the other day. 
He might have fixed it - I get my git-scsi-misc via git-infiniband (don't
ask) and it's a bit laggy.

Re: 2.6.17-rc5-mm3

[Michal Piotrowski]

Hi Andrew,

On 04/06/06, Andrew Morton <akpm@osdl.org> wrote:
> On Sun, 4 Jun 2006 02:38:03 -0700
> "Barry K. Nathan" <barryn@pobox.com> wrote:
>
> > When I build ACPI processor support as a module, I get this:
> >
> >   MODPOST
> > WARNING: drivers/acpi/processor.o - Section mismatch: reference to
> > .init.data: from .text between 'acpi_processor_power_init' (at offset
> > 0xfb0) and 'acpi_safe_halt'
>
> yup.  The code in there is actually correct (assuming
> acpi_processor_power_init()'s first invokation is at initcall-time).
>
> Maybe we'll do something to kill the warning, once we're down to the last
> few thousand of them ;)

I have got something similar
WARNING: drivers/usb/storage/usb-storage.o - Section mismatch:
reference to .exit.text: from .smp_locks after '' (at offset 0x3c)
WARNING: net/ipv4/netfilter/ip_conntrack.o - Section mismatch:
reference to .init.text: from .smp_locks after '' (at offset 0x8)
WARNING: net/ipv6/ipv6.o - Section mismatch: reference to .init.text:
from .smp_locks after '' (at offset 0x14c)
WARNING: net/ipv6/ipv6.o - Section mismatch: reference to .init.text:
from .smp_locks after '' (at offset 0x17c)

BTW. I still get this bug
http://www.stardust.webpages.pl/files/mm/2.6.17-rc5-mm2/bug_1.jpg
http://www.stardust.webpages.pl/files/mm/2.6.17-rc5-mm2/mm-config

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-rc5-mm3

[Ingo Molnar]

* Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:

> BTW. I still get this bug
> http://www.stardust.webpages.pl/files/mm/2.6.17-rc5-mm2/bug_1.jpg
> http://www.stardust.webpages.pl/files/mm/2.6.17-rc5-mm2/mm-config

could you please apply the following patches ontop of -mm3:

  http://redhat.com/~mingo/lockdep-patches/lockdep-combo-2.6.17-rc5-mm3.patch
  http://redhat.com/~mingo/lockdep-patches/lockdep-tracer-2.6.17-rc5-mm3.patch

accept all the default 'make oldconfig' options and reboot into the 
patched kernel. If everything goes well then the system should still 
boot up fine and you should still get the lockdep warning - but this 
time there should be a long trace in /proc/latency_trace. Please upload 
that trace - it gives us the kernel's function trace, leading up to the 
warning.

	Ingo

Re: 2.6.17-rc5-mm3

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]

On Sun, 04 Jun 2006 12:41:21 +0200, Ingo Molnar said:

> could you please apply the following patches ontop of -mm3:
> 
>   http://redhat.com/~mingo/lockdep-patches/lockdep-combo-2.6.17-rc5-mm3.patch
>   http://redhat.com/~mingo/lockdep-patches/lockdep-tracer-2.6.17-rc5-mm3.patch

Just for grins, I tried building this, and got this error:

  CC      kernel/irq/handle.o
kernel/irq/handle.c:246:35: error: macro "early_init_irq_lock_type" passed 1 arguments, but takes just 0
kernel/irq/handle.c:247: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
make[2]: *** [kernel/irq/handle.o] Error 1

It won't build if you don't have CONFIG_TRACE_IRQFLAGS defined - and that
is defined like this:

config TRACE_IRQFLAGS
        bool
        default y
        depends on TRACE_IRQFLAGS_SUPPORT
        depends on PROVE_SPIN_LOCKING || PROVE_RW_LOCKING

but my config has:
% grep PROVE .config
# CONFIG_PROVE_SPIN_LOCKING is not set
# CONFIG_PROVE_RW_LOCKING is not set
# CONFIG_PROVE_MUTEX_LOCKING is not set
# CONFIG_PROVE_RWSEM_LOCKING is not set

So using the defaults for the PROVE_* won't compile clean.  Yes, probably
a stupid setting for anybody applying the patches, but.. ;)

(I'm off to go build kernels without the patch, and with the PROVE_* set)..


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: 2.6.17-rc5-mm3

[Ingo Molnar]

* Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:

> Unfortunately I can't compile this
> Here is output from my build log

> /usr/src/linux-mm/kernel/sched.c:3040: error: 'p' redeclared as

i've uploaded a fixed version - does that work for you?

	Ingo

Re: 2.6.17-rc5-mm3

[Michal Piotrowski]

On 04/06/06, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
>
> > Unfortunately I can't compile this
> > Here is output from my build log
>
> > /usr/src/linux-mm/kernel/sched.c:3040: error: 'p' redeclared as
>
> i've uploaded a fixed version - does that work for you?

Yes, thanks.

Here is dmesg http://www.stardust.webpages.pl/files/mm/2.6.17-rc5-mm3/mm-dmesg
Here is latency trace
http://www.stardust.webpages.pl/files/mm/2.6.17-rc5-mm3/mm-latency.bz2
Here is config http://www.stardust.webpages.pl/files/mm/2.6.17-rc5-mm3/mm-config

Here is something new
Jun  4 23:59:44 ltg01-fedora kernel: hdd: set_drive_speed_status:
status=0x51 { DriveReady SeekComplete Error }
Jun  4 23:59:44 ltg01-fedora kernel: hdd: set_drive_speed_status:
error=0xb4 { AbortedCommand LastFailedSense=0x0b }
Jun  4 23:59:44 ltg01-fedora kernel: (          hdparm-1821 |#0): new
164424143 us user-latency.
Jun  4 23:59:44 ltg01-fedora kernel: stopped custom tracer.
Jun  4 23:59:44 ltg01-fedora kernel:
Jun  4 23:59:44 ltg01-fedora kernel: ============================
Jun  4 23:59:44 ltg01-fedora kernel: [ BUG: illegal lock usage! ]
Jun  4 23:59:44 ltg01-fedora kernel: ----------------------------
Jun  4 23:59:44 ltg01-fedora kernel: illegal {in-hardirq-W} ->
{hardirq-on-W} usage.
Jun  4 23:59:44 ltg01-fedora kernel: hdparm/1821 [HC0[0]:SC0[0]:HE1:SE1] takes:
Jun  4 23:59:44 ltg01-fedora kernel:  (ide_lock){++..}, at:
[<c0268388>] ide_dump_opcode+0x13/0x9b
Jun  4 23:59:44 ltg01-fedora kernel: {in-hardirq-W} state was registered at:
Jun  4 23:59:44 ltg01-fedora kernel:   [<c013b536>] lockdep_acquire+0x67/0x7f
Jun  4 23:59:44 ltg01-fedora kernel:   [<c0305755>] _spin_lock_irqsave+0x2d/0x3c
Jun  4 23:59:44 ltg01-fedora kernel:   [<c0265fff>] ide_intr+0x18/0x1ab
Jun  4 23:59:44 ltg01-fedora kernel:   [<c015062c>] handle_IRQ_event+0x1d/0x52
Jun  4 23:59:44 ltg01-fedora kernel:   [<c015169c>] handle_edge_irq+0x113/0x15a
Jun  4 23:59:44 ltg01-fedora kernel:   [<c0105857>] do_IRQ+0xa2/0xc7
Jun  4 23:59:44 ltg01-fedora kernel: irq event stamp: 2011
Jun  4 23:59:44 ltg01-fedora kernel: hardirqs last  enabled at (2011):
[<c0305b29>] _spin_unlock_irq+0x24/0x58
Jun  4 23:59:44 ltg01-fedora kernel: hardirqs last disabled at (2010):
[<c03056c9>] _spin_lock_irq+0x11/0x38
Jun  4 23:59:44 ltg01-fedora kernel: softirqs last  enabled at (2008):
[<c012630c>] __do_softirq+0xf0/0xf8
Jun  4 23:59:44 ltg01-fedora kernel: softirqs last disabled at (2001):
[<c0105741>] do_softirq+0x5e/0xd2
Jun  4 23:59:44 ltg01-fedora kernel:
Jun  4 23:59:44 ltg01-fedora kernel: other info that might help us debug this:
Jun  4 23:59:44 ltg01-fedora kernel: no locks held by hdparm/1821.
Jun  4 23:59:44 ltg01-fedora kernel:
Jun  4 23:59:44 ltg01-fedora kernel: stack backtrace:
Jun  4 23:59:44 ltg01-fedora kernel:  [<c0104513>] show_trace+0x1b/0x20
Jun  4 23:59:44 ltg01-fedora kernel:  [<c01045f1>] dump_stack+0x1f/0x24
Jun  4 23:59:44 ltg01-fedora kernel:  [<c013976c>] print_usage_bug+0x1a5/0x1b1
Jun  4 23:59:44 ltg01-fedora kernel:  [<c0139e90>] mark_lock+0x2ca/0x4f7
Jun  4 23:59:44 ltg01-fedora kernel:  [<c013aa96>] __lockdep_acquire+0x47e/0xaa4
Jun  4 23:59:44 ltg01-fedora kernel:  [<c013b536>] lockdep_acquire+0x67/0x7f
Jun  4 23:59:44 ltg01-fedora kernel:  [<c030552d>] _spin_lock+0x24/0x32
Jun  4 23:59:44 ltg01-fedora kernel:  [<c0268388>] ide_dump_opcode+0x13/0x9b
Jun  4 23:59:44 ltg01-fedora kernel:  [<c02688b6>] ide_dump_status+0x4a6/0x4cc
Jun  4 23:59:44 ltg01-fedora kernel:  [<c0267ae6>]
ide_config_drive_speed+0x32a/0x33a
Jun  4 23:59:44 ltg01-fedora kernel:  [<c0262dc5>] piix_tune_chipset+0x2ed/0x2f8
Jun  4 23:59:44 ltg01-fedora kernel:  [<c0262e31>]
piix_config_drive_xfer_rate+0x61/0xb5
Jun  4 23:59:44 ltg01-fedora kernel:  [<c0263a82>] set_using_dma+0x2f/0x60
Jun  4 23:59:44 ltg01-fedora kernel:  [<c0263bee>] ide_write_setting+0x4a/0xc3
Jun  4 23:59:44 ltg01-fedora kernel:  [<c02647ca>] generic_ide_ioctl+0x8a/0x47f
Jun  4 23:59:44 ltg01-fedora kernel:  [<f886003a>]
idecd_ioctl+0xfd/0x133 [ide_cd]
Jun  4 23:59:44 ltg01-fedora kernel:  [<c01f1fff>] blkdev_driver_ioctl+0x4b/0x5f
Jun  4 23:59:44 ltg01-fedora kernel:  [<c01f2783>] blkdev_ioctl+0x770/0x7bd
Jun  4 23:59:44 ltg01-fedora kernel:  [<c017dc0d>] block_ioctl+0x1f/0x21
Jun  4 23:59:44 ltg01-fedora kernel:  [<c0189353>] do_ioctl+0x27/0x6e
Jun  4 23:59:44 ltg01-fedora kernel:  [<c0189604>] vfs_ioctl+0x26a/0x280
Jun  4 23:59:44 ltg01-fedora kernel:  [<c0189667>] sys_ioctl+0x4d/0x7e
Jun  4 23:59:44 ltg01-fedora kernel:  [<c0305ed2>] sysenter_past_esp+0x63/0xa1
Jun  4 23:59:44 ltg01-fedora kernel: ---------------------------
Jun  4 23:59:44 ltg01-fedora kernel: | preempt count: 00000001 ]
Jun  4 23:59:44 ltg01-fedora kernel: | 1-level deep critical section nesting:
Jun  4 23:59:44 ltg01-fedora kernel: ----------------------------------------
Jun  4 23:59:44 ltg01-fedora kernel: .. [<c030551b>] .... _spin_lock+0x12/0x32
Jun  4 23:59:44 ltg01-fedora kernel: .....[<c0268388>] ..   ( <=
ide_dump_opcode+0x13/0x9b)
Jun  4 23:59:44 ltg01-fedora kernel:
Jun  4 23:59:44 ltg01-fedora kernel: ide: failed opcode was: unknown

I get this when I do "hdparm -c 1 -d 1 /dev/hd{c,d}"

>
>         Ingo
>

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-rc5-mm3

[Rafael J. Wysocki]

On Sunday 04 June 2006 08:20, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm3/

Small compilation fix needed for x86_64 without SMP:

 arch/x86_64/kernel/mce_amd.c |    4 ++++
 1 files changed, 4 insertions(+)

Index: linux-2.6.17-rc5-mm3/arch/x86_64/kernel/mce_amd.c
===================================================================
--- linux-2.6.17-rc5-mm3.orig/arch/x86_64/kernel/mce_amd.c
+++ linux-2.6.17-rc5-mm3/arch/x86_64/kernel/mce_amd.c
@@ -494,7 +494,11 @@ static __cpuinit int threshold_create_ba
 
 	kobject_set_name(&b->kobj, "threshold_bank%i", bank);
 	b->kobj.parent = &per_cpu(device_mce, cpu).kobj;
+#ifdef CONFIG_SMP
 	b->cpus = cpu_core_map[cpu];
+#else
+	b->cpus = CPU_MASK_CPU0;
+#endif
 
 	err = kobject_register(&b->kobj);
 	if (err)

Re: 2.6.17-rc5-mm3

[J.A. Magallón]

On Sat, 3 Jun 2006 23:20:04 -0700, Andrew Morton <akpm@osdl.org> wrote:

> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm3/
> 
> - Lots of PCI and USB updates
> 
> - The various lock validator, stack backtracing and IRQ management problems
>   are converging, but we're not quite there yet.
> 

Got this on boot. Looks like another locking bug in firewire:

ACPI: PCI Interrupt 0000:03:03.0[A] -> GSI 20 (level, low) -> IRQ 20
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[20]  MMIO=[ec024000-ec0247ff]  Max Packet=[2048]  IR/IT contexts=[4/8]
stopped custom tracer.

============================
[ BUG: illegal lock usage! ]
----------------------------
illegal {hardirq-on-W} -> {in-hardirq-R} usage.
idle/0 [HC1[1]:SC1[0]:HE0:SE0] takes:
 (hl_irqs_lock){--+.}, at: [<f8835cb9>] highlevel_host_reset+0x11/0x5b [ieee1394]
{hardirq-on-W} state was registered at:
  [<c0133fe4>] lockdep_acquire+0x4d/0x63
  [<c02f3421>] _write_lock+0x2e/0x3b
  [<f88365ab>] hpsb_register_highlevel+0xac/0xea [ieee1394]
  [<f8836d6a>] init_csr+0x28/0x3f [ieee1394]
  [<f880617d>] 0xf880617d
  [<c01398df>] sys_init_module+0x12a/0x1b7b
  [<c02f3b2d>] sysenter_past_esp+0x56/0x8d
irq event stamp: 258193
hardirqs last  enabled at (258192): [<c011fab5>] __do_softirq+0x67/0xf7
hardirqs last disabled at (258193): [<c0102eb7>] common_interrupt+0x1b/0x2c
softirqs last  enabled at (258186): [<c011fb34>] __do_softirq+0xe6/0xf7
softirqs last disabled at (258191): [<c0104cec>] do_softirq+0x5a/0xc9

other info that might help us debug this:
no locks held by idle/0.

stack backtrace:
 [<c01034ba>] show_trace+0x12/0x14
 [<c0103b8d>] dump_stack+0x19/0x1b
 [<c0132025>] print_usage_bug+0x20b/0x215
 [<c01329cc>] mark_lock+0x4fa/0x5b4
 [<c0133399>] __lockdep_acquire+0x310/0xbc0
 [<c0133fe4>] lockdep_acquire+0x4d/0x63
 [<c02f3153>] _read_lock+0x2e/0x3b
 [<f8835cb9>] highlevel_host_reset+0x11/0x5b [ieee1394]
 [<f8833867>] hpsb_selfid_complete+0x286/0x307 [ieee1394]
 [<f884ec30>] ohci_irq_handler+0x6c9/0x995 [ohci1394]
 [<c013d3a2>] handle_IRQ_event+0x2e/0x63
 [<c013e4c3>] handle_fasteoi_irq+0x6b/0xac
 [<c0104dc7>] do_IRQ+0x6c/0xa5
 =======================
 [<c0102ec1>] common_interrupt+0x25/0x2c
 [<c0104cec>] do_softirq+0x5a/0xc9
 =======================
 [<c011fb90>] irq_exit+0x4b/0x4d
 [<c0104dce>] do_IRQ+0x73/0xa5
 [<c0102ec1>] common_interrupt+0x25/0x2c
 [<c010164e>] cpu_idle+0x63/0x80
 [<c0100599>] rest_init+0x33/0x3a
 [<c03d97af>] start_kernel+0x339/0x3aa
 [<c0100210>] 0xc0100210
ieee1394: Host added: ID:BUS[0-00:1023]  GUID[00e018000063814f]

--
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.16-jam18 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Mon

Re: 2.6.17-rc5-mm3

[Andrew Morton]

On Mon, 5 Jun 2006 01:15:31 +0200
"J.A. Magallón" <jamagallon@ono.com> wrote:

> On Sat, 3 Jun 2006 23:20:04 -0700, Andrew Morton <akpm@osdl.org> wrote:
> 
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm3/
> > 
> > - Lots of PCI and USB updates
> > 
> > - The various lock validator, stack backtracing and IRQ management problems
> >   are converging, but we're not quite there yet.
> > 
> 
> Got this on boot. Looks like another locking bug in firewire:
> 
> ACPI: PCI Interrupt 0000:03:03.0[A] -> GSI 20 (level, low) -> IRQ 20
> ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[20]  MMIO=[ec024000-ec0247ff]  Max Packet=[2048]  IR/IT contexts=[4/8]
> stopped custom tracer.
> 
> ============================
> [ BUG: illegal lock usage! ]
> ----------------------------
> illegal {hardirq-on-W} -> {in-hardirq-R} usage.

So we have an rwlock which was acquired for writing under
local_irq_enable() but we later acquired it for reading inside an interrupt
handler.


> idle/0 [HC1[1]:SC1[0]:HE0:SE0] takes:
>  (hl_irqs_lock){--+.}, at: [<f8835cb9>] highlevel_host_reset+0x11/0x5b [ieee1394]
> {hardirq-on-W} state was registered at:
>   [<c0133fe4>] lockdep_acquire+0x4d/0x63
>   [<c02f3421>] _write_lock+0x2e/0x3b
>   [<f88365ab>] hpsb_register_highlevel+0xac/0xea [ieee1394]
>   [<f8836d6a>] init_csr+0x28/0x3f [ieee1394]
>   [<f880617d>] 0xf880617d
>   [<c01398df>] sys_init_module+0x12a/0x1b7b
>   [<c02f3b2d>] sysenter_past_esp+0x56/0x8d

Here's the irqs-on write_lock.

> irq event stamp: 258193
> hardirqs last  enabled at (258192): [<c011fab5>] __do_softirq+0x67/0xf7
> hardirqs last disabled at (258193): [<c0102eb7>] common_interrupt+0x1b/0x2c
> softirqs last  enabled at (258186): [<c011fb34>] __do_softirq+0xe6/0xf7
> softirqs last disabled at (258191): [<c0104cec>] do_softirq+0x5a/0xc9
> 
> other info that might help us debug this:
> no locks held by idle/0.
> 
> stack backtrace:
>  [<c01034ba>] show_trace+0x12/0x14
>  [<c0103b8d>] dump_stack+0x19/0x1b
>  [<c0132025>] print_usage_bug+0x20b/0x215
>  [<c01329cc>] mark_lock+0x4fa/0x5b4
>  [<c0133399>] __lockdep_acquire+0x310/0xbc0
>  [<c0133fe4>] lockdep_acquire+0x4d/0x63
>  [<c02f3153>] _read_lock+0x2e/0x3b
>  [<f8835cb9>] highlevel_host_reset+0x11/0x5b [ieee1394]
>  [<f8833867>] hpsb_selfid_complete+0x286/0x307 [ieee1394]
>  [<f884ec30>] ohci_irq_handler+0x6c9/0x995 [ohci1394]
>  [<c013d3a2>] handle_IRQ_event+0x2e/0x63
>  [<c013e4c3>] handle_fasteoi_irq+0x6b/0xac
>  [<c0104dc7>] do_IRQ+0x6c/0xa5

And here's the in-irq read_lock().

Simple fix would be to take hl_irqs_lock in an irq-safe manner everywhere.

Re: 2.6.17-rc5-mm3

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 970 bytes --]

On Mon, 05 Jun 2006 01:15:31 +0200, "J.A. =?UTF-8?B?TWFnYWxsw7Nu?=" said:
> On Sat, 3 Jun 2006 23:20:04 -0700, Andrew Morton <akpm@osdl.org> wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm3/

> ============================
> [ BUG: illegal lock usage! ]
> ----------------------------
> illegal {hardirq-on-W} -> {in-hardirq-R} usage.
> idle/0 [HC1[1]:SC1[0]:HE0:SE0] takes:
>  (hl_irqs_lock){--+.}, at: [<f8835cb9>] highlevel_host_reset+0x11/0x5b [ieee1394]
> {hardirq-on-W} state was registered at:
>   [<c0133fe4>] lockdep_acquire+0x4d/0x63
>   [<c02f3421>] _write_lock+0x2e/0x3b
>   [<f88365ab>] hpsb_register_highlevel+0xac/0xea [ieee1394]
>   [<f8836d6a>] init_csr+0x28/0x3f [ieee1394]
>   [<f880617d>] 0xf880617d
>   [<c01398df>] sys_init_module+0x12a/0x1b7b
>   [<c02f3b2d>] sysenter_past_esp+0x56/0x8d

ACK.  I saw this same one too, while udevd was trying to get its act
together in very early rc.sysinit....


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: 2.6.17-rc5-mm3

[Arjan van de Ven]

On Mon, 2006-06-05 at 01:15 +0200, J.A. Magallón wrote:
> On Sat, 3 Jun 2006 23:20:04 -0700, Andrew Morton <akpm@osdl.org> wrote:
> 
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm3/
> > 
> > - Lots of PCI and USB updates
> > 
> > - The various lock validator, stack backtracing and IRQ management problems
> >   are converging, but we're not quite there yet.
> > 
> 
> Got this on boot. Looks like another locking bug in firewire:
> 
> ACPI: PCI Interrupt 0000:03:03.0[A] -> GSI 20 (level, low) -> IRQ 20
> ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[20]  MMIO=[ec024000-ec0247ff]  Max Packet=[2048]  IR/IT contexts=[4/8]
> stopped custom tracer.
> 
> ============================
> [ BUG: illegal lock usage! ]
> ----------------------------
> illegal {hardirq-on-W} -> {in-hardirq-R} usage.
> idle/0 [HC1[1]:SC1[0]:HE0:SE0] takes:
>  (hl_irqs_lock){--+.}, at: [<f8835cb9>] highlevel_host_reset+0x11/0x5b [ieee1394]

this one was reported a few days ago and acknowledged by the firewire
people as real.. it seems they haven't sent Andrew a fix yet.
If they don't do that today I'll send a provisional fix

Re: 2.6.17-rc5-mm3

[J.A. Magallón]

On Sat, 3 Jun 2006 23:20:04 -0700, Andrew Morton <akpm@osdl.org> wrote:

> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm3/
> 
> - Lots of PCI and USB updates
> 
> - The various lock validator, stack backtracing and IRQ management problems
>   are converging, but we're not quite there yet.
> 

I got this with -mm2, is it supposed to be cured in -mm3 ? I still have to
try with mm3:

Jun  2 14:34:39 annwn kernel: Console: colour VGA+ 80x60
Jun  2 14:34:39 annwn kernel: ------------------------
Jun  2 14:34:39 annwn kernel: | Locking API testsuite:
Jun  2 14:34:39 annwn kernel: ----------------------------------------------------------------------------
Jun  2 14:34:39 annwn kernel:                                  | spin |wlock |rlock |mutex | wsem | rsem |
Jun  2 14:34:39 annwn kernel:   --------------------------------------------------------------------------
Jun  2 14:34:39 annwn kernel:                      A-A deadlock:failed|failed|failed|failed|failed|failed|
Jun  2 14:34:39 annwn kernel:                  A-B-B-A deadlock:failed|failed|  ok  |failed|failed|failed|
Jun  2 14:34:39 annwn kernel:              A-B-B-C-C-A deadlock:failed|failed|  ok  |failed|failed|failed|
Jun  2 14:34:39 annwn kernel:              A-B-C-A-B-C deadlock:failed|failed|  ok  |failed|failed|failed|
Jun  2 14:34:39 annwn kernel:          A-B-B-C-C-D-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
Jun  2 14:34:39 annwn kernel:          A-B-C-D-B-D-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
Jun  2 14:34:39 annwn kernel:          A-B-C-D-B-C-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
Jun  2 14:34:39 annwn kernel:                     double unlock:failed|failed|failed|failed|failed|failed|
Jun  2 14:34:39 annwn kernel:                  bad unlock order:failed|failed|failed|failed|failed|failed|
Jun  2 14:34:39 annwn kernel:   --------------------------------------------------------------------------
Jun  2 14:34:39 annwn kernel:               recursive read-lock:             |  ok  |             |failed|
Jun  2 14:34:39 annwn kernel:   --------------------------------------------------------------------------
Jun  2 14:34:39 annwn kernel:      hard-irqs-on + irq-safe-A/12:failed|failed|  ok  |
Jun  2 14:34:39 annwn kernel:      soft-irqs-on + irq-safe-A/12:failed|failed|  ok  |
Jun  2 14:34:39 annwn kernel:      hard-irqs-on + irq-safe-A/21:failed|failed|  ok  |
Jun  2 14:34:39 annwn kernel:      soft-irqs-on + irq-safe-A/21:failed|failed|  ok  |
Jun  2 14:34:39 annwn kernel:        sirq-safe-A => hirqs-on/12:failed|failed|  ok  |
Jun  2 14:34:39 annwn kernel:        sirq-safe-A => hirqs-on/21:failed|failed|  ok  |
Jun  2 14:34:39 annwn kernel:          hard-safe-A + irqs-on/12:failed|failed|  ok  |
Jun  2 14:34:39 annwn kernel:          soft-safe-A + irqs-on/12:failed|failed|  ok  |

(all tests failed like this...)

Jun  2 14:34:39 annwn kernel: --------------------------------------------------------
Jun  2 14:34:39 annwn kernel: 141 out of 206 testcases failed, as expected. |
Jun  2 14:34:39 annwn kernel: ----------------------------------------------------

Expected ? Uh ?

--
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.16-jam18 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Mon

Re: 2.6.17-rc5-mm3

[Barry K. Nathan]

On 6/4/06, J.A. Magallón <jamagallon@ono.com> wrote:
> Jun  2 14:34:39 annwn kernel: --------------------------------------------------------
> Jun  2 14:34:39 annwn kernel: 141 out of 206 testcases failed, as expected. |
> Jun  2 14:34:39 annwn kernel: ----------------------------------------------------
>
> Expected ? Uh ?

grep PROVE .config

Make sure all 4 of them are set to Y; if any of them are N, then test
case failures would in fact be expected.
-- 
-Barry K. Nathan <barryn@pobox.com>

Re: 2.6.17-rc5-mm3

[Grant Coady]

On Mon, 5 Jun 2006 01:28:42 +0200, "J.A. Magallón" <jamagallon@ono.com> wrote:

>On Sat, 3 Jun 2006 23:20:04 -0700, Andrew Morton <akpm@osdl.org> wrote:
>
>> 
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm3/
>> 
>> - Lots of PCI and USB updates
>> 
>> - The various lock validator, stack backtracing and IRQ management problems
>>   are converging, but we're not quite there yet.
>> 
>
>I got this with -mm2, is it supposed to be cured in -mm3 ? I still have to
>try with mm3:
>
>Jun  2 14:34:39 annwn kernel: Console: colour VGA+ 80x60
>Jun  2 14:34:39 annwn kernel: ------------------------
>Jun  2 14:34:39 annwn kernel: | Locking API testsuite:
>Jun  2 14:34:39 annwn kernel: ----------------------------------------------------------------------------
>Jun  2 14:34:39 annwn kernel:                                  | spin |wlock |rlock |mutex | wsem | rsem |
>Jun  2 14:34:39 annwn kernel:   --------------------------------------------------------------------------
>Jun  2 14:34:39 annwn kernel:                      A-A deadlock:failed|failed|failed|failed|failed|failed|
>Jun  2 14:34:39 annwn kernel:                  A-B-B-A deadlock:failed|failed|  ok  |failed|failed|failed|
>Jun  2 14:34:39 annwn kernel:              A-B-B-C-C-A deadlock:failed|failed|  ok  |failed|failed|failed|
>Jun  2 14:34:39 annwn kernel:              A-B-C-A-B-C deadlock:failed|failed|  ok  |failed|failed|failed|
>Jun  2 14:34:39 annwn kernel:          A-B-B-C-C-D-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
>Jun  2 14:34:39 annwn kernel:          A-B-C-D-B-D-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
>Jun  2 14:34:39 annwn kernel:          A-B-C-D-B-C-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
>Jun  2 14:34:39 annwn kernel:                     double unlock:failed|failed|failed|failed|failed|failed|
>Jun  2 14:34:39 annwn kernel:                  bad unlock order:failed|failed|failed|failed|failed|failed|
>Jun  2 14:34:39 annwn kernel:   --------------------------------------------------------------------------
>Jun  2 14:34:39 annwn kernel:               recursive read-lock:             |  ok  |             |failed|
>Jun  2 14:34:39 annwn kernel:   --------------------------------------------------------------------------
>Jun  2 14:34:39 annwn kernel:      hard-irqs-on + irq-safe-A/12:failed|failed|  ok  |
>Jun  2 14:34:39 annwn kernel:      soft-irqs-on + irq-safe-A/12:failed|failed|  ok  |
>Jun  2 14:34:39 annwn kernel:      hard-irqs-on + irq-safe-A/21:failed|failed|  ok  |
>Jun  2 14:34:39 annwn kernel:      soft-irqs-on + irq-safe-A/21:failed|failed|  ok  |
>Jun  2 14:34:39 annwn kernel:        sirq-safe-A => hirqs-on/12:failed|failed|  ok  |
>Jun  2 14:34:39 annwn kernel:        sirq-safe-A => hirqs-on/21:failed|failed|  ok  |
>Jun  2 14:34:39 annwn kernel:          hard-safe-A + irqs-on/12:failed|failed|  ok  |
>Jun  2 14:34:39 annwn kernel:          soft-safe-A + irqs-on/12:failed|failed|  ok  |
>
>(all tests failed like this...)
>
>Jun  2 14:34:39 annwn kernel: --------------------------------------------------------
>Jun  2 14:34:39 annwn kernel: 141 out of 206 testcases failed, as expected. |
>Jun  2 14:34:39 annwn kernel: ----------------------------------------------------
>
>Expected ? Uh ?

I got something like that here before turning on all the test options, 
suggest '  --  ' for non-selected tests.  More info, first four files:
<http://bugsplatter.mine.nu/test/linux-2.6/sempro/?M=D>

dmesg, false positives:

<http://bugsplatter.mine.nu/test/linux-2.6/sempro/dmesg-2.6.17-rc5-mm3a.gz>:

------------------------
| Locking API testsuite:
----------------------------------------------------------------------------
                                 | spin |wlock |rlock |mutex | wsem | rsem |
  --------------------------------------------------------------------------
                     A-A deadlock:failed|failed|failed|failed|failed|failed|
                 A-B-B-A deadlock:failed|failed|  ok  |failed|failed|failed|
             A-B-B-C-C-A deadlock:failed|failed|  ok  |failed|failed|failed|
             A-B-C-A-B-C deadlock:failed|failed|  ok  |failed|failed|failed|
         A-B-B-C-C-D-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
         A-B-C-D-B-D-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
         A-B-C-D-B-C-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
                    double unlock:failed|failed|failed|failed|failed|failed|
                 bad unlock order:failed|failed|failed|failed|failed|failed|
  --------------------------------------------------------------------------
              recursive read-lock:             |  ok  |             |failed|
  --------------------------------------------------------------------------
     hard-irqs-on + irq-safe-A/12:failed|failed|  ok  |
     soft-irqs-on + irq-safe-A/12:failed|failed|  ok  |
     hard-irqs-on + irq-safe-A/21:failed|failed|  ok  |
     soft-irqs-on + irq-safe-A/21:failed|failed|  ok  |

and dmesg, okay:
<http://bugsplatter.mine.nu/test/linux-2.6/sempro/dmesg-2.6.17-rc5-mm3a-2.gz>:
------------------------
| Locking API testsuite:
----------------------------------------------------------------------------
                                 | spin |wlock |rlock |mutex | wsem | rsem |
  --------------------------------------------------------------------------
                     A-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                 A-B-B-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
             A-B-B-C-C-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
             A-B-C-A-B-C deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
         A-B-B-C-C-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
         A-B-C-D-B-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
         A-B-C-D-B-C-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                    double unlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                 bad unlock order:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
  --------------------------------------------------------------------------
              recursive read-lock:             |  ok  |             |  ok  |
  --------------------------------------------------------------------------
                non-nested unlock:  ok  |  ok  |  ok  |  ok  |
  ------------------------------------------------------------
     hard-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
     soft-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
     hard-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
     soft-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |

Grant.

Re: 2.6.17-rc5-mm3

[Grant Coady]

On Mon, 5 Jun 2006 01:28:42 +0200, "J.A. Magallón" <jamagallon@ono.com> wrote:

>On Sat, 3 Jun 2006 23:20:04 -0700, Andrew Morton <akpm@osdl.org> wrote:
>
>> 
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm3/
>> 
>> - Lots of PCI and USB updates
>> 
>> - The various lock validator, stack backtracing and IRQ management problems
>>   are converging, but we're not quite there yet.
>> 
>
>I got this with -mm2, is it supposed to be cured in -mm3 ? I still have to
>try with mm3:
>
>Jun  2 14:34:39 annwn kernel: Console: colour VGA+ 80x60
>Jun  2 14:34:39 annwn kernel: ------------------------
>Jun  2 14:34:39 annwn kernel: | Locking API testsuite:
>Jun  2 14:34:39 annwn kernel: ----------------------------------------------------------------------------
>Jun  2 14:34:39 annwn kernel:                                  | spin |wlock |rlock |mutex | wsem | rsem |
>Jun  2 14:34:39 annwn kernel:   --------------------------------------------------------------------------
>Jun  2 14:34:39 annwn kernel:                      A-A deadlock:failed|failed|failed|failed|failed|failed|
>Jun  2 14:34:39 annwn kernel:                  A-B-B-A deadlock:failed|failed|  ok  |failed|failed|failed|
>Jun  2 14:34:39 annwn kernel:              A-B-B-C-C-A deadlock:failed|failed|  ok  |failed|failed|failed|
>Jun  2 14:34:39 annwn kernel:              A-B-C-A-B-C deadlock:failed|failed|  ok  |failed|failed|failed|
>Jun  2 14:34:39 annwn kernel:          A-B-B-C-C-D-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
>Jun  2 14:34:39 annwn kernel:          A-B-C-D-B-D-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
>Jun  2 14:34:39 annwn kernel:          A-B-C-D-B-C-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
>Jun  2 14:34:39 annwn kernel:                     double unlock:failed|failed|failed|failed|failed|failed|
>Jun  2 14:34:39 annwn kernel:                  bad unlock order:failed|failed|failed|failed|failed|failed|
>Jun  2 14:34:39 annwn kernel:   --------------------------------------------------------------------------
>Jun  2 14:34:39 annwn kernel:               recursive read-lock:             |  ok  |             |failed|
>Jun  2 14:34:39 annwn kernel:   --------------------------------------------------------------------------
>Jun  2 14:34:39 annwn kernel:      hard-irqs-on + irq-safe-A/12:failed|failed|  ok  |
>Jun  2 14:34:39 annwn kernel:      soft-irqs-on + irq-safe-A/12:failed|failed|  ok  |
>Jun  2 14:34:39 annwn kernel:      hard-irqs-on + irq-safe-A/21:failed|failed|  ok  |
>Jun  2 14:34:39 annwn kernel:      soft-irqs-on + irq-safe-A/21:failed|failed|  ok  |
>Jun  2 14:34:39 annwn kernel:        sirq-safe-A => hirqs-on/12:failed|failed|  ok  |
>Jun  2 14:34:39 annwn kernel:        sirq-safe-A => hirqs-on/21:failed|failed|  ok  |
>Jun  2 14:34:39 annwn kernel:          hard-safe-A + irqs-on/12:failed|failed|  ok  |
>Jun  2 14:34:39 annwn kernel:          soft-safe-A + irqs-on/12:failed|failed|  ok  |
>
>(all tests failed like this...)
>
>Jun  2 14:34:39 annwn kernel: --------------------------------------------------------
>Jun  2 14:34:39 annwn kernel: 141 out of 206 testcases failed, as expected. |
>Jun  2 14:34:39 annwn kernel: ----------------------------------------------------
>
>Expected ? Uh ?

I got something like that here before turning on all the test options, 
suggest '  --  ' for non-selected tests.  More info, first four files:
<http://bugsplatter.mine.nu/test/linux-2.6/sempro/?M=D>

dmesg, false positives:

<http://bugsplatter.mine.nu/test/linux-2.6/sempro/dmesg-2.6.17-rc5-mm3a.gz>:

------------------------
| Locking API testsuite:
----------------------------------------------------------------------------
                                 | spin |wlock |rlock |mutex | wsem | rsem |
  --------------------------------------------------------------------------
                     A-A deadlock:failed|failed|failed|failed|failed|failed|
                 A-B-B-A deadlock:failed|failed|  ok  |failed|failed|failed|
             A-B-B-C-C-A deadlock:failed|failed|  ok  |failed|failed|failed|
             A-B-C-A-B-C deadlock:failed|failed|  ok  |failed|failed|failed|
         A-B-B-C-C-D-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
         A-B-C-D-B-D-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
         A-B-C-D-B-C-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
                    double unlock:failed|failed|failed|failed|failed|failed|
                 bad unlock order:failed|failed|failed|failed|failed|failed|
  --------------------------------------------------------------------------
              recursive read-lock:             |  ok  |             |failed|
  --------------------------------------------------------------------------
     hard-irqs-on + irq-safe-A/12:failed|failed|  ok  |
     soft-irqs-on + irq-safe-A/12:failed|failed|  ok  |
     hard-irqs-on + irq-safe-A/21:failed|failed|  ok  |
     soft-irqs-on + irq-safe-A/21:failed|failed|  ok  |

and dmesg, okay:
<http://bugsplatter.mine.nu/test/linux-2.6/sempro/dmesg-2.6.17-rc5-mm3a-2.gz>:
------------------------
| Locking API testsuite:
----------------------------------------------------------------------------
                                 | spin |wlock |rlock |mutex | wsem | rsem |
  --------------------------------------------------------------------------
                     A-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                 A-B-B-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
             A-B-B-C-C-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
             A-B-C-A-B-C deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
         A-B-B-C-C-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
         A-B-C-D-B-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
         A-B-C-D-B-C-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                    double unlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                 bad unlock order:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
  --------------------------------------------------------------------------
              recursive read-lock:             |  ok  |             |  ok  |
  --------------------------------------------------------------------------
                non-nested unlock:  ok  |  ok  |  ok  |  ok  |
  ------------------------------------------------------------
     hard-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
     soft-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
     hard-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
     soft-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |

Grant.

Re: 2.6.17-rc5-mm3

[Ingo Molnar]

* J.A. Magallón <jamagallon@ono.com> wrote:

> I got this with -mm2, is it supposed to be cured in -mm3 ? I still 
> have to try with mm3:

> (all tests failed like this...)
> 
> Jun  2 14:34:39 annwn kernel: --------------------------------------------------------
> Jun  2 14:34:39 annwn kernel: 141 out of 206 testcases failed, as expected. |
> Jun  2 14:34:39 annwn kernel: ----------------------------------------------------
> 
> Expected ? Uh ?

to have lock validation you should have these options enabled:

 CONFIG_PROVE_SPIN_LOCKING=y
 CONFIG_PROVE_RW_LOCKING=y
 CONFIG_PROVE_MUTEX_LOCKING=y
 CONFIG_PROVE_RWSEM_LOCKING=y

otherwise the tests are still run, but the deadlocks are not detected. 
That's why those 141 testcases are 'expected' failures.

and definitely try -mm3 plus the current combo patch:

  http://redhat.com/~mingo/lockdep-patches/lockdep-combo-2.6.17-rc5-mm3.patch

	Ingo

Re: 2.6.17-rc5-mm3

[Mel Gorman]

I am seeing more networking-related funniness with 2.6.17-rc5-mm3 on the
same machine previously fixed by git-net-llc-fix.patch. The console log is
below. I've done no investigation work in case it's a known problem.

kernel /vmlinuz-autobench ro root=/dev/VolGroup00/LogVol00 rhgb quiet console=t
tyS1,19200 autobench_args: root=30726124 ABAT:1149529388 earlyprintk=serial,tty
S1,19200
   [Linux-bzImage, setup=0x1e00, size=0x1e0687]
initrd /initrd-autobench.img
   [Linux-initrd @ 0x37e60000, 0x18fbd9 bytes]
Bootdata ok (command line is ro root=/dev/VolGroup00/LogVol00 rhgb quiet console=ttyS1,19200 autobench_args: root=30726124 ABAT:1149529388 earlyprintk=serial,ttyS1,19200)
Linux version 2.6.17-rc5-mm2-autokern1 (root@bl6-13.ltc.austin.ibm.com) (/usr/local/autobench/var/tmp/build/scripts/mkcompile_h: line 61: /usr/local/autobench/sources/x86_64-cross/*/bin/x86_64-unknown-linux-gnu-gcc: No such file or directory) #1 SMP Mon Jun 5 12:36:09 CDT 2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009d400 (usable)
 BIOS-e820: 000000000009d400 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003ffcddc0 (usable)
 BIOS-e820: 000000003ffcddc0 - 000000003ffd0000 (ACPI data)
 BIOS-e820: 000000003ffd0000 - 0000000040000000 (reserved)
 BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
kernel direct mapping tables up to 100000000 @ 8000-8000
DMI 2.3 present.
ACPI: PM-Timer IO Port: 0x2208
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:1 APIC version 16
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 15:1 APIC version 16
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
Processor #2 15:1 APIC version 16
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled)
Processor #3 15:1 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x0e] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 14, version 17, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x0d] address[0xfec10000] gsi_base[24])
IOAPIC[1]: apic_id 13, version 17, address 0xfec10000, GSI 24-27
ACPI: IOAPIC (id[0x0c] address[0xfec20000] gsi_base[48])
IOAPIC[2]: apic_id 12, version 17, address 0xfec20000, GSI 48-51
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
Setting APIC routing to physical flat
ACPI: HPET id: 0x10228203 base: 0xfecff000
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 50000000 (gap: 40000000:bec00000)
SMP: Allowing 4 CPUs, 0 hotplug CPUs
Built 1 zonelists
Kernel command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet console=ttyS1,19200 autobench_args: root=30726124 ABAT:1149529388 earlyprintk=serial,ttyS1,19200
powernow-k8: MP systems not supported by PSB BIOS structure
powernow-k8: MP systems not supported by PSB BIOS structure
powernow-k8: MP systems not supported by PSB BIOS structure
powernow-k8: MP systems not supported by PSB BIOS structure
Red Hat nash version 5.0.32 starting
  Reading all physical volumes.  This may take a while...
  Found volume group "VolGroup00" using metadata type lvm2
  2 logical volume(s) in volume group "VolGroup00" now active
INIT: version 2.86 booting
                Welcome to Fedora Core
                press 'I' to enter interactive startup.
Setting clock  (localtime): Mon Jun  5 12:47:49 CDT 2006 [  OK  ]
Starting udev: [  OK  ]
Setting hostname bl6-13.ltc.austin.ibm.com:  [  OK  ]
Setting up Logical Volume Management:   2 logical volume(s) in volume group "VolGroup00" now active
[  OK  ]
Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/VolGroup00/LogVol00 
/dev/VolGroup00/LogVol00: clean, 285228/7929856 files, 2745851/7929856 blocks
[/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 -a /dev/sda1 
/boot: clean, 63/512512 files, 43614/512064 blocks
[  OK  ]
Remounting root filesystem in read-write mode:  [  OK  ]
Mounting local filesystems:  [  OK  ]
Enabling local filesystem quotas:  [  OK  ]
Enabling swap space:  [  OK  ]
INIT: Entering runlevel: 3
Entering non-interactive startup
Starting readahead_early:  Starting background readahead: [  OK  ]
[  OK  ]
FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.17-rc5-mm2-autokern1/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko): No such device
Bringing up loopback interface:  [  OK  ]
Bringing up interface eth1:  [  OK  ]
Starting system logger: [  OK  ]
Starting kernel logger: [  OK  ]
Starting irqbalance: [  OK  ]
Starting portmap: [  OK  ]
Starting NFS statd: [  OK  ]
Starting RPC idmapd: FATAL: Module sunrpc not found.
FATAL: Error running install command for sunrpc
Starting system message bus: [  OK  ]
Starting Bluetooth services:[  OK  ]
[  OK  ]
Mounting other filesystems:  [  OK  ]
Starting hidd: [  OK  ]
Starting automount: [  OK  ]
Starting smartd: [  OK  ]
Starting acpi daemon: [  OK  ]
Starting hpiod: [  OK  ]
Starting hpssd: [  OK  ]
Starting cups: [  OK  ]
Starting sshd: [  OK  ]
Starting sendmail: [  OK  ]
Starting sm-client: [  OK  ]
Starting console mouse services: [  OK  ]
Starting crond: [  OK  ]
Starting xfs: [  OK  ]
Starting anacron: [  OK  ]
Starting atd: [  OK  ]
Starting Avahi daemon: [  OK  ]
Starting cups-config-daemon: [  OK  ]
Starting HAL daemon: [  OK  ]
Fedora Core release 5 (Bordeaux)
Kernel 2.6.17-rc5-mm2-autokern1 on an x86_64
bl6-13.ltc.austin.ibm.com login: -- 0:conmux-control -- time-stamp -- Jun/05/06 10:47:46 --
-- 0:conmux-control -- time-stamp -- Jun/05/06 10:51:12 --
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81199568>] tg3_poll+0x1a1/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff81007807>] default_idle+0x0/0x54
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
Attempt to release alive inet socket ffff81003f8b2780
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81268fc4>] icmp_rcv+0x17c/0x184
 [<ffffffff812484ca>] ip_local_deliver+0xfe/0x1bf
 [<ffffffff812489bf>] ip_rcv+0x434/0x475
 [<ffffffff8122d615>] netif_receive_skb+0x2c6/0x2e5
 [<ffffffff81199add>] tg3_poll+0x716/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160<7>Losing some ticks... checking if CPU frequency changed.
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff81007807>] default_idle+0x0/0x54
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
Attempt to release alive inet socket ffff81003f8b2780
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81199568>] tg3_poll+0x1a1/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff81007807>] default_idle+0x0/0x54
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff8125923f>] tcp_rcv_established+0xe3/0x71a
 [<ffffffff8126079d>] tcp_v4_do_rcv+0x2b/0x2ff
 [<ffffffff8126106d>] tcp_v4_rcv+0x5fc/0x996
 [<ffffffff812484ca>] ip_local_deliver+0xfe/0x1bf
 [<ffffffff812489bf>] ip_rcv+0x434/0x475
 [<ffffffff8122d615>] netif_receive_skb+0x2c6/0x2e5
 [<ffffffff81199add>] tg3_poll+0x716/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81268fc4>] icmp_rcv+0x17c/0x184
 [<ffffffff812484ca>] ip_local_deliver+0xfe/0x1bf
 [<ffffffff812489bf>] ip_rcv+0x434/0x475
 [<ffffffff8122d615>] netif_receive_skb+0x2c6/0x2e5
 [<ffffffff81199add>] tg3_poll+0x716/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
Attempt to release alive inet socket ffff81003f8b2780
Unable to handle kernel NULL pointer dereference at 0000000000000010 RIP: 
 [<ffffffff8108b063>] prepare_binprm+0xb/0xf4
PGD ccd9067 PUD e0ce067 PMD 0 
Oops: 0000 [1] SMP 
last sysfs file: /block/sda/sda1/size
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff8125923f>] tcp_rcv_established+0xe3/0x71a
 [<ffffffff8126079d>] tcp_v4_do_rcv+0x2b/0x2ff
 [<ffffffff8126106d>] tcp_v4_rcv+0x5fc/0x996
 [<ffffffff812484ca>] ip_local_deliver+0xfe/0x1bf
 [<ffffffff812489bf>] ip_rcv+0x434/0x475
 [<ffffffff8122d615>] netif_receive_skb+0x2c6/0x2e5
 [<ffffffff81199add>] tg3_poll+0x716/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff81007807>] default_idle+0x0/0x54
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81199568>] tg3_poll+0x1a1/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff81007807>] default_idle+0x0/0x54
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
Attempt to release alive inet socket ffff81003f8b2780
CPU 2 
Modules linked in: ipv6 ppdev hidp rfcomm l2cap bluetooth video sony_acpi button battery asus_acpi ac lp parport_pc parport nvram
Pid: 18763, comm: sh Not tainted 2.6.17-rc5-mm2-autokern1 #1
RIP: 0010:[<ffffffff8108b063>]  [<ffffffff8108b063>] prepare_binprm+0xb/0xf4
RSP: 0018:ffff81000cb3ded8  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff81003eae6800 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000003fff RDI: ffff81003eae6800
RBP: ffff810029649c00 R08: ffff81000cb3c000 R09: 000000000000afa7
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff81001a618000 R14: 000000000070a560 R15: 000000000070b5c0
FS:  00002aba68ba6d30(0000) GS:ffff81003ffbe8c0(0000) knlGS:00000000f7f5a6b0
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000010 CR3: 000000000cdab000 CR4: 00000000000006e0
Process sh (pid: 18763, threadinfo ffff81000cb3c000, task ffff8100285437c0)
Stack: ffff81003eae6800 BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81199568>] tg3_poll+0x1a1/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff81007807>] default_idle+0x0/0x54
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
Attempt to release alive inet socket ffff81003f8b2780
ffffffff8108b63f ffff81000cb3df58 ffff81001a618000 
       000000000070a560 000000000070b5c0 ffff81001a618000 0000000000709620 
       0000000000000000 ffffffff81007f14 
Call Trace:
 [<ffffffff8108b63f>] do_execve+0x11d/0x24b
 [<ffffffff81007f14>] sys_execve+0x34/0x87
 [<ffffffff81009677>] stub_execve+0x67/0xb0
Code: 48 8b 41 10 48 8b 70 20 b8 f3 ff ff ff 0f b7 56 4c f6 c2 49 
RIP  [<ffffffff8108b063>] prepare_binprm+0xb/0xf4 RSP <ffff81000cb3ded8>
CR2: 0000000000000010
 BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff8125923f>] tcp_rcv_established+0xe3/0x71a
 [<ffffffff8126079d>] tcp_v4_do_rcv+0x2b/0x2ff
 [<ffffffff8126106d>] tcp_v4_rcv+0x5fc/0x996
 [<ffffffff812484ca>] ip_local_deliver+0xfe/0x1bf
 [<ffffffff812489bf>] ip_rcv+0x434/0x475
 [<ffffffff8122d615>] netif_receive_skb+0x2c6/0x2e5
 [<ffffffff81199add>] tg3_poll+0x716/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff81007807>] default_idle+0x0/0x54
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81199568>] tg3_poll+0x1a1/0x94f
 [<ffffffff811d94a3>] sd_rw_intr+0x2a2/0x2b1
 [<ffffffff811cbe47>] scsi_device_unbusy+0x5d/0x77
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
Attempt to release alive inet socket ffff81003f8b2780
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff8125923f>] tcp_rcv_established+0xe3/0x71a
 [<ffffffff8126079d>] tcp_v4_do_rcv+0x2b/0x2ff
 [<ffffffff8126106d>] tcp_v4_rcv+0x5fc/0x996
 [<ffffffff812484ca>] ip_local_deliver+0xfe/0x1bf
 [<ffffffff812489bf>] ip_rcv+0x434/0x475
 [<ffffffff8122d615>] netif_receive_skb+0x2c6/0x2e5
 [<ffffffff81199add>] tg3_poll+0x716/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff8125923f>] tcp_rcv_established+0xe3/0x71a
 [<ffffffff8126079d>] tcp_v4_do_rcv+0x2b/0x2ff
 [<ffffffff8126106d>] tcp_v4_rcv+0x5fc/0x996
 [<ffffffff812484ca>] ip_local_deliver+0xfe/0x1bf
 [<ffffffff812489bf>] ip_rcv+0x434/0x475
 [<ffffffff8122d615>] netif_receive_skb+0x2c6/0x2e5
 [<ffffffff81199add>] tg3_poll+0x716/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff8125923f>] tcp_rcv_established+0xe3/0x71a
 [<ffffffff8126079d>] tcp_v4_do_rcv+0x2b/0x2ff
 [<ffffffff8126106d>] tcp_v4_rcv+0x5fc/0x996
 [<ffffffff812484ca>] ip_local_deliver+0xfe/0x1bf
 [<ffffffff812489bf>] ip_rcv+0x434/0x475
 [<ffffffff8122d615>] netif_receive_skb+0x2c6/0x2e5
 [<ffffffff81199add>] tg3_poll+0x716/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff8125923f>] tcp_rcv_established+0xe3/0x71a
 [<ffffffff8126079d>] tcp_v4_do_rcv+0x2b/0x2ff
 [<ffffffff8126106d>] tcp_v4_rcv+0x5fc/0x996
 [<ffffffff812484ca>] ip_local_deliver+0xfe/0x1bf
 [<ffffffff812489bf>] ip_rcv+0x434/0x475
 [<ffffffff8122d615>] netif_receive_skb+0x2c6/0x2e5
 [<ffffffff81199add>] tg3_poll+0x716/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81199568>] tg3_poll+0x1a1/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81199568>] tg3_poll+0x1a1/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81199568>] tg3_poll+0x1a1/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
Attempt to release alive inet socket ffff81003f8b2780
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81199568>] tg3_poll+0x1a1/0x94f
 [<ffffffff811d94a3>] sd_rw_intr+0x2a2/0x2b1
 [<ffffffff811cbe47>] scsi_device_unbusy+0x5d/0x77
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff81007807>] default_idle+0x0/0x54
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
Attempt to release alive inet socket ffff81003f8b2780
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff8125923f>] tcp_rcv_established+0xe3/0x71a
 [<ffffffff8126079d>] tcp_v4_do_rcv+0x2b/0x2ff
 [<ffffffff8126106d>] tcp_v4_rcv+0x5fc/0x996
 [<ffffffff812484ca>] ip_local_deliver+0xfe/0x1bf
 [<ffffffff812489bf>] ip_rcv+0x434/0x475
 [<ffffffff8122d615>] netif_receive_skb+0x2c6/0x2e5
 [<ffffffff81199add>] tg3_poll+0x716/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff81007807>] default_idle+0x0/0x54
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81199568>] tg3_poll+0x1a1/0x94f
 [<ffffffff811d94a3>] sd_rw_intr+0x2a2/0x2b1
 [<ffffffff811cbe47>] scsi_device_unbusy+0x5d/0x77
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff81007807>] default_idle+0x0/0x54
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
Attempt to release alive inet socket ffff81003f8b2780
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff8125923f>] tcp_rcv_established+0xe3/0x71a
 [<ffffffff8126079d>] tcp_v4_do_rcv+0x2b/0x2ff
 [<ffffffff8126106d>] tcp_v4_rcv+0x5fc/0x996
 [<ffffffff812484ca>] ip_local_deliver+0xfe/0x1bf
 [<ffffffff812489bf>] ip_rcv+0x434/0x475
 [<ffffffff8122d615>] netif_receive_skb+0x2c6/0x2e5
 [<ffffffff81199add>] tg3_poll+0x716/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff81007807>] default_idle+0x0/0x54
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
BUG: warning at include/net/dst.h:153/dst_release()
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81252ce2>] tcp_recvmsg+0x622/0x7fb
 [<ffffffff8122720e>] sock_common_recvmsg+0x2d/0x44
 [<ffffffff81223aaf>] do_sock_read+0xc6/0xd1
 [<ffffffff81223bff>] sock_aio_read+0x4f/0x5e
 [<ffffffff8102bed5>] __wake_up+0x36/0x4d
 [<ffffffff81080bc8>] do_sync_read+0xc9/0x106
 [<ffffffff81045d20>] autoremove_wake_function+0x0/0x2e
 [<ffffffff81170577>] tty_ldisc_deref+0x65/0x77
 [<ffffffff81080ce9>] vfs_read+0xe4/0x172
 [<ffffffff81081037>] sys_read+0x45/0x6e
 [<ffffffff810092be>] system_call+0x7e/0x83
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81252ce2>] tcp_recvmsg+0x622/0x7fb
 [<ffffffff8122720e>] sock_common_recvmsg+0x2d/0x44
 [<ffffffff81223aaf>] do_sock_read+0xc6/0xd1
 [<ffffffff81223bff>] sock_aio_read+0x4f/0x5e
 [<ffffffff8102bed5>] __wake_up+0x36/0x4d
 [<ffffffff81080bc8>] do_sync_read+0xc9/0x106
 [<ffffffff81045d20>] autoremove_wake_function+0x0/0x2e
 [<ffffffff81170577>] tty_ldisc_deref+0x65/0x77
 [<ffffffff81080ce9>] vfs_read+0xe4/0x172
 [<ffffffff81081037>] sys_read+0x45/0x6e
 [<ffffffff810092be>] system_call+0x7e/0x83
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81199568>] tg3_poll+0x1a1/0x94f
 [<ffffffff811d94a3>] sd_rw_intr+0x2a2/0x2b1
 [<ffffffff811cbe47>] scsi_device_unbusy+0x5d/0x77
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff81007807>] default_idle+0x0/0x54
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
Attempt to release alive inet socket ffff81003f8b2780
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff8125923f>] tcp_rcv_established+0xe3/0x71a
 [<ffffffff8126079d>] tcp_v4_do_rcv+0x2b/0x2ff
 [<ffffffff8126106d>] tcp_v4_rcv+0x5fc/0x996
 [<ffffffff812484ca>] ip_local_deliver+0xfe/0x1bf
 [<ffffffff812489bf>] ip_rcv+0x434/0x475
 [<ffffffff8122d615>] netif_receive_skb+0x2c6/0x2e5
 [<ffffffff81199add>] tg3_poll+0x716/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff81007807>] default_idle+0x0/0x54
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
BUG: warning at include/net/dst.h:153/dst_release()
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81199568>] tg3_poll+0x1a1/0x94f
 [<ffffffff811d94a3>] sd_rw_intr+0x2a2/0x2b1
 [<ffffffff811cbe47>] scsi_device_unbusy+0x5d/0x77
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff81007807>] default_idle+0x0/0x54
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
Attempt to release alive inet socket ffff81003f8b2780
Call Trace:
 [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81252ce2>] tcp_recvmsg+0x622/0x7fb
 [<ffffffff8122720e>] sock_common_recvmsg+0x2d/0x44
 [<ffffffff81223aaf>] do_sock_read+0xc6/0xd1
 [<ffffffff81223bff>] sock_aio_read+0x4f/0x5e
 [<ffffffff8102bed5>] __wake_up+0x36/0x4d
 [<ffffffff81080bc8>] do_sync_read+0xc9/0x106BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81199568>] tg3_poll+0x1a1/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
Attempt to release alive inet socket ffff81003f8b2780
 [<ffffffff81045d20>] autoremove_wake_function+0x0/0x2e
 [<ffffffff81092210>] do_ioctl+0x64/0x6f
 [<ffffffff81080ce9>] vfs_read+0xe4/0x172
 [<ffffffff81081037>] sys_read+0x45/0x6e
 [<ffffffff810092be>] system_call+0x7e/0x83
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81252ce2>] tcp_recvmsg+0x622/0x7fb
 [<ffffffff8122720e>] sock_common_recvmsg+0x2d/0x44
 [<ffffffff81223aaf>] do_sock_read+0xc6/0xd1
 [<ffffffff81223bff>] sock_aio_read+0x4f/0x5e
 [<ffffffff8102bed5>] __wake_up+0x36/0x4d
 [<ffffffff81080bc8>] do_sync_read+0xc9/0x106
 [<ffffffff81045d20>] autoremove_wake_function+0x0/0x2e
 [<ffffffff81092210>] do_ioctl+0x64/0x6f
 [<ffffffff81080ce9>] vfs_read+0xe4/0x172
 [<ffffffff81081037>] sys_read+0x45/0x6e
 [<ffffffff810092be>] system_call+0x7e/0x83
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81252ce2>] tcp_recvmsg+0x622/0x7fb
 [<ffffffff8122720e>] sock_common_recvmsg+0x2d/0x44
 [<ffffffff81223aaf>] do_sock_read+0xc6/0xd1
 [<ffffffff81223bff>] sock_aio_read+0x4f/0x5e
 [<ffffffff8102bed5>] __wake_up+0x36/0x4d
 [<ffffffff81080bc8>] do_sync_read+0xc9/0x106
 [<ffffffff81045d20>] autoremove_wake_function+0x0/0x2e
 [<ffffffff81092210>] do_ioctl+0x64/0x6f
 [<ffffffff81080ce9>] vfs_read+0xe4/0x172BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81199568>] tg3_poll+0x1a1/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff81007807>] default_idle+0x0/0x54
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
Attempt to release alive inet socket ffff81003f8b2780
 [<ffffffff81081037>] sys_read+0x45/0x6e
 [<ffffffff810092be>] system_call+0x7e/0x83
general protection fault: 0000 [2] SMP 
last sysfs file: /block/sda/sda1/size
CPU 3 
Modules linked in: ipv6 ppdev hidp rfcomm l2cap bluetooth video sony_acpi button battery asus_acpi ac lp parport_pc parport nvram
Pid: 17887, comm: sshd Not tainted 2.6.17-rc5-mm2-autokern1 #1
RIP: 0010:[<ffffffff81228334>]  [<ffffffff81228334>] skb_drop_fraglist+0x17/0x26
RSP: 0018:ffff81000ef8dc48  EFLAGS: 00010206
RAX: 00000000026b2300 RBX: 4000000000000060 RCX: 000000000000b56c
RDX: ffff8100162f6900 RSI: ffffffff81321250 RDI: 4000000000000060
RBP: 0000000000000090 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000000 R11: ffff81000ea78800 R12: 00000000ffffff95
R13: 0000000000000000 R14: ffff810034b84ac0 R15: 0000000000003f70
FS:  00002ae22a4babe0(0000) GS:ffff810037e0cdc0(0000) knlGS:00000000f7f0b6b0
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000005b9e5c CR3: 000000000f2ef000 CR4: 00000000000006e0
Process sshd (pid: 17887, threadinfo ffff81000ef8c000, task ffff810015501840)
Stack: ffff810034b84ac0 ffffffff812283c7 00000000000001d8 ffff810034b84ac0 
       0000000000000090 ffffffff812281c2 ffff81000ea78800 ffffffff81252ce2 
       0000000000000246 0000000100000000 
Call Trace:
 [<ffffffff812283c7>] skb_release_data+0x84/0x97
 [<ffffffff812281c2>] kfree_skbmem+0x9/0x7fBUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81199568>] tg3_poll+0x1a1/0x94f
 [<ffffffff8103b598>] do_timer+0x9b/0x4bd
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
Attempt to release alive inet socket ffff81003f8b2780
 [<ffffffff81252ce2>] tcp_recvmsg+0x622/0x7fb
 [<ffffffff8122720e>] sock_common_recvmsg+0x2d/0x44
 [<ffffffff81223aaf>] do_sock_read+0xc6/0xd1
 [<ffffffff81223bff>] sock_aio_read+0x4f/0x5e
 [<ffffffff8102bed5>] __wake_up+0x36/0x4d
 [<ffffffff81080bc8>] do_sync_read+0xc9/0x106
 [<ffffffff81045d20>] autoremove_wake_function+0x0/0x2e
 [<ffffffff81092210>] do_ioctl+0x64/0x6f
 [<ffffffff81080ce9>] vfs_read+0xe4/0x172
 [<ffffffff81081037>] sys_read+0x45/0x6e
 [<ffffffff810092be>] system_call+0x7e/0x83
Code: 48 8b 1b e8 b9 ff ff ff 48 85 db 75 f0 5b c3 55 53 48 89 fb 
RIP  [<ffffffff81228334>] skb_drop_fraglist+0x17/0x26 RSP <ffff81000ef8dc48>
 ----------- [cut here ] --------- [please bite here ] ---------
Kernel BUG at mm/slab.c:3430
invalid opcode: 0000 [3] SMP 
last sysfs file: /block/sda/sda1/size
CPU 1 
Modules linked in: ipv6 ppdev hidp rfcomm l2cap bluetooth video sony_acpi button battery asus_acpi ac lp parport_pc parport nvram
Pid: 6, comm: ksoftirqd/1 Not tainted 2.6.17-rc5-mm2-autokern1 #1
RIP: 0010:[<ffffffff8107d0a4>]  [<ffffffff8107d0a4>] kmem_cache_free+0x5f/0x77
RSP: 0018:ffff810037e1ff28  EFLAGS: 00010287
RAX: 0000000000000080 RBX: ffff81000cfc1480 RCX: 000000000000000a
RDX: ffff81000185c980 RSI: ffff81000e3a6c00 RDI: ffff8100026b2340
RBP: ffff8100024e7d40 R08: 0000000000000008 R09: 0000000000000000
BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81199568>] tg3_poll+0x1a1/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
Attempt to release alive inet socket ffff81003f8b2780
R10: 0000000000000000 R11: ffff81003ff950d0 R12: 0000000000000008
R13: 0000000000000001 R14: ffffffff812b1104 R15: 0000000000000000
FS:  00002ae22a4babe0(0000) GS:ffff81003ff81340(0000) knlGS:00000000f7f5c6b0
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00000000005b9e5c CR3: 0000000001001000 CR4: 00000000000006e0
Process ksoftirqd/1 (pid: 6, threadinfo ffff810037e14000, task ffff81003ff950d0)
Stack: ffff81000cfc1480 ffffffff8104394c ffff8100024e7dc0 0000000000000000 
       ffffffff814cbc90 ffffffff810439ee 0000000000000000 ffffffff81037bc1 
       0000000000000001 ffffffff81476f90 
Call Trace:
 <IRQ> [<ffffffff8104394c>] __rcu_process_callbacks+0x12a/0x1ab
 [<ffffffff810439ee>] rcu_process_callbacks+0x21/0x42
 [<ffffffff81037bc1>] tasklet_action+0x69/0xa8
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff81037d1b>] ksoftirqd+0x0/0xbf
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 <EOI> [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff81037d84>] ksoftirqd+0x69/0xbf
 [<ffffffff81045806>] kthread+0x107/0x133
 [<ffffffff81037d1b>] ksoftirqd+0x0/0xbf
 [<ffffffff8100a146>] child_rip+0x8/0x12
 [<ffffffff81037d1b>] ksoftirqd+0x0/0xbf
 [<ffffffff810456ff>] kthread+0x0/0x133
 [<ffffffff8100a13e>] child_rip+0x0/0x12
Code: 0f 0b 68 41 56 2b 81 c2 66 0d 9c 5b fa 31 d2 e8 99 f9 ff ff 
RIP  [<ffffffff8107d0a4>] kmem_cache_free+0x5f/0x77BUG: warning at include/net/dst.h:153/dst_release()
Call Trace:
 <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
 [<ffffffff81199568>] tg3_poll+0x1a1/0x94f
 [<ffffffff8122d80c>] net_rx_action+0xac/0x160
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
 [<ffffffff810097b8>] ret_from_intr+0x0/0xb
 <EOI>
Attempt to release alive inet socket ffff81003f8b2780
 RSP <ffff810037e1ff28>
 <3>BUG: sleeping function called from invalid context at include/linux/rwsem.h:53
in_atomic():1, irqs_disabled():0
Call Trace:
 <IRQ> [<ffffffff810299a0>] __might_sleep+0xc0/0xc2
 [<ffffffff8103f5a1>] blocking_notifier_call_chain+0x1f/0x4e
 [<ffffffff81034c96>] do_exit+0x22/0x8b2
 [<ffffffff8128a3a7>] _spin_unlock_irqrestore+0xb/0xd
 [<ffffffff8100aa61>] do_divide_error+0x0/0xa2
 [<ffffffff8128ad5e>] do_trap+0xe6/0xf3
 [<ffffffff8100ac90>] do_invalid_op+0x9b/0xa5
 [<ffffffff8107d0a4>] kmem_cache_free+0x5f/0x77
 [<ffffffff81009f8d>] error_exit+0x0/0x84
 [<ffffffff8107d0a4>] kmem_cache_free+0x5f/0x77
 [<ffffffff8104394c>] __rcu_process_callbacks+0x12a/0x1ab
 [<ffffffff810439ee>] rcu_process_callbacks+0x21/0x42
 [<ffffffff81037bc1>] tasklet_action+0x69/0xa8
 [<ffffffff81037904>] __do_softirq+0x48/0xb4
 [<ffffffff81037d1b>] ksoftirqd+0x0/0xbf
 [<ffffffff8100a496>] call_softirq+0x1e/0x28
 <EOI> [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
 [<ffffffff81037d84>] ksoftirqd+0x69/0xbf
 [<ffffffff81045806>] kthread+0x107/0x133
 [<ffffffff81037d1b>] ksoftirqd+0x0/0xbf
 [<ffffffff8100a146>] child_rip+0x8/0x12
 [<ffffffff81037d1b>] ksoftirqd+0x0/0xbf
 [<ffffffff810456ff>] kthread+0x0/0x133
 [<ffffffff8100a13e>] child_rip+0x0/0x12
Kernel panic - not syncing: Aiee, killing interrupt handler!
-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: 2.6.17-rc5-mm3

[Andrew Morton]

On Mon, 5 Jun 2006 18:56:37 +0100
mel@csn.ul.ie (Mel Gorman) wrote:

> 
> I am seeing more networking-related funniness with 2.6.17-rc5-mm3 on the
> same machine previously fixed by git-net-llc-fix.patch. The console log is
> below. I've done no investigation work in case it's a known problem.

It's not a known problem, afaik.

> ...
> Starting anacron: [  OK  ]
> Starting atd: [  OK  ]
> Starting Avahi daemon: [  OK  ]
> Starting cups-config-daemon: [  OK  ]
> Starting HAL daemon: [  OK  ]
> Fedora Core release 5 (Bordeaux)
> Kernel 2.6.17-rc5-mm2-autokern1 on an x86_64
> bl6-13.ltc.austin.ibm.com login: -- 0:conmux-control -- time-stamp -- Jun/05/06 10:47:46 --
> -- 0:conmux-control -- time-stamp -- Jun/05/06 10:51:12 --
> BUG: warning at include/net/dst.h:153/dst_release()
> Call Trace:
>  <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
>  [<ffffffff81199568>] tg3_poll+0x1a1/0x94f
>  [<ffffffff8122d80c>] net_rx_action+0xac/0x160
>  [<ffffffff81037904>] __do_softirq+0x48/0xb4
>  [<ffffffff8100a496>] call_softirq+0x1e/0x28
>  [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
>  [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
>  [<ffffffff81007807>] default_idle+0x0/0x54
>  [<ffffffff810097b8>] ret_from_intr+0x0/0xb
>  <EOI>
> Attempt to release alive inet socket ffff81003f8b2780
> BUG: warning at include/net/dst.h:153/dst_release()
> Call Trace:
>  <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
>  [<ffffffff81268fc4>] icmp_rcv+0x17c/0x184
>  [<ffffffff812484ca>] ip_local_deliver+0xfe/0x1bf
>  [<ffffffff812489bf>] ip_rcv+0x434/0x475
>  [<ffffffff8122d615>] netif_receive_skb+0x2c6/0x2e5
>  [<ffffffff81199add>] tg3_poll+0x716/0x94f
>  [<ffffffff8122d80c>] net_rx_action+0xac/0x160<7>Losing some ticks... checking if CPU frequency changed.
>  [<ffffffff81037904>] __do_softirq+0x48/0xb4
>  [<ffffffff8100a496>] call_softirq+0x1e/0x28
>  [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
>  [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
>  [<ffffffff81007807>] default_idle+0x0/0x54
>  [<ffffffff810097b8>] ret_from_intr+0x0/0xb

There are quite a few changes in the net tree.  I guess the first thing to
investigate would be 2.6.17-rc5+origin.patch+git-net.patch.

Re: 2.6.17-rc5-mm3

[Mel Gorman]

On Mon, 5 Jun 2006, Andrew Morton wrote:

> On Mon, 5 Jun 2006 18:56:37 +0100
> mel@csn.ul.ie (Mel Gorman) wrote:
>
>>
>> I am seeing more networking-related funniness with 2.6.17-rc5-mm3 on the
>> same machine previously fixed by git-net-llc-fix.patch. The console log is
>> below. I've done no investigation work in case it's a known problem.
>
> It's not a known problem, afaik.
>
>> ...
>> Starting anacron: [  OK  ]
>> Starting atd: [  OK  ]
>> Starting Avahi daemon: [  OK  ]
>> Starting cups-config-daemon: [  OK  ]
>> Starting HAL daemon: [  OK  ]
>> Fedora Core release 5 (Bordeaux)
>> Kernel 2.6.17-rc5-mm2-autokern1 on an x86_64
>> bl6-13.ltc.austin.ibm.com login: -- 0:conmux-control -- time-stamp -- Jun/05/06 10:47:46 --
>> -- 0:conmux-control -- time-stamp -- Jun/05/06 10:51:12 --
>> BUG: warning at include/net/dst.h:153/dst_release()
>> Call Trace:
>>  <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
>>  [<ffffffff81199568>] tg3_poll+0x1a1/0x94f
>>  [<ffffffff8122d80c>] net_rx_action+0xac/0x160
>>  [<ffffffff81037904>] __do_softirq+0x48/0xb4
>>  [<ffffffff8100a496>] call_softirq+0x1e/0x28
>>  [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
>>  [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
>>  [<ffffffff81007807>] default_idle+0x0/0x54
>>  [<ffffffff810097b8>] ret_from_intr+0x0/0xb
>>  <EOI>
>> Attempt to release alive inet socket ffff81003f8b2780
>> BUG: warning at include/net/dst.h:153/dst_release()
>> Call Trace:
>>  <IRQ> [<ffffffff81228274>] __kfree_skb+0x3c/0xbd
>>  [<ffffffff81268fc4>] icmp_rcv+0x17c/0x184
>>  [<ffffffff812484ca>] ip_local_deliver+0xfe/0x1bf
>>  [<ffffffff812489bf>] ip_rcv+0x434/0x475
>>  [<ffffffff8122d615>] netif_receive_skb+0x2c6/0x2e5
>>  [<ffffffff81199add>] tg3_poll+0x716/0x94f
>>  [<ffffffff8122d80c>] net_rx_action+0xac/0x160<7>Losing some ticks... checking if CPU frequency changed.
>>  [<ffffffff81037904>] __do_softirq+0x48/0xb4
>>  [<ffffffff8100a496>] call_softirq+0x1e/0x28
>>  [<ffffffff8100b84e>] do_softirq+0x2c/0x7e
>>  [<ffffffff8100b6c8>] do_IRQ+0x50/0x59
>>  [<ffffffff81007807>] default_idle+0x0/0x54
>>  [<ffffffff810097b8>] ret_from_intr+0x0/0xb
>
> There are quite a few changes in the net tree.  I guess the first thing to
> investigate would be 2.6.17-rc5+origin.patch+git-net.patch.
>

That survived long enough to build a kernel, but backing out git-net on 
top of mm like I did for the LLC bug also survived. Not sure what is going 
on.

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

Re: 2.6.17-rc5-mm3

[Mel Gorman]

On Mon, 5 Jun 2006, Andrew Morton wrote:

> On Mon, 5 Jun 2006 18:56:37 +0100
> mel@csn.ul.ie (Mel Gorman) wrote:
>
>>
>> I am seeing more networking-related funniness with 2.6.17-rc5-mm3 on the
>> same machine previously fixed by git-net-llc-fix.patch. The console log is
>> below. I've done no investigation work in case it's a known problem.
>
> It's not a known problem, afaik.
>
>> ...
>> Starting anacron: [  OK  ]
>> Starting atd: [  OK  ]
>> Starting Avahi daemon: [  OK  ]
>> Starting cups-config-daemon: [  OK  ]
>> Starting HAL daemon: [  OK  ]
>> Fedora Core release 5 (Bordeaux)
>> Kernel 2.6.17-rc5-mm2-autokern1 on an x86_64

Bah, I'm a spanner. The patches I was testing were rebased to the latest 
-mm, but the kernel version they were then tested on was not changed. This 
was probably the LLC bug with a different shaped error and the first set 
of tests are passing with -mm3. Sorry for the noise.

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

Re: 2.6.17-rc5-mm3

[Dave Jones]

On Sat, Jun 03, 2006 at 11:20:04PM -0700, Andrew Morton wrote:
 > 
 > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm3/
 > 
 > - Lots of PCI and USB updates
 > 
 > - The various lock validator, stack backtracing and IRQ management problems
 >   are converging, but we're not quite there yet.

Thought I'd try my bi-annual "poke at -mm". Results were less
than spectacular.

http://www.codemonkey.org.uk/junk/DSC00347.JPG
First the sound driver oopsed.

Then, the whole thing locked up after probing the parallel port.
I disabled it in the BIOS, and then it locked up probing the floppy drive..
http://www.codemonkey.org.uk/junk/DSC00348.JPG

System is still alive, and responds to keyboard, but makes no forward progress.

(sysrq-B spewed a lockdep trace and then rebooted. I'll try and get
that hooked up to a serial console)

On a whim, I enabled the floppy drive in the BIOS, and rebooted.
That got me here. http://www.codemonkey.org.uk/junk/DSC00349.JPG
Same dead userspace.

Off to find a serial cable.

		Dave

-- 
http://www.codemonkey.org.uk

Re: 2.6.17-rc5-mm3

[Andrew Morton]

On Mon, 5 Jun 2006 15:48:45 -0400
Dave Jones <davej@redhat.com> wrote:

> On Sat, Jun 03, 2006 at 11:20:04PM -0700, Andrew Morton wrote:
>  > 
>  > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm3/
>  > 
>  > - Lots of PCI and USB updates
>  > 
>  > - The various lock validator, stack backtracing and IRQ management problems
>  >   are converging, but we're not quite there yet.
> 
> Thought I'd try my bi-annual "poke at -mm". Results were less
> than spectacular.
> 
> http://www.codemonkey.org.uk/junk/DSC00347.JPG
> First the sound driver oopsed.

That's a bug in sound/pci/cs4281.c.

There's a debug patch in -mm
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm3/broken-out/debug-shared-irqs.patch
which trips up drivers which request an IRQ before their IRQ handler is
ready to accept IRQs (they'll crash in real life if the IRQ is shared).

> Then, the whole thing locked up after probing the parallel port.
> I disabled it in the BIOS, and then it locked up probing the floppy drive..
> http://www.codemonkey.org.uk/junk/DSC00348.JPG

That looks like the same thing?

> System is still alive, and responds to keyboard, but makes no forward progress.
> 
> (sysrq-B spewed a lockdep trace and then rebooted. I'll try and get
> that hooked up to a serial console)
> 
> On a whim, I enabled the floppy drive in the BIOS, and rebooted.
> That got me here. http://www.codemonkey.org.uk/junk/DSC00349.JPG
> Same dead userspace.

So does that.

> Off to find a serial cable.

Try reverting debug-shared-irqs.patch, or disable the sound driver?

Re: 2.6.17-rc5-mm3

[Dave Jones]

On Mon, Jun 05, 2006 at 01:06:26PM -0700, Andrew Morton wrote:

 > > Then, the whole thing locked up after probing the parallel port.
 > > I disabled it in the BIOS, and then it locked up probing the floppy drive..
 > > http://www.codemonkey.org.uk/junk/DSC00348.JPG
 > 
 > That looks like the same thing?
 > 
 > > System is still alive, and responds to keyboard, but makes no forward progress.
 > > 
 > > (sysrq-B spewed a lockdep trace and then rebooted. I'll try and get
 > > that hooked up to a serial console)
 > > 
 > > On a whim, I enabled the floppy drive in the BIOS, and rebooted.
 > > That got me here. http://www.codemonkey.org.uk/junk/DSC00349.JPG
 > > Same dead userspace.
 > 
 > So does that.

The top half the screen is the same as the first pic yes, but the purpose
of those latter two pics was to show that we're locking up (in aparently
different places) shortly afterwards.

 > Try reverting debug-shared-irqs.patch, or disable the sound driver?

Will turn off the sound driver, and see what happens.

		Dave

-- 
http://www.codemonkey.org.uk

Re: 2.6.17-rc5-mm3

[Dave Jones]

On Mon, Jun 05, 2006 at 04:09:47PM -0400, Dave Jones wrote:

 >  > Try reverting debug-shared-irqs.patch, or disable the sound driver?
 > Will turn off the sound driver, and see what happens.

Win! It now boots.   I blew it up really easy with a socket-fuzzer though.
(http://people.redhat.com/davej/sfuzz.c)

[  874.865028] ======================================
[  874.943738] [ BUG: bad unlock ordering detected! ]
[  875.002919] --------------------------------------
[  875.062134] sfuzz/23915 is trying to release lock (&sctp_port_alloc_lock) at:
[  875.149619]  [<d128ed4e>] sctp_get_port_local+0xd0/0x285 [sctp]
[  875.222636] but the next lock to release is:
[  875.276019]  (&sctp_port_hashtable[i].lock){-...}, at: [<d128ed0e>] sctp_get_port_local+0x90/0x285 [sctp]
[  875.393031]
[  875.393032] other info that might help us debug this:
[  875.476583] 1 locks held by sfuzz/23915:
[  875.526247]  #0:  (&sctp_port_alloc_lock){-...}, at: [<d128ecd9>] sctp_get_port_local+0x5b/0x285 [sctp]
[  875.641621]
[  875.641623] stack backtrace:
[  875.699891]  [<c0104966>] show_trace_log_lvl+0x54/0xfd
[  875.764425]  [<c0104f1a>] show_trace+0xd/0x10
[  875.819622]  [<c010502f>] dump_stack+0x19/0x1b
[  875.875924]  [<c013b4af>] lockdep_release+0x150/0x2d1
[  875.939610]  [<c032341e>] _spin_unlock+0x16/0x20
[  875.998171]  [<d128ed4e>] sctp_get_port_local+0xd0/0x285 [sctp]
[  876.072345]  [<d128efd4>] sctp_do_bind+0x9a/0x158 [sctp]
[  876.139315]  [<d128f0ce>] sctp_autobind+0x3c/0x44 [sctp]
[  876.206310]  [<d129253d>] sctp_inet_listen+0xe9/0x139 [sctp]
[  876.277539]  [<c02c20af>] sys_listen+0x4a/0x65
[  876.334730]  [<c02c308d>] sys_socketcall+0x98/0x186
[  876.397175]  [<c03239cb>] syscall_call+0x7/0xb


-- 
http://www.codemonkey.org.uk

Re: 2.6.17-rc5-mm3

[Andrew Morton]

On Mon, 5 Jun 2006 16:44:56 -0400
Dave Jones <davej@redhat.com> wrote:

> On Mon, Jun 05, 2006 at 04:09:47PM -0400, Dave Jones wrote:
> 
>  >  > Try reverting debug-shared-irqs.patch, or disable the sound driver?
>  > Will turn off the sound driver, and see what happens.
> 
> Win! It now boots.

So does Windows 95.

>   I blew it up really easy with a socket-fuzzer though.
> (http://people.redhat.com/davej/sfuzz.c)

But it kept running OK, yes?

> [  874.865028] ======================================
> [  874.943738] [ BUG: bad unlock ordering detected! ]
> [  875.002919] --------------------------------------
> [  875.062134] sfuzz/23915 is trying to release lock (&sctp_port_alloc_lock) at:
> [  875.149619]  [<d128ed4e>] sctp_get_port_local+0xd0/0x285 [sctp]
> [  875.222636] but the next lock to release is:
> [  875.276019]  (&sctp_port_hashtable[i].lock){-...}, at: [<d128ed0e>] sctp_get_port_local+0x90/0x285 [sctp]
> [  875.393031]
> [  875.393032] other info that might help us debug this:
> [  875.476583] 1 locks held by sfuzz/23915:
> [  875.526247]  #0:  (&sctp_port_alloc_lock){-...}, at: [<d128ecd9>] sctp_get_port_local+0x5b/0x285 [sctp]
> [  875.641621]
> [  875.641623] stack backtrace:
> [  875.699891]  [<c0104966>] show_trace_log_lvl+0x54/0xfd
> [  875.764425]  [<c0104f1a>] show_trace+0xd/0x10
> [  875.819622]  [<c010502f>] dump_stack+0x19/0x1b
> [  875.875924]  [<c013b4af>] lockdep_release+0x150/0x2d1
> [  875.939610]  [<c032341e>] _spin_unlock+0x16/0x20
> [  875.998171]  [<d128ed4e>] sctp_get_port_local+0xd0/0x285 [sctp]
> [  876.072345]  [<d128efd4>] sctp_do_bind+0x9a/0x158 [sctp]
> [  876.139315]  [<d128f0ce>] sctp_autobind+0x3c/0x44 [sctp]
> [  876.206310]  [<d129253d>] sctp_inet_listen+0xe9/0x139 [sctp]
> [  876.277539]  [<c02c20af>] sys_listen+0x4a/0x65
> [  876.334730]  [<c02c308d>] sys_socketcall+0x98/0x186
> [  876.397175]  [<c03239cb>] syscall_call+0x7/0xb

This is a really really fussy "BUG", IMO.  So we undid the locks in an
inappropriate order - big deal.

But often these _are_ things which we should tune up, as an efficiency
thing, so it is interesting to hear about them.  But calling it a "BUG" is
a bit alarmist.

Thanks for booting it.

Re: 2.6.17-rc5-mm3

[Dave Jones]

On Mon, Jun 05, 2006 at 01:53:54PM -0700, Andrew Morton wrote:
 
 > >  >  > Try reverting debug-shared-irqs.patch, or disable the sound driver?
 > >  > Will turn off the sound driver, and see what happens.
 > > Win! It now boots.
 > So does Windows 95.

Hey, it's my turn to play "optimist" today. :)

 > >   I blew it up really easy with a socket-fuzzer though.
 > > (http://people.redhat.com/davej/sfuzz.c)
 > 
 > But it kept running OK, yes?

Yep, still ticking along (for now).

 > > [  874.865028] ======================================
 > > [  874.943738] [ BUG: bad unlock ordering detected! ]
 > > [  875.002919] --------------------------------------
 > > [  875.062134] sfuzz/23915 is trying to release lock (&sctp_port_alloc_lock) at:
 > > [  875.149619]  [<d128ed4e>] sctp_get_port_local+0xd0/0x285 [sctp]
 > > [  875.222636] but the next lock to release is:
 > > [  875.276019]  (&sctp_port_hashtable[i].lock){-...}, at: [<d128ed0e>] sctp_get_port_local+0x90/0x285 [sctp]
 > > [  875.393031]
 > > [  875.393032] other info that might help us debug this:
 > > [  875.476583] 1 locks held by sfuzz/23915:
 > > [  875.526247]  #0:  (&sctp_port_alloc_lock){-...}, at: [<d128ecd9>] sctp_get_port_local+0x5b/0x285 [sctp]
 > > [  875.641621]
 > > [  875.641623] stack backtrace:
 > > [  875.699891]  [<c0104966>] show_trace_log_lvl+0x54/0xfd
 > > [  875.764425]  [<c0104f1a>] show_trace+0xd/0x10
 > > [  875.819622]  [<c010502f>] dump_stack+0x19/0x1b
 > > [  875.875924]  [<c013b4af>] lockdep_release+0x150/0x2d1
 > > [  875.939610]  [<c032341e>] _spin_unlock+0x16/0x20
 > > [  875.998171]  [<d128ed4e>] sctp_get_port_local+0xd0/0x285 [sctp]
 > > [  876.072345]  [<d128efd4>] sctp_do_bind+0x9a/0x158 [sctp]
 > > [  876.139315]  [<d128f0ce>] sctp_autobind+0x3c/0x44 [sctp]
 > > [  876.206310]  [<d129253d>] sctp_inet_listen+0xe9/0x139 [sctp]
 > > [  876.277539]  [<c02c20af>] sys_listen+0x4a/0x65
 > > [  876.334730]  [<c02c308d>] sys_socketcall+0x98/0x186
 > > [  876.397175]  [<c03239cb>] syscall_call+0x7/0xb
 > 
 > This is a really really fussy "BUG", IMO.  So we undid the locks in an
 > inappropriate order - big deal.
 > 
 > But often these _are_ things which we should tune up, as an efficiency
 > thing, so it is interesting to hear about them.  But calling it a "BUG" is
 > a bit alarmist.

Maybe so, but it's still pretty grotty though.

		Dave

-- 
http://www.codemonkey.org.uk

Re: 2.6.17-rc5-mm3

[Arjan van de Ven]

On Mon, 2006-06-05 at 16:44 -0400, Dave Jones wrote:
> On Mon, Jun 05, 2006 at 04:09:47PM -0400, Dave Jones wrote:
> 
>  >  > Try reverting debug-shared-irqs.patch, or disable the sound driver?
>  > Will turn off the sound driver, and see what happens.
> 
> Win! It now boots.   I blew it up really easy with a socket-fuzzer though.
> (http://people.redhat.com/davej/sfuzz.c)
> 
> [  874.865028] ======================================
> [  874.943738] [ BUG: bad unlock ordering detected! ]
> [  875.002919] --------------------------------------
> [  875.062134] sfuzz/23915 is trying to release lock (&sctp_port_alloc_lock) at:
> [  875.149619]  [<d128ed4e>] sctp_get_port_local+0xd0/0x285 [sctp]
> [  875.222636] but the next lock to release is:
> [  875.276019]  (&sctp_port_hashtable[i].lock){-...}, at: [<d128ed0e>] sctp_get_port_local+0x90/0x285 [sctp]
> [  875.393031]

this is "interesting" code to follow but it looks like a honest case of
deliberate out of order unlock

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>

---
 net/sctp/socket.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.17-rc5-mm3/net/sctp/socket.c
===================================================================
--- linux-2.6.17-rc5-mm3.orig/net/sctp/socket.c
+++ linux-2.6.17-rc5-mm3/net/sctp/socket.c
@@ -4597,7 +4597,7 @@ static long sctp_get_port_local(struct s
 			sctp_spin_unlock(&head->lock);
 		} while (--remaining > 0);
 		sctp_port_rover = rover;
-		sctp_spin_unlock(&sctp_port_alloc_lock);
+		spin_unlock_non_nested(&sctp_port_alloc_lock);
 
 		/* Exhausted local port range during search? */
 		ret = 1;

Re: 2.6.17-rc5-mm3

[Takashi Iwai]

At Mon, 5 Jun 2006 13:06:26 -0700,
Andrew Morton wrote:
> 
> On Mon, 5 Jun 2006 15:48:45 -0400
> Dave Jones <davej@redhat.com> wrote:
> 
> > On Sat, Jun 03, 2006 at 11:20:04PM -0700, Andrew Morton wrote:
> >  > 
> >  > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm3/
> >  > 
> >  > - Lots of PCI and USB updates
> >  > 
> >  > - The various lock validator, stack backtracing and IRQ management problems
> >  >   are converging, but we're not quite there yet.
> > 
> > Thought I'd try my bi-annual "poke at -mm". Results were less
> > than spectacular.
> > 
> > http://www.codemonkey.org.uk/junk/DSC00347.JPG
> > First the sound driver oopsed.
> 
> That's a bug in sound/pci/cs4281.c.
> 
> There's a debug patch in -mm
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm3/broken-out/debug-shared-irqs.patch
> which trips up drivers which request an IRQ before their IRQ handler is
> ready to accept IRQs (they'll crash in real life if the IRQ is shared).

I guess that the bug in cs4281 is ioremap too lately issued after the
registration of irq handler.

Does the patch below fix the problem?

Takashi


[PATCH] Fix possible Oops in cs4281 irq handler

Call ioremap before request_irq for avoiding possible Oops
in cs4281 driver.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
diff -r 84d14cbbd713 sound/pci/cs4281.c
--- a/sound/pci/cs4281.c	Fri Jun 02 09:15:44 2006 +0200
+++ b/sound/pci/cs4281.c	Tue Jun 06 12:11:56 2006 +0200
@@ -1379,6 +1379,13 @@ static int __devinit snd_cs4281_create(s
 	chip->ba0_addr = pci_resource_start(pci, 0);
 	chip->ba1_addr = pci_resource_start(pci, 1);
 
+	chip->ba0 = ioremap_nocache(chip->ba0_addr, pci_resource_len(pci, 0));
+	chip->ba1 = ioremap_nocache(chip->ba1_addr, pci_resource_len(pci, 1));
+	if (!chip->ba0 || !chip->ba1) {
+		snd_cs4281_free(chip);
+		return -ENOMEM;
+	}
+	
 	if (request_irq(pci->irq, snd_cs4281_interrupt, SA_INTERRUPT|SA_SHIRQ,
 			"CS4281", chip)) {
 		snd_printk(KERN_ERR "unable to grab IRQ %d\n", pci->irq);
@@ -1387,13 +1394,6 @@ static int __devinit snd_cs4281_create(s
 	}
 	chip->irq = pci->irq;
 
-	chip->ba0 = ioremap_nocache(chip->ba0_addr, pci_resource_len(pci, 0));
-	chip->ba1 = ioremap_nocache(chip->ba1_addr, pci_resource_len(pci, 1));
-	if (!chip->ba0 || !chip->ba1) {
-		snd_cs4281_free(chip);
-		return -ENOMEM;
-	}
-	
 	tmp = snd_cs4281_chip_init(chip);
 	if (tmp) {
 		snd_cs4281_free(chip);

Re: 2.6.17-rc5-mm3

[Dave Jones]

On Sat, Jun 03, 2006 at 11:20:04PM -0700, Andrew Morton wrote:
 > 
 > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm3/

WARNING: /lib/modules/2.6.17-rc5-mm3/kernel/drivers/char/pcmcia/synclink_cs.ko needs unknown symbol alloc_hdlcdev
WARNING: /lib/modules/2.6.17-rc5-mm3/kernel/drivers/char/pcmcia/synclink_cs.ko needs unknown symbol hdlc_close
WARNING: /lib/modules/2.6.17-rc5-mm3/kernel/drivers/char/pcmcia/synclink_cs.ko needs unknown symbol hdlc_set_carrier
WARNING: /lib/modules/2.6.17-rc5-mm3/kernel/drivers/char/pcmcia/synclink_cs.ko needs unknown symbol register_hdlc_device
WARNING: /lib/modules/2.6.17-rc5-mm3/kernel/drivers/char/pcmcia/synclink_cs.ko needs unknown symbol hdlc_open
WARNING: /lib/modules/2.6.17-rc5-mm3/kernel/drivers/char/pcmcia/synclink_cs.ko needs unknown symbol hdlc_ioctl
WARNING: /lib/modules/2.6.17-rc5-mm3/kernel/drivers/char/pcmcia/synclink_cs.ko needs unknown symbol unregister_hdlc_device

(19:02:21:root@northwood:mm3)# grep SYNCLINK .config
CONFIG_SYNCLINK_CS=m
CONFIG_SYNCLINK_CS_HDLC=y
(19:02:25:root@northwood:mm3)# grep HDLC .config
CONFIG_HDLC=m
# CONFIG_HDLC_RAW is not set
# CONFIG_HDLC_RAW_ETH is not set
# CONFIG_HDLC_CISCO is not set
# CONFIG_HDLC_FR is not set
# CONFIG_HDLC_PPP is not set
CONFIG_HISAX_HDLC=y
CONFIG_SYNCLINK_CS_HDLC=y


		Dave

-- 
http://www.codemonkey.org.uk

Re: 2.6.17-rc5-mm3

[Randy.Dunlap]

On Mon, 5 Jun 2006 19:02:48 -0400 Dave Jones wrote:

> On Sat, Jun 03, 2006 at 11:20:04PM -0700, Andrew Morton wrote:
>  > 
>  > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm3/
> 
> WARNING: /lib/modules/2.6.17-rc5-mm3/kernel/drivers/char/pcmcia/synclink_cs.ko needs unknown symbol alloc_hdlcdev
> WARNING: /lib/modules/2.6.17-rc5-mm3/kernel/drivers/char/pcmcia/synclink_cs.ko needs unknown symbol hdlc_close
> WARNING: /lib/modules/2.6.17-rc5-mm3/kernel/drivers/char/pcmcia/synclink_cs.ko needs unknown symbol hdlc_set_carrier
> WARNING: /lib/modules/2.6.17-rc5-mm3/kernel/drivers/char/pcmcia/synclink_cs.ko needs unknown symbol register_hdlc_device
> WARNING: /lib/modules/2.6.17-rc5-mm3/kernel/drivers/char/pcmcia/synclink_cs.ko needs unknown symbol hdlc_open
> WARNING: /lib/modules/2.6.17-rc5-mm3/kernel/drivers/char/pcmcia/synclink_cs.ko needs unknown symbol hdlc_ioctl
> WARNING: /lib/modules/2.6.17-rc5-mm3/kernel/drivers/char/pcmcia/synclink_cs.ko needs unknown symbol unregister_hdlc_device
> 
> (19:02:21:root@northwood:mm3)# grep SYNCLINK .config
> CONFIG_SYNCLINK_CS=m
> CONFIG_SYNCLINK_CS_HDLC=y
> (19:02:25:root@northwood:mm3)# grep HDLC .config
> CONFIG_HDLC=m
> # CONFIG_HDLC_RAW is not set
> # CONFIG_HDLC_RAW_ETH is not set
> # CONFIG_HDLC_CISCO is not set
> # CONFIG_HDLC_FR is not set
> # CONFIG_HDLC_PPP is not set
> CONFIG_HISAX_HDLC=y
> CONFIG_SYNCLINK_CS_HDLC=y

Those Kconfig + Makefiles are quite ugly to me.  I would rather see
SYNCLINK depend on HDLC rather than using some tricks to SELECT HDLC.
And then it selects HDLC (and HDLC depends on WAN), but (in my case)
WAN was not enabled, and doing "SELECT HDLC" did not enable WAN.

Adding SELECT WAN and changing the hdlc (wan) Makefile to use
obj-m or obj-y (it was ONLY obj-y for hdlc) fixes^W makes it build
with no missing symbols.  However, I'll also see about a fix
that uses "depends on HDLC" instead of "selects HDLC".

---
From: Randy Dunlap <rdunlap@xenotime.net>

Fix many missing hdlc_generic symbols when CONFIG_HDLC=m.
When Selecting HDLC, also Select WAN.
Fix Makefile to build for HDLC=y or HDLC=m.

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
 drivers/char/Kconfig     |    3 +++
 drivers/net/wan/Makefile |    8 ++++++--
 2 files changed, 9 insertions(+), 2 deletions(-)

--- linux-2617-rc5mm3.orig/drivers/net/wan/Makefile
+++ linux-2617-rc5mm3/drivers/net/wan/Makefile
@@ -9,14 +9,18 @@ cyclomx-y                       := cycx_
 cyclomx-$(CONFIG_CYCLOMX_X25)	+= cycx_x25.o
 cyclomx-objs			:= $(cyclomx-y)  
 
-hdlc-y				:= hdlc_generic.o
+hdlc-$(CONFIG_HDLC)		:= hdlc_generic.o
 hdlc-$(CONFIG_HDLC_RAW)		+= hdlc_raw.o
 hdlc-$(CONFIG_HDLC_RAW_ETH)	+= hdlc_raw_eth.o
 hdlc-$(CONFIG_HDLC_CISCO)	+= hdlc_cisco.o
 hdlc-$(CONFIG_HDLC_FR)		+= hdlc_fr.o
 hdlc-$(CONFIG_HDLC_PPP)		+= hdlc_ppp.o
 hdlc-$(CONFIG_HDLC_X25)		+= hdlc_x25.o
-hdlc-objs			:= $(hdlc-y)
+ifeq ($(CONFIG_HDLC),y)
+  hdlc-objs			:= $(hdlc-y)
+else
+  hdlc-objs			:= $(hdlc-m)
+endif
 
 pc300-y				:= pc300_drv.o
 pc300-$(CONFIG_PC300_MLPPP)	+= pc300_tty.o
--- linux-2617-rc5mm3.orig/drivers/char/Kconfig
+++ linux-2617-rc5mm3/drivers/char/Kconfig
@@ -197,6 +197,7 @@ config ISI
 config SYNCLINK
 	tristate "SyncLink PCI/ISA support"
 	depends on SERIAL_NONSTANDARD && PCI && ISA_DMA_API
+	select WAN if SYNCLINK_HDLC
 	select HDLC if SYNCLINK_HDLC
 	help
 	  Driver for SyncLink ISA and PCI synchronous serial adapters.
@@ -214,6 +215,7 @@ config SYNCLINK_HDLC
 config SYNCLINKMP
 	tristate "SyncLink Multiport support"
 	depends on SERIAL_NONSTANDARD && PCI
+	select WAN if SYNCLINKMP_HDLC
 	select HDLC if SYNCLINKMP_HDLC
 	help
 	  Driver for SyncLink Multiport (2 or 4 ports) PCI synchronous serial adapter.
@@ -231,6 +233,7 @@ config SYNCLINKMP_HDLC
 config SYNCLINK_GT
 	tristate "SyncLink GT/AC support"
 	depends on SERIAL_NONSTANDARD && PCI
+	select WAN if SYNCLINK_GT_HDLC
 	select HDLC if SYNCLINK_GT_HDLC
 	help
 	  Support for SyncLink GT and SyncLink AC families of

Re: 2.6.17-rc5-mm3

[Paul Fulghum]

Randy.Dunlap wrote:
> Those Kconfig + Makefiles are quite ugly to me.  I would rather see
> SYNCLINK depend on HDLC rather than using some tricks to SELECT HDLC.
> And then it selects HDLC (and HDLC depends on WAN), but (in my case)
> WAN was not enabled, and doing "SELECT HDLC" did not enable WAN.
> 
> Adding SELECT WAN and changing the hdlc (wan) Makefile to use
> obj-m or obj-y (it was ONLY obj-y for hdlc) fixes^W makes it build
> with no missing symbols.  However, I'll also see about a fix
> that uses "depends on HDLC" instead of "selects HDLC".

Generic HDLC support in the synclink drivers is optional.
Should the generic HDLC code be enabled even if it is not used?

Some of our customers would scream if we started forcing
them to compile and load unused code.

> Fix many missing hdlc_generic symbols when CONFIG_HDLC=m.
> When Selecting HDLC, also Select WAN.
> Fix Makefile to build for HDLC=y or HDLC=m.
> 
> +	select WAN if SYNCLINK_HDLC

If this is the accepted approach, then synclink_cs should be added also.
(drivers/char/pcmcia)

What about select WAN if HDLC instead?
Or does kbuild not propogate the reverse dependency?
(SYNCLINK_HDLC selects HDLC, HDLC selects WAN)

--
Paul

Re: 2.6.17-rc5-mm3

[Randy.Dunlap]

On Mon, 05 Jun 2006 20:54:51 -0500 Paul Fulghum wrote:

> Randy.Dunlap wrote:
> > Those Kconfig + Makefiles are quite ugly to me.  I would rather see
> > SYNCLINK depend on HDLC rather than using some tricks to SELECT HDLC.
> > And then it selects HDLC (and HDLC depends on WAN), but (in my case)
> > WAN was not enabled, and doing "SELECT HDLC" did not enable WAN.
> > 
> > Adding SELECT WAN and changing the hdlc (wan) Makefile to use
> > obj-m or obj-y (it was ONLY obj-y for hdlc) fixes^W makes it build
> > with no missing symbols.  However, I'll also see about a fix
> > that uses "depends on HDLC" instead of "selects HDLC".
> 
> Generic HDLC support in the synclink drivers is optional.
> Should the generic HDLC code be enabled even if it is not used?
> 
> Some of our customers would scream if we started forcing
> them to compile and load unused code.

OK, I'll try to allow for that.

> > Fix many missing hdlc_generic symbols when CONFIG_HDLC=m.
> > When Selecting HDLC, also Select WAN.
> > Fix Makefile to build for HDLC=y or HDLC=m.
> > 
> > +	select WAN if SYNCLINK_HDLC
> 
> If this is the accepted approach, then synclink_cs should be added also.
> (drivers/char/pcmcia)

It's not the desired approach AFAIK, but it may be the only
reasonable one.  I'm still testing alternatives, but you are welcome
to take over and fix it.  :)

> What about select WAN if HDLC instead?
> Or does kbuild not propogate the reverse dependency?
> (SYNCLINK_HDLC selects HDLC, HDLC selects WAN)

OK.

---
~Randy

Re: 2.6.17-rc5-mm3

[Randy.Dunlap]

On Mon, 5 Jun 2006 19:03:55 -0700 Randy.Dunlap wrote:

> On Mon, 05 Jun 2006 20:54:51 -0500 Paul Fulghum wrote:
> 
> > Randy.Dunlap wrote:
> > > Those Kconfig + Makefiles are quite ugly to me.  I would rather see
> > > SYNCLINK depend on HDLC rather than using some tricks to SELECT HDLC.
> > > And then it selects HDLC (and HDLC depends on WAN), but (in my case)
> > > WAN was not enabled, and doing "SELECT HDLC" did not enable WAN.
> > > 
> > > Adding SELECT WAN and changing the hdlc (wan) Makefile to use
> > > obj-m or obj-y (it was ONLY obj-y for hdlc) fixes^W makes it build
> > > with no missing symbols.  However, I'll also see about a fix
> > > that uses "depends on HDLC" instead of "selects HDLC".
> > 
> > Generic HDLC support in the synclink drivers is optional.
> > Should the generic HDLC code be enabled even if it is not used?
> > 
> > Some of our customers would scream if we started forcing
> > them to compile and load unused code.
> 
> OK, I'll try to allow for that.
> 
> > > Fix many missing hdlc_generic symbols when CONFIG_HDLC=m.
> > > When Selecting HDLC, also Select WAN.
> > > Fix Makefile to build for HDLC=y or HDLC=m.
> > > 
> > > +	select WAN if SYNCLINK_HDLC
> > 
> > If this is the accepted approach, then synclink_cs should be added also.
> > (drivers/char/pcmcia)
> 
> It's not the desired approach AFAIK, but it may be the only
> reasonable one.  I'm still testing alternatives, but you are welcome
> to take over and fix it.  :)
> 
> > What about select WAN if HDLC instead?
> > Or does kbuild not propogate the reverse dependency?
> > (SYNCLINK_HDLC selects HDLC, HDLC selects WAN)
> 
> OK.

Hi Paul,
Here's another version of the patch for you to consider.
---

From: Randy Dunlap <rdunlap@xenotime.net>

Fix missing symbol references to hdlc_generic functions.
Switch SYNCLINK drivers from using SELECT to using DEPENDS for HDLC.

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
 drivers/char/Kconfig        |    9 +++------
 drivers/char/pcmcia/Kconfig |    3 +--
 drivers/net/wan/Makefile    |    8 ++++++--
 3 files changed, 10 insertions(+), 10 deletions(-)

--- linux-2617-rc5mm3.orig/drivers/char/Kconfig
+++ linux-2617-rc5mm3/drivers/char/Kconfig
@@ -197,7 +197,6 @@ config ISI
 config SYNCLINK
 	tristate "SyncLink PCI/ISA support"
 	depends on SERIAL_NONSTANDARD && PCI && ISA_DMA_API
-	select HDLC if SYNCLINK_HDLC
 	help
 	  Driver for SyncLink ISA and PCI synchronous serial adapters.
 	  These adapters are no longer in production and have
@@ -205,7 +204,7 @@ config SYNCLINK
 
 config SYNCLINK_HDLC
 	bool "Generic HDLC support for SyncLink driver"
-	depends on SYNCLINK
+	depends on SYNCLINK && HDLC
 	help
 	  Enable generic HDLC support for the SyncLink PCI/ISA driver.
 	  Generic HDLC implements multiple higher layer networking
@@ -214,7 +213,6 @@ config SYNCLINK_HDLC
 config SYNCLINKMP
 	tristate "SyncLink Multiport support"
 	depends on SERIAL_NONSTANDARD && PCI
-	select HDLC if SYNCLINKMP_HDLC
 	help
 	  Driver for SyncLink Multiport (2 or 4 ports) PCI synchronous serial adapter.
 	  These adapters are no longer in production and have
@@ -222,7 +220,7 @@ config SYNCLINKMP
 
 config SYNCLINKMP_HDLC
 	bool "Generic HDLC support for SyncLink Multiport"
-	depends on SYNCLINKMP
+	depends on SYNCLINKMP && HDLC
 	help
 	  Enable generic HDLC support for the SyncLink Multiport driver.
 	  Generic HDLC implements multiple higher layer networking
@@ -231,7 +229,6 @@ config SYNCLINKMP_HDLC
 config SYNCLINK_GT
 	tristate "SyncLink GT/AC support"
 	depends on SERIAL_NONSTANDARD && PCI
-	select HDLC if SYNCLINK_GT_HDLC
 	help
 	  Support for SyncLink GT and SyncLink AC families of
 	  synchronous and asynchronous serial adapters
@@ -239,7 +236,7 @@ config SYNCLINK_GT
 
 config SYNCLINK_GT_HDLC
 	bool "Generic HDLC support for SyncLink GT/AC"
-	depends on SYNCLINK_GT
+	depends on SYNCLINK_GT && HDLC
 	help
 	  Enable generic HDLC support for the SyncLink GT/AC driver.
 	  Generic HDLC implements multiple higher layer networking
--- linux-2617-rc5mm3.orig/drivers/char/pcmcia/Kconfig
+++ linux-2617-rc5mm3/drivers/char/pcmcia/Kconfig
@@ -8,13 +8,12 @@ menu "PCMCIA character devices"
 config SYNCLINK_CS
 	tristate "SyncLink PC Card support"
 	depends on PCMCIA
-	select HDLC if SYNCLINK_CS_HDLC
 	help
 	  Driver for SyncLink PC Card synchronous serial adapter.
 
 config SYNCLINK_CS_HDLC
 	bool "Generic HDLC support for SyncLink Multiport"
-	depends on SYNCLINK_CS
+	depends on SYNCLINK_CS && HDLC
 	help
 	  Enable generic HDLC support for the SyncLink PC Card driver.
 	  Generic HDLC implements multiple higher layer networking
--- linux-2617-rc5mm3.orig/drivers/net/wan/Makefile
+++ linux-2617-rc5mm3/drivers/net/wan/Makefile
@@ -9,14 +9,18 @@ cyclomx-y                       := cycx_
 cyclomx-$(CONFIG_CYCLOMX_X25)	+= cycx_x25.o
 cyclomx-objs			:= $(cyclomx-y)  
 
-hdlc-y				:= hdlc_generic.o
+hdlc-$(CONFIG_HDLC)		:= hdlc_generic.o
 hdlc-$(CONFIG_HDLC_RAW)		+= hdlc_raw.o
 hdlc-$(CONFIG_HDLC_RAW_ETH)	+= hdlc_raw_eth.o
 hdlc-$(CONFIG_HDLC_CISCO)	+= hdlc_cisco.o
 hdlc-$(CONFIG_HDLC_FR)		+= hdlc_fr.o
 hdlc-$(CONFIG_HDLC_PPP)		+= hdlc_ppp.o
 hdlc-$(CONFIG_HDLC_X25)		+= hdlc_x25.o
-hdlc-objs			:= $(hdlc-y)
+ifeq ($(CONFIG_HDLC),y)
+  hdlc-objs			:= $(hdlc-y)
+else
+  hdlc-objs			:= $(hdlc-m)
+endif
 
 pc300-y				:= pc300_drv.o
 pc300-$(CONFIG_PC300_MLPPP)	+= pc300_tty.o

Re: 2.6.17-rc5-mm3

[Paul Fulghum]

Randy.Dunlap wrote:
> On Mon, 5 Jun 2006 19:03:55 -0700 Randy.Dunlap wrote:
> Here's another version of the patch for you to consider.

This looks like the correct implementation of what I was trying (unsuccessfully)
to do when the random config errors were first reported.

I'll do testing tomorrow to make sure I understand this completely.

Thanks,
Paul

Re: 2.6.17-rc5-mm3

[Paul Fulghum]

Randy.Dunlap wrote:
> Here's another version of the patch for you to consider.
> ---
> --- linux-2617-rc5mm3.orig/drivers/char/Kconfig
> +++ linux-2617-rc5mm3/drivers/char/Kconfig
> @@ -197,7 +197,6 @@ config ISI
>  config SYNCLINK
>  	tristate "SyncLink PCI/ISA support"
>  	depends on SERIAL_NONSTANDARD && PCI && ISA_DMA_API
> -	select HDLC if SYNCLINK_HDLC
>  	help
>  	  Driver for SyncLink ISA and PCI synchronous serial adapters.
>  	  These adapters are no longer in production and have
> @@ -205,7 +204,7 @@ config SYNCLINK
>  
>  config SYNCLINK_HDLC
>  	bool "Generic HDLC support for SyncLink driver"
> -	depends on SYNCLINK
> +	depends on SYNCLINK && HDLC
>  	help
>  	  Enable generic HDLC support for the SyncLink PCI/ISA driver.
>  	  Generic HDLC implements multiple higher layer networking

Now I remember that this was tried before and does
not work because SYNCLINK_HDLC is a bool and will
force the HDLC module to 'y' even if the synclink
driver is a 'm' which results in build errors.

I also tried 'depends on HDLC if SYNCLINK_HDLC'
in the config SYNCLINK section, but that causes a
cyclic dependency error. I suppose I could do that if I
remove 'depends on SYNCLINK' from config SYNCLINK_HDLC.
The only down side of that is the way the
SYNCLINK_HDLC option would be displayed.

I'll review this again to find the best solution.

-- 
Paul Fulghum
Microgate Systems, Ltd.

Re: 2.6.17-rc5-mm3

[J.A. Magallón]

On Sat, 3 Jun 2006 23:20:04 -0700, Andrew Morton <akpm@osdl.org> wrote:

> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm3/
> 
> - Lots of PCI and USB updates
> 
> - The various lock validator, stack backtracing and IRQ management problems
>   are converging, but we're not quite there yet.
> 

One more, could not find it already reported (if yes, sorry for the noise).
It is not in lockdep-combo as 20060606.

ide-floppy driver 0.99.newide
stopped custom tracer.
BUG: warning at kernel/lockdep.c:1856/trace_hardirqs_on()
 [<c01034ba>] show_trace+0x12/0x14
 [<c0103b8d>] dump_stack+0x19/0x1b
 [<c0133c56>] trace_hardirqs_on+0x14d/0x152
 [<f88bcaa9>] idefloppy_pc_intr+0x192/0x6ca [ide_floppy]
 [<f89402e2>] ide_intr+0x74/0x1c7 [ide_core]
 [<c013d212>] handle_IRQ_event+0x2e/0x63
 [<c013e451>] handle_edge_irq+0xad/0x132
 [<c0104dc7>] do_IRQ+0x6c/0xa5
 =======================
 [<c0102ec1>] common_interrupt+0x25/0x2c
 [<c0103029>] error_code+0x39/0x40
hdb: No disk in drive
hdb: 244736kB, 239/64/32 CHS, 4096 kBps, 512 sector size, 2941 rpm
hdb: No disk in drive

--
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.16-jam19 (gcc 4.1.1 20060518 (prerelease)) #1 SMP PREEMPT Tue