Just thought I'd share some of the fun I have to face all the time with usb-storage. The bug is against the RHEL 3 U2, which essentially equals Marcelo >= 2.4.24 in the usb-storage department.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120341 khubd D 00000002 3584 81 1 205 26 (L-TLB) Call Trace: [<c0123274>] schedule [kernel] 0x2f4 (0xf678de60) [<c010ac83>] __down [kernel] 0x73 (0xf678dea4) [<c010ae2c>] __down_failed [kernel] 0x8 (0xf678ded8) [<f8edd51f>] .text.lock.usb [usb-storage] 0x85 (0xf678dee8) [<f8eeb0a0>] usb_storage_driver [usb-storage] 0x20 (0xf678def0) [<f8eeb080>] usb_storage_driver [usb-storage] 0x0 (0xf678def4) [<f8bb2380>] usb_disconnect_Rsmp_8c20b3cd [usbcore] 0xa0 (0xf678def8) [<f8bc3720>] hub_driver [usbcore] 0x0 (0xf678df18) [<f8bb2428>] usb_disconnect_Rsmp_8c20b3cd [usbcore] 0x148 (0xf678df24) [<f8bb538f>] usb_hub_port_connect_change [usbcore] 0x27f (0xf678df50) [<f8bb4dac>] usb_hub_port_status [usbcore] 0x6c (0xf678df64) [<f8bb56a2>] usb_hub_events [usbcore] 0x302 (0xf678df84) [<f8bb5755>] usb_hub_thread [usbcore] 0x55 (0xf678dfb0) [<f8bb5700>] usb_hub_thread [usbcore] 0x0 (0xf678dfe0) [<c010958d>] kernel_thread_helper [kernel] 0x5 (0xf678dff0) usb-storage-0 D 00000002 3584 2692 1 2693 211 (L-TLB) Call Trace: [<c0123274>] schedule [kernel] 0x2f4 (0xc4f5fe2c) [<c01238e1>] wait_for_completion [kernel] 0x71 (0xc4f5fe70) [<f8eda8a5>] usb_stor_control_msg [usb-storage] 0x175 (0xc4f5fec4) [<f8edb0f5>] usb_stor_CBI_transport [usb-storage] 0xa5 (0xc4f5fef0) [<f8edae8c>] usb_stor_invoke_transport [usb-storage] 0x18c (0xc4f5ff20) [<c0170000>] open_namei [kernel] 0x330 (0xc4f5ff48) [<f8eda341>] usb_stor_ufi_command [usb-storage] 0x61 (0xc4f5ff60) [<f8edc245>] usb_stor_control_thread [usb-storage] 0x355 (0xc4f5ff78) [<f8edbef0>] usb_stor_control_thread [usb-storage] 0x0 (0xc4f5ffe0) [<c010958d>] kernel_thread_helper [kernel] 0x5 (0xc4f5fff0) scsi_eh_2 D 00000001 4100 2693 1 3230 2692 (L-TLB) Call Trace: [<c0123274>] schedule [kernel] 0x2f4 (0xc4f37ec8) [<c01238e1>] wait_for_completion [kernel] 0x71 (0xc4f37f0c) [<c0123274>] schedule [kernel] 0x2f4 (0xc4f37f2c) [<f8ed9279>] command_abort [usb-storage] 0x79 (0xc4f37f60) [<f8b14621>] scsi_try_to_abort_command [scsi_mod] 0x61 (0xc4f37f6c) [<f8b15421>] scsi_unjam_host [scsi_mod] 0x8a1 (0xc4f37f7c) [<f8b157e8>] scsi_error_handler [scsi_mod] 0x148 (0xc4f37fb4) [<f8b1db75>] .rodata.str1.1 [scsi_mod] 0x2071 (0xc4f37fbc) [<f8b156a0>] scsi_error_handler [scsi_mod] 0x0 (0xc4f37fe4) [<c010958d>] kernel_thread_helper [kernel] 0x5 (0xc4f37ff0) It appears that they is the compination of 4-way SMP, two storage devices on the same bus, and one of them being a floppy (UFI). I already fixed some of the failure paths, but apparently not all. Before it collapsed much sooner than 10 switches. If someone has an IBM Bladecenter, it may be a good excercise to run 2.6 on it and flip console there and back 20 times. Curiously, I cannot reproduce it just by pulling cables here on a regular kind of PC. -- Pete ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
