A commonly available usb3 - sata dock experiences regular disconnections & possible data corruption during heavy usage. kernel 3.6.8-2.fc17.x86_64 #1 SMP Tue Nov 27 19:35:02 UTC 2012 % lspci -v: 02:00.0 USB Controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller (prog-if 30 [XHCI]) Subsystem: Technical Corp. Device 5678 Flags: bus master, fast devsel, latency 0, IRQ 18 Memory at fdef8000 (64-bit, non-prefetchable) [size=32K] Capabilities: [50] MSI: Enable- Count=1/8 Maskable- 64bit+ Capabilities: [68] MSI-X: Enable+ Count=8 Masked- Capabilities: [78] Power Management version 3 Capabilities: [80] Express Legacy Endpoint, MSI 00 Capabilities: [100] Virtual Channel Kernel driver in use: xhci_hcd % lsusb -v Bus 008 Device 015: ID 152d:0551 JMicron Technology Corp. / JMicron USA Technology Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x152d JMicron Technology Corp. / JMicron USA Technology Corp. idProduct 0x0551 bcdDevice 1.00 iManufacturer 1 JMicron iProduct 2 USB to ATA/ATAPI Bridge iSerial 5 DCA0434115FF bNumConfigurations 1 .... % dmesg (working initial connection): [3549132.365487] usb 8-2: new SuperSpeed USB device number 15 using xhci_hcd [3549132.376462] usb 8-2: Parent hub missing LPM exit latency info. Power management will be impacted. [3549132.377264] usb 8-2: New USB device found, idVendor=152d, idProduct=0551 [3549132.377268] usb 8-2: New USB device strings: Mfr=1, Product=2, SerialNumber=5 [3549132.377272] usb 8-2: Product: USB to ATA/ATAPI Bridge [3549132.377274] usb 8-2: Manufacturer: JMicron [3549132.377277] usb 8-2: SerialNumber: DCA0434115FF [3549132.394930] scsi27 : usb-storage 8-2:1.0 [3549133.398713] scsi 27:0:0:0: Direct-Access ST3000DM 001-1CH166 PQ: 0 ANSI: 5 [3549133.398968] scsi 27:0:0:1: Direct-Access WDC WD20 EADS-00R6B0 PQ: 0 ANSI: 5 [3549133.402978] sd 27:0:0:0: Attached scsi generic sg7 type 0 [3549133.404792] sd 27:0:0:1: Attached scsi generic sg8 type 0 % dmesg (failure): [3468006.010767] Buffer I/O error on device sdg1, logical block 365985792 [3468006.010773] lost page write due to I/O error on sdg1 [3468006.010776] JBD2: Error -5 detected when updating journal superblock for sdg1-8. [3468268.031160] EXT4-fs error (device sdh1): ext4_journal_start_sb:349: Detected aborted journal [3468268.031167] EXT4-fs (sdh1): Remounting filesystem read-only [3468361.883779] usb 8-2: Device not responding to set address. [3468362.086371] usb 8-2: Device not responding to set address. [3468362.287028] usb 8-2: device not accepting address 14, error -71 [3468362.338073] usb 8-2: USB disconnect, device number 14 [3468362.338117] sd 26:0:0:0: Device offlined - not ready after error recovery [3468362.341831] xhci_hcd 0000:02:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff880101c28b00 [3468362.341838] xhci_hcd 0000:02:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff880101c28b40 [3468362.684985] EXT4-fs error (device sdh1): ext4_put_super:859: Couldn't clean up the journal See also http://lists.lug.boulder.co.us/pipermail/lug/Week-of-Mon-20121112/042476.html and http://lists.community.tummy.com/pipermail/lug/Week-of-Mon-20121119/042478.html
Are you still seeing this with 3.7.9 or 3.8.2 in updates-testing?
Hey Josh. I switched to another USB3 drive dock (ASMedia USB chipset based), and it's rock-solid. I'll power up the previous hardware and run some tests to let you know.
(Oops, the well-working newer hardware is JMicron-based.)
(Meh, sorry, I'm getting confused; the host controller is ASMedia; the working target controller is ASMedia; the so-so target controller is JMicron. I'll get this right eventually.)
The problem still occurs, apparently some time after a load of I/O (an rsync backup job) ends, and idleness sets in: [123556.874116] usb 8-1: USB disconnect, device number 5 [123556.874169] sd 8:0:0:0: Device offlined - not ready after error recovery [123560.275798] Buffer I/O error on device sdh1, logical block 243826688 [123560.275809] lost page write due to I/O error on sdh1 [123560.275817] JBD2: Error -5 detected when updating journal superblock for sdh1-8 At that point, the JMicron target drops off the bus and doesn't show up on lsusb any more. Linux XXXX 3.8.1-201.fc18.x86_64 #1 SMP Thu Feb 28 19:23:08 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
I am facing similar USB 3 issues with an enclosure. I wonder if this is due to the xHCI driver or anything to do with the JMicron bridge in the enclosure. When the enclosure is switched on, the disk spins up but does not show up on Nautilus (A - dmesg below) Linux XXXX 3.8.4-102.fc17.x86_64 #1 SMP Sun Mar 24 13:09:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux HP Pavilion dv6t-6000 CTO Quad Edition Entertainment Notebook PC USB Controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) (prog-if 30 [XHCI]) http://pastebin.com/BuNqEwsA ORICO - 7629US3-C USB 3 2 bay 3.5 drive enclosure [23057.548952] usb 4-2: new SuperSpeed USB device number 2 using xhci_hcd [23057.561299] usb 4-2: Parent hub missing LPM exit latency info. Power management will be impacted. [23057.563927] usb 4-2: New USB device found, idVendor=152d, idProduct=0551 [23057.563936] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=5 [23057.563942] usb 4-2: Product: USB to ATA/ATAPI Bridge [23057.563947] usb 4-2: Manufacturer: JMicron [23057.563952] usb 4-2: SerialNumber: 0DF1515475FF [23057.638685] Initializing USB Mass Storage driver... [23057.639132] scsi6 : usb-storage 4-2:1.0 [23057.639435] usbcore: registered new interface driver usb-storage [23057.639442] USB Mass Storage support registered. (A) dmesg [ 548.141266] usb 3-1: new high-speed USB device number 2 using xhci_hcd [ 553.139915] xhci_hcd 0000:19:00.0: Timeout while waiting for address device command [ 577.054632] xhci_hcd 0000:19:00.0: Stopped the command ring failed, maybe the host is dead [ 577.130984] xhci_hcd 0000:19:00.0: Host not halted after 16000 microseconds. [ 577.130989] xhci_hcd 0000:19:00.0: Abort command ring failed [ 577.131777] xhci_hcd 0000:19:00.0: HC died; cleaning up [ 582.331201] xhci_hcd 0000:19:00.0: Timeout while waiting for address device command [ 582.331213] xhci_hcd 0000:19:00.0: Abort the command ring, but the xHCI is dead. [ 582.532121] usb 3-1: device not accepting address 2, error -108 [ 582.532141] hub 3-0:1.0: cannot disable port 1 (err = -19) [ 587.530813] xhci_hcd 0000:19:00.0: Timeout while waiting for a slot [ 587.530826] xhci_hcd 0000:19:00.0: Abort the command ring, but the xHCI is dead. [Full output - http://pastebin.com/sMrPwEhD]
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 18 kernel bugs. Fedora 18 has now been rebased to 3.11.4-101.fc18. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 19, and are still experiencing this issue, please change the version to Fedora 19. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. It has been over a month since we asked you to test the 3.11 kernel updates and let us know if your issue has been resolved or is still a problem. When this happened, the bug was set to needinfo. Because the needinfo is still set, we assume either this is no longer a problem, or you cannot provide additional information to help us resolve the issue. As a result we are closing with insufficient data. If this is still a problem, we apologize, feel free to reopen the bug and provide more information so that we can work towards a resolution If you experience different issues, please open a new bug report for those.
Created attachment 841778 [details] Dmesg output from kernel 3.12.5, USB HDD dock attached after boot Confirmed still occuring with kernel 3.12.5-302 from Fedora 20. I have this JMicron controller in a MediaSonic SATA -> USB3 enclosure and I can only get through a few files in rsync before it disconnects. Attached is dmesg output from 3.12.5-303, which I compiled using fedpkg from git a few days ago.
Updating release & issue status.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.13.4-200.fc20. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
(In reply to Justin M. Forbes from comment #11) > *********** MASS BUG UPDATE ************** The bug is still here. Nothing has been changed. The strange part, it cannot be reproduced with ext2/vfat. Reproduced every single time with xfs/ext3/ext4.
ext4 also work without a journal (ext3 too probably): # mkfs.ext4 -O ^has_journal /dev/sdb1 # mount... read/write # umount ... Unfortunately there is no way to have an xfs filesystem without journal.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.14.4-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
I have the same problem with 3.14.4-100 (fedora 19).
Same issue, F20.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.17.2-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21. If you experience different issues, please open a new bug report for those.
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
Today I was able to re-test my jmicron usb3 sata dock with an xfs file system using Fedora 21. This bug seems to be fixed with kernel 3.17.7-300. The bug can be closed again as fixed. Also, can we have this fix back ported to RHEL 6 and 7?