Oops (Unable to handle kernel NULL pointer dereference) on plugging out and plugging in USB stick on RHEL4 (2.6.9-5.ELsmp). On RHEL4 U2 (2.6.9-22.ELsmp), USB stick removal leads to kernel panic. Reproducible Everytime. Steps: This problem can be reproduced by plugging out and plugging in USB stick 2-3 times. The kernel panic is as follows: Jan 2 17:45:33 llibg188 kernel: usb 2-2: USB disconnect, address 2 Jan 2 17:45:33 llibg188 kernel: Unable to handle kernel NULL pointer dereferenc e at 0000000000000090 RIP: Jan 2 17:45:33 llibg188 kernel: <ffffffff801aacad>{sysfs_remove_dir+43} Jan 2 17:45:33 llibg188 kernel: PML4 7cf7c067 PGD 0 Jan 2 17:45:33 llibg188 kernel: Oops: 0000 [1] SMP Jan 2 17:45:33 llibg188 kernel: CPU 0 Jan 2 17:45:33 llibg188 kernel: Modules linked in: usb_storage md5 ipv6 parport _pc lp parport autofs4 sunrpc ds yenta_socket pcmcia_core dm_mod button battery ac joydev ohci_hcd hw_random tg3 ext3 jbd qla2300(U) qla2xxx(U) qla2xxx_conf (U) mptscsih mptbase sd_mod scsi_mod Jan 2 17:45:33 llibg188 kernel: Pid: 41, comm: khubd Not tainted 2.6.9-5.ELsmp Jan 2 17:45:33 llibg188 kernel: RIP: 0010:[<ffffffff801aacad>] <ffffffff801aaca d>{sysfs_remove_dir+43} Jan 2 17:45:33 llibg188 kernel: RSP: 0018:000001007fecdc68 EFLAGS: 00010246 Jan 2 17:45:33 llibg188 kernel: RAX: 0000010080000000 RBX: 00000100f5a3ef10 RCX : 0000010080000000 Jan 2 17:45:33 llibg188 kernel: RDX: 0000000000000202 RSI: 00000100fbd477f0 RDI : 00000100f5a3ef10 Jan 2 17:45:33 llibg188 kernel: RBP: 0000000000000000 R08: 000001007fecc000 R09 : 0000010002f36e80 Jan 2 17:45:33 llibg188 kernel: R10: 0000000000000000 R11: 0000010002f36e80 R12 : 000001007e4f6800 Jan 2 17:45:33 llibg188 kernel: R13: 0000000000000010 R14: 000001007feec6a0 R15 : 000001007feec400 Jan 2 17:45:33 llibg188 kernel: FS: 0000002a955603e0(0000) GS:ffffffff804bf300 (0000) knlGS:00000000f7fd16c0 Jan 2 17:45:33 llibg188 kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 00000000800500 3b Jan 2 17:45:33 llibg188 kernel: CR2: 0000000000000090 CR3: 0000000000101000 CR4 : 00000000000006e0 Jan 2 17:45:33 llibg188 kernel: Process khubd (pid: 41, threadinfo 000001007fec c000, task 00000100fbd477f0) Jan 2 17:45:33 llibg188 kernel: Stack: 00000100f5a3ef10 0000000000000002 000001 007e4f6800 0000000000000010 Jan 2 17:45:33 llibg188 kernel: 000001007feec6a0 ffffffff801db792 000001 00f5a3ef10 ffffffff801db7a4 Jan 2 17:45:33 llibg188 kernel: 00000100f83f5a00 ffffffff801a80d6 Jan 2 17:45:33 llibg188 kernel: Call Trace:<ffffffff801db792>{kobject_del+27} < ffffffff801db7a4>{kobject_unregister+9} Jan 2 17:45:33 llibg188 kernel: <ffffffff801a80d6>{del_gendisk+36} <ffff ffffa0025c65>{:sd_mod:sd_remove+22} Jan 2 17:45:33 llibg188 kernel: <ffffffff802383d3> {device_release_driver +83} <ffffffff80238597>{bus_remove_device+162} Jan 2 17:45:33 llibg188 kernel: <ffffffff80237819>{device_del+104} <ffff ffffa0007be0>{:scsi_mod:scsi_remove_device+115} Jan 2 17:45:33 llibg188 kernel: <ffffffffa000755a> {:scsi_mod:scsi_forget _host+59} <ffffffffa0001290>{:scsi_mod:scsi_remove_host+9} Jan 2 17:45:33 llibg188 kernel: <ffffffffa021d8b7> {:usb_storage:storage_ disconnect+102} Jan 2 17:45:33 llibg188 kernel: <ffffffff80272481> {usb_unbind_interface+ 59} <ffffffff802383d3>{device_release_driver+83} Jan 2 17:45:33 llibg188 kernel: <ffffffff80238597> {bus_remove_device+162 } <ffffffff80237819>{device_del+104} Jan 2 17:45:33 llibg188 kernel: <ffffffff802788e1> {usb_disable_device+11 2} <ffffffff80274011>{usb_disconnect+224} Jan 2 17:45:33 llibg188 kernel: <ffffffff80275813>{hub_thread+1057} <fff fffff80132ff0>{autoremove_wake_function+0} Jan 2 17:45:33 llibg188 kernel: <ffffffff80132ff0> {autoremove_wake_funct ion+0} <ffffffff80110c23>{child_rip+8} Jan 2 17:45:33 llibg188 kernel: <ffffffff801ea51a>{vgacon_cursor+0} <fff fffff801ea51a>{vgacon_cursor+0} Jan 2 17:45:33 llibg188 kernel: <ffffffff802753f2>{hub_thread+0} <ffffff ff80110c1b>{child_rip+0} Jan 2 17:45:33 llibg188 kernel: Jan 2 17:45:33 llibg188 kernel: Jan 2 17:45:33 llibg188 kernel: Code: 4c 8b ad 90 00 00 00 0f 84 07 01 00 00 4c 8b 65 10 31 d2 be Jan 2 17:45:33 llibg188 kernel: RIP <ffffffff801aacad>{sysfs_remove_dir+43} RSP <000001007fecdc68> Jan 2 17:45:33 llibg188 kernel: CR2: 0000000000000090 [root@llibg188 ~]# fdisk -l /dev/sdda Disk /dev/sdda: 1047 MB, 1047134208 bytes 33 heads, 61 sectors/track, 1015 cylinders Units = cylinders of 2013 * 512 = 1030656 bytes Device Boot Start End Blocks Id System /dev/sdda1 1 486 489128+ 83 Linux /dev/sdda2 487 1015 532438+ 83 Linux [root@llibg188 ~]# fdisk -l /dev/sdda [root@llibg188 ~]# fdisk -l /dev/sdda [root@llibg188 ~]# fdisk -l /dev/sdda [root@llibg188 ~]# fdisk -l /dev/sdda
I need to see the complete dmesg, taken after the oops. Please do not drop it into the comments box, but attach to the bug instead.
Created attachment 123000 [details] dmesg output after oops
1. Seen this issue on AMD (x86_64), IA32 as well as IA64. 2. This happens without running any I/O on USB device. 3. dmesg output is uploaded to log file.
Sysreport is probably an overkill. The original report was clear and to the point, and the dmesg taken correctly, so I have the data. But testing with the beta U3 would be much appreciated. I thought Al fixed all this -17 weirdness with kobject_add. But I guess not in this scenario.
This seems a duplicate of bug 153971. But please, nobody move to dup, before Hari tests U3 (anything later than 2.6.9-22.14.EL should work).
Engineering Reports: Tried the same scenario with U3 Beta kernel (2.6.9-27.ELsmp), problem is not seen on U3 Beta kernel (2.6.9-27.ELsmp). We will continue with our testing. As of now this issue can be marked dup and resolved.
Created attachment 123344 [details] dmesg output (dmesg.out.U3_IA32) uploaded after USB stick removal/insertion on U3 Beta kernel. dmesg output (dmesg.out.U3_IA32) uploaded after USB stick removal/insertion on U3 Beta kernel.