Most recent kernel where this bug did not occur: unknown Distribution: Fedora core 5 Hardware Environment: FIC-AZ11EA MOBO, 512MB RAM, IDE, 1.0Ghz athlon, 2 ethernet cards, 1 prism2 card, one PCI Video card. Is a Via 686 chipset. Software Environment: Fedora core 5 with lots of things installed. Problem Description: USB Storage devices are initially detected, but then go away with lots of kernel errors. Not sure when started, possibly about 6 months ago. Unsure Kernel version then. Sample syslog snippet (this is only a snippet of the most significant lines): Sep 5 22:53:20 k1gto kernel: usb-storage: queuecommand called Sep 5 22:53:20 k1gto kernel: usb-storage: *** thread awakened. Sep 5 22:53:20 k1gto kernel: usb-storage: Command READ_10 (10 bytes) Sep 5 22:53:20 k1gto kernel: usb-storage: 28 00 00 00 00 00 00 00 08 00 Sep 5 22:53:20 k1gto kernel: usb-storage: Bulk Command S 0x43425355 T 0x2f L 40 96 F 128 Trg 0 LUN 0 CL 10 Sep 5 22:53:20 k1gto kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 b ytes Sep 5 22:54:20 k1gto kernel: usb-storage: command_abort called Sep 5 22:54:20 k1gto kernel: usb-storage: usb_stor_stop_transport called Sep 5 22:54:20 k1gto kernel: usb-storage: -- cancelling URB Sep 5 22:54:20 k1gto kernel: usb-storage: Status code -104; transferred 0/31 Sep 5 22:54:20 k1gto kernel: usb-storage: -- transfer cancelled Sep 5 22:54:20 k1gto kernel: usb-storage: Bulk command transfer result=4 Sep 5 22:54:20 k1gto kernel: usb-storage: -- command was aborted Sep 5 22:54:20 k1gto kernel: usb 2-2: reset full speed USB device using uhci_hc d and address 3 Sep 5 22:54:21 k1gto kernel: usb 2-2: usb-storage timed out on ep0in len=0/64 Sep 5 22:54:23 k1gto last message repeated 2 times Sep 5 22:54:23 k1gto kernel: usb 2-2: device descriptor read/64, error -110 Sep 5 22:54:28 k1gto kernel: usb 2-2: usb-storage timed out on ep0in len=0/64 Sep 5 22:54:38 k1gto last message repeated 2 times Sep 5 22:54:39 k1gto kernel: usb 2-2: device descriptor read/64, error -110 Sep 5 22:54:39 k1gto kernel: hub 2-0:1.0: state 7 ports 2 chg 0000 evt 0004 Sep 5 22:54:39 k1gto kernel: usb 2-2: reset full speed USB device using uhci_hc d and address 3 Steps to reproduce: Plug in a USB mass storage device, watch the syslog go nuts. booting with acpi=noirq had no affect
It's possible that the problem lies in your USB device or in your computer's USB controller. The log messages make it look like a problem in the device, but they could be deceptive. Once the mass-storage device disconnects, what happens if you rmmod uhci-hcd and then modprobe it back?
Reply-To: brad@k1gto.com I don't think it's device specific. I've tried two different USB memory drives, and an external IDE enclosure. These devices all work fine on my other computer in windows. Here is a snippet from my syslog as I unplugged both devices, rmmod, modprobe, then plugged just the 256MB thumb-drive back in. http://old.k1gto.com/wiki/index.php/Kernel_toubleshooting I tried to do some troubleshooting by loading old kernels (2.6.0, 2.6.5, 2.6.10), but the old kernels won't compile so I've abandoned that idea. I would have to "downgrade" GCC and some other stuff by the looks of it. -----Original Message----- From: bugme-daemon@bugzilla.kernel.org [mailto:bugme-daemon@bugzilla.kernel.org] Sent: Wednesday, September 06, 2006 10:14 AM To: brad7@k1gto.com Subject: [Bug 7113] USB Mass storage devices are detected and then die http://bugzilla.kernel.org/show_bug.cgi?id=7113 stern@rowland.harvard.edu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stern@rowland.harvard.edu ------- Additional Comments From stern@rowland.harvard.edu 2006-09-06 07:05 ------- It's possible that the problem lies in your USB device or in your computer's USB controller. The log messages make it look like a problem in the device, but they could be deceptive. Once the mass-storage device disconnects, what happens if you rmmod uhci-hcd and then modprobe it back? ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter.
Please don't include the original message text when replying by email. It just clutters up the bug report. It's possible that the problem lies elsewhere in your computer, such as in the interrupt controller. Here's how you can get more information. First, make sure that CONFIG_USB_DEBUG and CONFIG_DEBUG_FS are both set in your kernel. Next, after the problem occurs type: mount -t debugfs none /sys/kernel/debug rmmod uhci-hcd modprobe uhci-hcd debug=2 Plug in the thumb-drive and then -- here the timing is important -- while the system is trying and failing to initialize the thumb-drive, make a copy of /sys/kernel/debug/uhci/0000:00:07.3 (the last part of the path is the PCI address of the controller into which you plug the drive). Maybe even make several copies while the initialization is going on, just to be sure nothing gets missed. It also would be a good idea to make copies of /proc/interrupts before and after plugging in the thumb-drive, to see if the interrupt count goes up.
Reply-To: brad@k1gto.com Lots of debug detail this time. Nothing jumped out at me as obviously wrong, but then again I don't really understand all the low-level messages. I organized all the information in my wiki at the following URL: http://old.k1gto.com/wiki/index.php/Info_for_kernel_bug It includes the /proc/interrupts before and after, syslog output, and the debugfs file. Note that I wrote a script to grab the contents of the debugfs file any time it changed and piped it to stdout. You'll see what I mean when you click the link - it should be pretty straight forward.
The UHCI debugging output indicates that the USB controller is broken. There's no way to know whether it's actually sending any data over the USB bus, but it definitely is not updating the data in the computer's memory. Apparently it's not a permanent problem; the controller starts out working after a power reset and then stops. By the way, this doesn't mean the EHCI controller is also broken. It could be that if you plugged in a high-speed USB device, it would work just fine. Do the other USB ports behave the same way? If they do, your only option is to buy an add-on PCI USB card.
Connected PCI USB card, connected thumb drive to it, mounted thumb drive, performed tests, all tests passed without incident - Problem is with onboard USB hardware as stated by Alan. No bug. I'm closing call with resolution of "invalid".