Bugzilla – Bug 458966
USB Hard Drive not recognized (Trekstor DataStation microdisk q.u 60GB)
Last modified: 2009-02-04 13:59:37 UTC
The Trekstor DataStation microdisk q.u 60GB USB hard drive is not working on openSUSE. The same disk works on Fedora 10. I don't know, if it's related to HAL or the kernel or even something else. I post the kernel output and kernel version below. Other than that, it's an up-to-date openSUSE 11.1. If you need more information, please tell me what I can do. I'd also send out the hardware if someone needs it for testing. Here is what I get in dmesg: -- Dec 14 13:21:58 linux-iqwd kernel: usb 1-4.1: new high speed USB device using ehci_hcd and address 6 Dec 14 13:21:58 linux-iqwd kernel: usb 1-4.1: configuration #1 chosen from 1 choice Dec 14 13:21:58 linux-iqwd kernel: scsi9 : SCSI emulation for USB Mass Storage devices Dec 14 13:21:58 linux-iqwd kernel: usb-storage: device found at 6 Dec 14 13:21:58 linux-iqwd kernel: usb-storage: waiting for device to settle before scanning Dec 14 13:21:58 linux-iqwd kernel: usb 1-4.1: New USB device found, idVendor=0000, idProduct=0000 Dec 14 13:21:58 linux-iqwd kernel: usb 1-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Dec 14 13:21:58 linux-iqwd kernel: usb 1-4.1: Product: Dec 14 13:21:58 linux-iqwd kernel: usb 1-4.1: Manufacturer: Dec 14 13:21:58 linux-iqwd kernel: usb 1-4.1: SerialNumber: S1GAJ16PC08640 Dec 14 13:22:09 linux-iqwd kernel: usb 1-4.1: reset high speed USB device using ehci_hcd and address 6 Dec 14 13:22:19 linux-iqwd kernel: usb 1-4.1: reset high speed USB device using ehci_hcd and address 6 Dec 14 13:22:35 linux-iqwd kernel: usb 1-4.1: reset high speed USB device using ehci_hcd and address 6 Dec 14 13:22:36 linux-iqwd kernel: usb 1-4.1: reset high speed USB device using ehci_hcd and address 6 Dec 14 13:22:46 linux-iqwd kernel: usb 1-4.1: reset high speed USB device using ehci_hcd and address 6 Dec 14 13:22:46 linux-iqwd kernel: scsi 9:0:0:0: Device offlined - not ready after error recovery Dec 14 13:22:46 linux-iqwd kernel: usb-storage: device scan complete -- Kernel information: Linux localhost 2.6.27.7-4-default #1 SMP 2008-11-25 00:02:37 +0100 i686 athlon i386 GNU/Linux
I thought I'd add my lspci output for more information. 00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a1) 00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2) 00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a2) 00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1) 00:02.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2) 00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1) 00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2) 00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2) 00:05.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2) 00:06.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev a2) 00:06.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2) 00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2) 00:0f.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:06.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller 01:07.0 Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder (rev 05) 01:07.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05) 01:07.4 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [IR Port] (rev 05) 02:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7600 GS] (rev a1)
Please provide following info: lshal > /tmp/lshal_output 1. remove the device from your machine 2. call on a console: lshal -m 3. readd/plug in the device and wait some seconds 4. attach than /var/log/messages and the full output of lshal More info on http://en.opensuse.org/HAL#Debugging.2FBugreporting
Created attachment 260161 [details] lshal -m output
Created attachment 260162 [details] complete lshal output
Created attachment 260163 [details] /var/log/messages
Thanks for the link. I attached the info you requested.
Created attachment 260164 [details] complete lshal output argh, the first "complete lshal output" was done when the device wasn't plugged in, which is probably not very helpful. so here is another one. sorry about all the emails..
Danny, can you look at the bug?
AFAICS Kernel bug/problem.
Reassign to kernel-maintainers.
Okay, if it's a kernel problem: I had the same behaviour when booting the packaged vanilla kernel.
From dmesg your device is reset a few times (presumably without success, logging isn't detailed enough to tell) and then taken offline. However, at least the ID is retrieved, therefore at least some communication works.
Please attach the output of "lsusb -v" with your disk attached.
Created attachment 260424 [details] lsusb -v output Here is the lsusb -v output. Device in question is "Bus 002 Device 005". Btw, I have the same disk with 30gb capacity (which works without problems on Suse), I could attach it's info, too, if that helps.
Please clarify: Is it another disk in the same enclosure or a totally different device? Is the disk attached to this hub? Bus 002 Device 002: ID 0409:0059 NEC Corp. HighSpeed Hub If so, does it have its own power brick?
Created attachment 261679 [details] dmesg from oliver's debug kernel After the last comment, oliver and I spoke on IRC and he gave me a debug kernel. I attached the more detailed dmesg output and added some inline comments on what I was doing... The problem only shows up if my usb keyboard is attached via an external usb hub (tried 2 different ones). If that is the case, the harddrive won't work in any of the usb ports (direct or via hub). If the keyboard is connected at one of the mainboard-ports, the disk works on every port again (direct and via hub). more chipset information: 00:02.0 0c03: 10de:036c (rev a1) (prog-if 10 [OHCI]) Subsystem: 1043:8239 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 20 Memory at fe02f000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 Kernel driver in use: ohci_hcd Kernel modules: ohci-hcd 00:02.1 0c03: 10de:036d (rev a2) (prog-if 20 [EHCI]) Subsystem: 1043:8239 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 23 Memory at fe02e000 (32-bit, non-prefetchable) [size=256] Capabilities: [44] Debug port: BAR=1 offset=0098 Capabilities: [80] Power Management version 2 Kernel driver in use: ehci_hcd Kernel modules: ehci-hcd
If this is the chipset bug, a kernel upgrade should help. Please test.
No response.
Sorry, I was wondering to which version I should upgrade to test this. I run the current 11.1 kernel currently. The debug output is from the kernel you provided me on IRC.
Sorry for the confusion
Please redo the test from comment #16 with the KOTD
Created attachment 267514 [details] dmesg output from KOTD Here is the dmesg output from my test with the KOTD (problem persists). At line 724 I connect the keyboard directly to the front usb port. Afterwards I connect the harddisk and everything works fine. At line 764 I attach the keyboard to the hub. Afterwards I connect the harddisk and get the same problems as before usb 2-6.1: reset high speed USB device using ehci_hcd and address 7 several times, then: scsi 9:0:0:0: Device offlined - not ready after error recovery it doesn't matter where I connect the harddisk. The problem occurs whenever the keyboard is connected via hub. This is probably a very rare bug and I have a workaround, so I don't know how much time should really be spend on that issue. I guess there are more important bugs regarding KDE / Pulseaudio, whatever. But that's up to you of course.
This needs further debugging output in the kernel to see what's going on.
Please attach the output of "lspci -vn"
Created attachment 267723 [details] lspci -vn output
Not among the affected hardware. Very little chance of fixing this.