Dave Jones wrote:

>Oct 25 18:38:12 tetrachloride kernel: Debug: sleeping function called from illegal context at mm/slab.c:1384
>Oct 25 18:38:12 tetrachloride kernel: Call Trace:
>Oct 25 18:38:12 tetrachloride kernel:  [<c011dd94>] __might_sleep+0x54/0x58
>Oct 25 18:38:12 tetrachloride kernel:  [<c01403ae>] kmalloc+0x5a/0x314
>Oct 25 18:38:12 tetrachloride kernel:  [<c017e2da>] proc_create+0x76/0xcc
>Oct 25 18:38:12 tetrachloride kernel:  [<c017e3fb>] proc_mkdir+0x17/0x40
>Oct 25 18:38:12 tetrachloride kernel:  [<c010a4c3>] register_irq_proc+0x6b/0xb0
>Oct 25 18:38:12 tetrachloride kernel:  [<c010a2ba>] setup_irq+0x166/0x174
>Oct 25 18:38:12 tetrachloride kernel:  [<c02b9424>] e100intr+0x0/0x308
>Oct 25 18:38:12 tetrachloride kernel:  [<c0109b48>] request_irq+0x88/0xa4
>Oct 25 18:38:12 tetrachloride kernel:  [<c02b84fa>] e100_open+0x106/0x188
> 
>
Well, it holds bdp->isolate_lock for an incredibly long time, so that 
might trigger this.  At least interrupts aren't disabled.

Another bug:  e100_close doesn't get the lock.


>Another weirdo.. Check out the Speed..
>
>Oct 25 18:38:12 tetrachloride kernel: Intel(R) PRO/100 Network Driver - version 2.1.24-k1
>Oct 25 18:38:12 tetrachloride kernel: Copyright (c) 2002 Intel Corporation
>Oct 25 18:38:12 tetrachloride kernel: 
>Oct 25 18:38:12 tetrachloride kernel: e100: selftest OK.
>Oct 25 18:38:12 tetrachloride kernel: e100: eth0: Intel(R) PRO/100 VE Network Connection
>Oct 25 18:38:12 tetrachloride kernel:   Mem:0xfeafc000  IRQ:20  Speed:0 Mbps  Dx:N/A
>Oct 25 18:38:12 tetrachloride kernel:   Hardware receive checksums enabled
>

Cosmetic or real, that's indeed another bug...

    Jeff




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/