kernel OOPS in 2.3.2 on USB device reattach

William Ono (wmono@home.com)
Sun, 16 May 1999 21:53:10 -0700 (PDT)


This is my first Oops report, so please let me know if there's anything I
can improve on for next time.

I'm running the stock kernel 2.3.2. USB is compiled in the kernel, not as
a module. I've been following linux-kernel for the past few days and have
seen nothing about this problem. When I attached my USB keyboard, removed
it, then re-attached it, I got a kernel Oops.

My hardware: PIIX4-driven USB, UHCI, on-board a Asus P2B motherboard,
with two ports on the root hub. My USB keyboard is from my iMac, model
M2452, which is also a two-port hub. My USB mouse is also from my iMac,
model M4848. My USB joystick is a Microsoft SideWinder Precision Pro.

I rebooted and gave "linux init=/bin/sh" to LILO before continuing these
tests. I have been able to generate Oops on the following actions:

* attach keyboard to root, attach mouse to keyboard, remove mouse, attach
mouse to keyboard (either port). Panic.

* attach keyboard to root, remove keyboard, reattach keyboard to root
(either port). Panic.

* attach mouse to root, remove mouse, reattach mouse to root (either
port). Panic.

* attach keyboard to root, remove keyboard, attach mouse to root (either
port). Panic.

* attach keyboard and mouse to root, remove keyboard and mouse, attach
joystick. Panic.

But I have -not- been able to generate an Oops on this action:

* attach joystick to root, remove joystick, reattach joystick to root. No
loss of functionality to the system.

The messages I see on boot that are somewhat related to USB are:

USB HID boot protocol mouse registered.
USB ACM registered.
...
usb_hub_thread at c01b7400
uhci_control_thread at c01b9a14
Uniform Multi-Platform E-IDE driver Revision: 6.19
PIIX4: IDE controller on PCI bus 00 dev 21
PIIX4: not 100% native mode: will probe irqs later

The remainder of this mail is the output from ksymoops. Due to the nature
of kernel Oops, I wrote out the Oops on paper and then typed it back in to
be fed to ksymoops. (I checked my syslog and there was nothing there
related to this issue.) This re-typing may have resulted in errors,
though I was sure to triple-check each value. ksymoops was executed under
the same conditions as which caused the Oops; namely, I fed "linux
init=/bin/sh" to LILO again.

Options used: -V (default)
-o /lib/modules/2.3.2/ (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-m /usr/src/linux/System.map (default)
-c 1 (default)

You did not tell me where to find symbol information. I will assume
that the log matches the kernel and modules that are running right now
and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.

No modules in ksyms, skipping objects
Warning, no symbols in lsmod, is /proc/modules a valid lsmod file?
Unable to handle kernel NULL pointer dereference at virtual address 00000004
current->tss.cr3 = 00101000, %cr3 = 00101000
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c01b9576>]
EFLAGS: 00010246
eax: c7fe8130 ebx: c7fe8010 ecx: c7fe8120 edx: 00000001
esi: c7dc0130 edi: c7dc0120 ebp: 00000000 esp: c020b3f8
ds: 0018 es: 0018 ss: 0018
Process swapper (pid:0 process nr: 0, stackpage=c020b00)
Stack: 00000009 c020bf68 c03de2f4 c01b96de c03de230 c03de3a0 04000001 c010aee9
00000009 c03de2e0 c020bf68 c01e92d0 00000000 c03de3a0 c020bf60 c010ac3f
00000009 c020bf68 c03de3a0 00000001 c020a000 000008a5 00000001 c010b00c
Call Trace: [<c01b96de>] [<c010aee9>] [<c010ac3f>] [<c010b00c>] [<c0109e80>] [<c01086a1>] [<c0106000>]
[<c01086c4>] [<c0109dc4>] [<c0106000>] [<c010607b>] [<c0106000>] [<c0100176>]
Code: 89 45 04 89 28 89 36 89 76 04 8b 47 20 50 8b 46 fc

>>EIP: c01b9576 <uhci_interrupt_notify+32/bc>
Trace: c01b96de <uhci_interrupt+32/40>
Trace: c010aee9 <handle_IRQ_event+31/68>
Trace: c010ac3f <do_8259A_IRQ+77/a8>
Trace: c010b00c <do_IRQ+24/40>
Trace: c0109e80 <ret_from_intr+0/20>
Trace: c01086a1 <cpu_idle+5d/6c>
Trace: c0106000 <get_options+0/74>
Trace: c01086c4 <sys_idle+14/24>
Code: c01b9576 <uhci_interrupt_notify+32/bc> 00000000 <_EIP>: <===
Code: c01b9576 <uhci_interrupt_notify+32/bc> 0: 89 45 04 movl %eax,0x4(%ebp) <===
Code: c01b9579 <uhci_interrupt_notify+35/bc> 3: 89 28 movl %ebp,(%eax)
Code: c01b957b <uhci_interrupt_notify+37/bc> 5: 89 36 movl %esi,(%esi)
Code: c01b957d <uhci_interrupt_notify+39/bc> 7: 89 76 04 movl %esi,0x4(%esi)
Code: c01b9580 <uhci_interrupt_notify+3c/bc> a: 8b 47 20 movl 0x20(%edi),%eax
Code: c01b9583 <uhci_interrupt_notify+3f/bc> d: 50 pushl %eax
Code: c01b9584 <uhci_interrupt_notify+40/bc> e: 8b 46 fc movl 0xfffffffc(%esi),%eax

2 warnings issued. Results may not be reliable.

I hope this is of use in finding the problem. If there is anything more I
can do, please let me know.

Thank you for your time.

-- 
William Ono <wmono@home.com>                               PGP key: 0x93BA6AFD
 fingerprint = E3 64 C5 43 3E B3 2D A6  C6 D7 E3 45 90 24 78 DE = fingerprint
PGP-encrypted mail welcome!           "640k ought to be enough for everybody."

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