Bug 86448 - (USB)Kernel oops when booting with USB pen-drive attached
(USB)Kernel oops when booting with USB pen-drive attached
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
9
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-22 00:22 EST by Rob Kearey
Modified: 2007-04-18 12:52 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:40:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Rob Kearey 2003-03-22 00:22:41 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313

Description of problem:
When booting with a Netac OnlyDisk USB pen drive attached, the kernel panics -
oops attached. I can reproduce this reliably.

The kernel oopsed once when hot-plugging the same pen drive on a booted system,
but I have not been able to reproduce this.


Version-Release number of selected component (if applicable):
kernel-2.4.20-6

How reproducible:
Always

Steps to Reproduce:
1. Plug in USB pen drive
2. Turn on computer
3. Splat
  

Actual Results:  Kernel oops, system hang

Expected Results:  System boots, USB pen drive available for read/write.

Additional info:

Kernel oops follows, as captured with netdump.

Unable to handle kernel NULL pointer dereference at virtual address 000000e4
 printing eip:
e09242ef
*pde = 00000000
Oops: 0000
parport_pc lp parport iptable_filter ip_tables netconsole ide-cd autofs tulip
microcode sg sr_mod cdrom usb-storage loop lvm-mod keybdev mousedev hid input us
CPU:    0
EIP:    0060:[<e09242ef>]    Not tainted
EFLAGS: 00010246
 
EIP is at bus_reset [usb-storage] 0x6f (2.4.20-6)
eax: 00000000   ebx: 00000282   ecx: 00000000   edx: 00002003
esi: dfd79600   edi: 00000000   ebp: 00000000   esp: df4cff60
ds: 0068   es: 0068   ss: 0068
Process scsi_eh_1 (pid: 204, stackpage=df4cf000)
Stack: dfd79400 00000000 df4cff68 dfd79744 00000282 dfd79c00 00000000 00000000
       e08132af dfd79c00 00000000 dfd79c00 e0813d2e dfd79c00 000000c8 df4ce000
       00000000 00000000 dfd79800 00000001 00000000 df850680 df4cffd4 df4ce000
Call Trace:   [<e08132af>] scsi_try_bus_reset [scsi_mod] 0x4f (0xdf4cff80))
[<e0813d2e>] scsi_unjam_host [scsi_mod] 0x66e (0xdf4cff90))
[<e08142b8>] scsi_error_handler [scsi_mod] 0x118 (0xdf4cffc4))
[<e081b9f5>] .rodata.str1.1 [scsi_mod] 0x2049 (0xdf4cffcc))
[<e08141a0>] scsi_error_handler [scsi_mod] 0x0 (0xdf4cffe4))
[<c010742d>] kernel_thread_helper [kernel] 0x5 (0xdf4cfff0))
 
 
Code: 8b 90 e4 00 00 00 89 c1 80 7a 04 00 0f 84 96 00 00 00 31 ed
< netdump activated - performing handshake with the client. >


I'll try and reproduce this on another machine.
Comment 1 Rob Kearey 2003-03-22 00:37:11 EST
Seems to work fine on my other machine (ASUS CUSI-M motherboard), but not on my
ABit BH6. 
Comment 2 Pete Zaitcev 2003-04-14 14:38:59 EDT
Is this SMP?
Comment 3 Rob Kearey 2003-04-14 18:57:46 EDT
Nope, a plain single PIII. sysreport available if needed.
Comment 4 Rob Kearey 2003-05-23 20:51:30 EDT
I've been able to reproduce this behaviour on 2.4.20-13.9, though the call trace
is completely different. I cannot reproduce this behaviour on 2.4.20-8 and 2.4.20-9.

ip_tables: (C) 2000-2002 Netfilter core team
Unable to handle kernel NULL pointer dereference at virtual address 0000000c
 printing eip:
c013a400
*pde = 00000000 t
Oops: 0000
iptable_filter ip_tables netconsole ide-cd autofs tulip sg sr_mod cdrom
microcode loop lvm-mod scanner usb-storage keybdev mousedev hid input usb-uhci
usbcore
CPU:    0
EIP:    0060:[<c013a400>]    Not tainted
EFLAGS: 00010006
                                                                               
                                             
EIP is at kmem_cache_free_one [kernel] 0x30 (2.4.20-13.9)
eax: c1000030   ebx: 00000000   ecx: 00000000   edx: 00000000
esi: 01000680   edi: dde2f800   ebp: dfceb600   esp: dcf6dd84
ds: 0068   es: 0068   ss: 0068
Process usb.agent (pid: 3312, stackpage=dcf6d000)
Stack: c2219000 00000202 00000000 c0139d28 00000000 01000680 dfceb600 e0863f7b
       01000680 00000046 00000282 deac9e7c 00000003 dfceb600 00000000 dde2f800
       dfceb600 dfceb600 00000000 dde2f800 dfceb600 e08633a7 dfceb600 00000000
Call Trace:   [<c0139d28>] kfree [kernel] 0x38 (0xdcf6dd90))
[<e0863f7b>] usb_destroy_configuration [usbcore] 0x4b (0xdcf6dda0))
[<e08633a7>] usb_free_dev_R41275f44 [usbcore] 0x37 (0xdcf6ddd8))
[<e087add4>] process_urb [usb-uhci] 0x164 (0xdcf6dde4))
[<e087af67>] uhci_interrupt [usb-uhci] 0x97 (0xdcf6de10))
[<c010aac5>] handle_IRQ_event [kernel] 0x45 (0xdcf6de3c))
[<c010ac64>] do_IRQ [kernel] 0x84 (0xdcf6de5c))
[<c010d778>] call_do_IRQ [kernel] 0x5 (0xdcf6de7c))
[<c0150068>] remove_arg_zero [kernel] 0x78 (0xdcf6de9c))
[<c013a331>] __kmem_cache_alloc [kernel] 0x61 (0xdcf6dea8))
[<c011b796>] dup_mmap [kernel] 0xd6 (0xdcf6decc))
[<c011a5f6>] copy_mm [kernel] 0x106 (0xdcf6def4))
[<c011adc9>] copy_process [kernel] 0x389 (0xdcf6df18))
[<c011b3ce>] do_fork [kernel] 0x4e (0xdcf6df58))
[<c01521a5>] path_release [kernel] 0x15 (0xdcf6df74))
[<c01459fc>] sys_access [kernel] 0x11c (0xdcf6df80))
[<c0127cd2>] sys_rt_sigprocmask [kernel] 0xf2 (0xdcf6df90))
[<c0107b39>] sys_clone [kernel] 0x49 (0xdcf6dfa0))
[<c010953f>] system_call [kernel] 0x33 (0xdcf6dfc0))
                                                                               
                                             
                                                                               
                                             
Code: 8b 41 0c 29 c6 89 f0 f7 73 18 89 c6 8b 41 14 89 44 b1 18 8b
< netdump activated - performing handshake with the client. >
Comment 5 Rob Kearey 2003-05-30 20:43:53 EDT
Yow, here's another one, different call trace again. Note that it only does this
when booting with the USB pen drive plugged in. Dodgy BIOS?

Unable to handle kernel NULL pointer dereference at virtual address 0000000c
 printing eip:
c013a400
*pde = 00000000
Oops: 0000
mga agpgart parport_pc lp parport iptable_filter ip_tables netconsole ide-cd
autofs tulip microcode
sg sr_mod cdrom usb-storage loop lvm-mod keybdev mousedev
CPU:    0
EIP:    0060:[<c013a400>]    Not tainted
EFLAGS: 00010002
                                                                               
                    
EIP is at kmem_cache_free_one [kernel] 0x30 (2.4.20-13.9)
eax: c1000030   ebx: 00000000   ecx: 00000000   edx: 00000000
esi: 02010100   edi: de581900   ebp: dfceb600   esp: dbb0dec8
ds: 0068   es: 0068   ss: 0068
Process gdm-binary (pid: 2819, stackpage=dbb0d000)
Stack: df9b3000 00000206 00000000 c0139d28 00000000 02010100 dfceb600 e08640cf
       02010100 00000000 00000282 df363e7c c2455980 dfceb600 00000000 00000000
       dfceb600 dfceb600 00000000 de581900 dfceb600 e08633a7 dfceb600 00000000
Call Trace:   [<c0139d28>] kfree [kernel] 0x38 (0xdbb0ded4))
[<e08640cf>] usb_destroy_configuration [usbcore] 0x19f (0xdbb0dee4))
[<e08633a7>] usb_free_dev_R41275f44 [usbcore] 0x37 (0xdbb0df1c))
[<e087add4>] process_urb [usb-uhci] 0x164 (0xdbb0df28))
[<e087af67>] uhci_interrupt [usb-uhci] 0x97 (0xdbb0df54))
[<c010aac5>] handle_IRQ_event [kernel] 0x45 (0xdbb0df80))
[<c010ac64>] do_IRQ [kernel] 0x84 (0xdbb0dfa0))
[<c010d778>] call_do_IRQ [kernel] 0x5 (0xdbb0dfc0))
                                                                               
                    
                                                                               
                    
Code: 8b 41 0c 29 c6 89 f0 f7 73 18 89 c6 8b 41 14 89 44 b1 18 8b
< netdump activated - performing handshake with the client. >
Comment 6 Pete Zaitcev 2003-06-02 22:53:12 EDT
I don't think it's BIOS. Seems like upstream destroyed the usb-uhci.
Due to some design issues with it, the traceback is utterly useless
for investigation, I'm sorry to say (it's all a callback context,
so we cannot find the perpetrator).

Are you sure that 2.4.20-9 works? If yes, I'll start diffing.
Comment 7 Rob Kearey 2003-06-02 23:05:09 EDT
I haven't been able to reproduce it with 2.4.20-9, but I'll try and do so
tonight to confirm.
Comment 8 Pete Zaitcev 2003-06-03 15:25:24 EDT
The 2.4.20-18 went out today, and fixes some problems in -13, including the usb.
I would appreciate if you tested that as well. Sorry for the extra download.
Comment 9 Rob Kearey 2003-06-05 05:55:58 EDT
After a night of laborious rebooting, I can confirm the same problem occurs in
2.4.20-9 and 2.4.20-18.9. Similar calltrace. Anything I can do to get more info
for you?
Comment 10 Pete Zaitcev 2003-06-05 09:41:03 EDT
So, it's not fixed and I have to investigate further. You don't have to
stay with me, but of course it helps. I gather the thing can be plugged in
without causing an oops, sometimes. Here's some things I'd like to see
(on 2.4.20-18).

First, do reboot with it so it oopses, and collect whole dmesg, not just
the oops. Attach it to the bug (do not drop it into comments box).

Next, boot it without the thing and plug it in so it doesn't oops.
Wait about 10 seconds (the hotplug is super-slow, sorry). Then,
take the dmesg again and attach it too. But the main objective is
to get a good /proc/bus/usb/devices and /proc/scsi/usb-storage-0/1
(I need to see what transport type it uses).
Comment 11 Bugzilla owner 2004-09-30 11:40:41 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

Note You need to log in before you can comment on or make changes to this bug.