This problem is reproducible in any 2.4 kernel since 2.4.13. I tracked it
down to the lock by hacking in lots of printk 's. to see exactly where the
Oops occurred..... The call to down() seems to invoke some inline asm code
in include/asm-i386/semaphore.h and I can't go further to see what the
problem was.
I hope someone knowledgeable can help!
In particular, can this be fixed by initializing something in cpia_usb.c
by adding something to the declaration:
static struct usb_driver cpia_driver = {
name: "cpia",
probe: cpia_probe,
disconnect: cpia_disconnect,
id_table: cpia_id_table,
};
Or is it completely a usb.c problem outside my scope as cpia maintainer?
For what its worth, here is a manually transcribed oops console screen:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
Printing eip
c0113e0a
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c0113e0a>] Not tainted
EFLAGS: 00010002
eax: c0342ea8 ebx: 00000000 ecx: c143ff84 edx: c143777c
esi: 00000202 edi: c0105000 ebp: c143ff74 esp: c143ff6c
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 1, stackpage=c143f000 )
Stack: c0324ea0 c143e000 c143ff94 c0105bab 00000001 c143e000 c0324ea8 00000000
c02b77c0 c02e5fbc c143ffa8 c0105d27 c0324ea0 c02df2a0 c02b7710 c143ffb4
c0204b6f c02b77c0 c143ffc0 c02019eb c02fb920 c143ffcc c02f25a7 c02b77c0
Call trace: [<c0105bab>] [<c0105d27>] [<c0204b6f>][c02019eb>][c010503b>]
[<c0105636>] [<c0105000>] [<c0105030>]
Code: 89 0b 56 9d 5b 5e 5d c3 8d b4 26 00 00 00 00 8d bc 27 00 00
<0>Kernel panic: Attempted to kill init!
Thanks
Duncan
-
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/