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/
This archive was generated by hypermail 2b29 : Thu Oct 31 2002 - 22:00:31 EST