# USB 3.0 corrupts NTFS disks

## naviathan

I've been having this problem for a while now and I'm finally fed up with it. I can plug an external hard drive or USB drive into my USB 2.0 ports without a problem. As soon as I plug it into the USB 3.0 ports and start transferring data to the drive, it corrupts the volume. I have to either chkdsk it from windows or wipe the drive and reformat. I'm hoping someone has experienced this and can tell me what I need to do to fix it. I'm running a 64bit version of gentoo with KDE SE overlay and ~amd64. Any thoughts?

----------

## frostschutz

Create a small partition and badblocks it. If it raises errors in USB3 mode but not in USB2 mode, then something is wrong somewhere, unrelated to NTFS.

----------

## naviathan

I threw NTFS in there because it's part of the scenario I'm working with. I don't think NTFS is the actual issue though. I'm running an ASROCK Z77 Pro 4 motherboard and this has been an ongoing issue. I actually switched to gentoo to see if the latest kernels fixed the issue, but they don't. I switched to Ubuntu Gnome last night to see if there was any progress with the Ubuntu systems and there's not. Here's some dmesg output related to the issue:

```
 sd 10:0:0:0: [sdc]  

[20830.258026] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK

[20830.258028] sd 10:0:0:0: [sdc] CDB: 

[20830.258030] Write(10): 2a 00 15 dc 15 80 00 00 08 00

[20830.258040] end_request: I/O error, dev sdc, sector 366744960

[20830.258044] Buffer I/O error on device sdc1, logical block 45842864

[20830.258046] lost page write due to I/O error on sdc1

[20830.369554] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd

[20830.385781] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a40

[20830.385786] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a00

[20830.505442] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd

[20830.521677] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a40

[20830.521682] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a00

[20830.641284] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd

[20830.657536] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a40

[20830.657541] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a00

[20830.777158] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd

[20830.793143] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a40

[20830.793148] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a00

[20830.912987] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd

[20830.929240] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a40

[20830.929245] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a00

[20831.048854] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd

[20831.065074] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a40

[20831.065079] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a00

[20831.065202] sd 10:0:0:0: [sdc] Unhandled error code

[20831.065205] sd 10:0:0:0: [sdc]  

[20831.065207] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK

[20831.065209] sd 10:0:0:0: [sdc] CDB: 

[20831.065211] Write(10): 2a 00 15 dc 95 80 00 00 20 00

[20831.065221] end_request: I/O error, dev sdc, sector 366777728

[20831.065225] Buffer I/O error on device sdc1, logical block 45846960

[20831.065227] lost page write due to I/O error on sdc1

[20831.065231] Buffer I/O error on device sdc1, logical block 45846961

[20831.065233] lost page write due to I/O error on sdc1

[20831.065235] Buffer I/O error on device sdc1, logical block 45846962

[20831.065237] lost page write due to I/O error on sdc1

[20831.065239] Buffer I/O error on device sdc1, logical block 45846963

[20831.065241] lost page write due to I/O error on sdc1

[20831.176758] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd

[20831.192943] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a40

[20831.192946] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a00

[20831.312633] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd

[20831.328851] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a40

[20831.328856] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a00

[20831.448511] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd

[20831.464728] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a40

[20831.464733] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a00

[20831.584328] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd

[20831.601118] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a40

[20831.601123] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a00

[20861.882965] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd

[20861.899227] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a40

[20861.899232] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a00

[20892.924827] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd

[20892.941026] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a40

[20892.941031] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a00

[20892.941286] sd 10:0:0:0: [sdc] Unhandled error code

[20892.941291] sd 10:0:0:0: [sdc]  

[20892.941293] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK

[20892.941296] sd 10:0:0:0: [sdc] CDB: 

[20892.941297] Read(10): 28 00 1d 1c 60 d0 00 00 f0 00

[20892.941307] end_request: I/O error, dev sdc, sector 488399056

[20892.941312] Buffer I/O error on device sdc1, logical block 61049626

[20892.941315] Buffer I/O error on device sdc1, logical block 61049627

[20892.941318] Buffer I/O error on device sdc1, logical block 61049628

[20892.941320] Buffer I/O error on device sdc1, logical block 61049629

[20892.941322] Buffer I/O error on device sdc1, logical block 61049630

[20892.941325] Buffer I/O error on device sdc1, logical block 61049631

[20892.941327] Buffer I/O error on device sdc1, logical block 61049632

[20892.941330] Buffer I/O error on device sdc1, logical block 61049633

[20892.941332] Buffer I/O error on device sdc1, logical block 61049634

[20892.941334] Buffer I/O error on device sdc1, logical block 61049635

[20923.870747] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd

[20923.887139] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a40

[20923.887144] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a00

[20954.816739] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd

[20954.832967] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a40

[20954.832973] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a00

[20954.944569] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd

[20954.960825] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a40

[20954.960830] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8803b3629a00

[20980.219854] INFO: task flush-8:32:20128 blocked for more than 120 seconds.

[20980.219859] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

[20980.219861] flush-8:32      D ffff88042f393f40     0 20128      2 0x00000000

[20980.219866]  ffff88040e1517f0 0000000000000046 ffff88037ae40000 ffff88040e151fd8

[20980.219871]  ffff88040e151fd8 ffff88040e151fd8 ffff880418d5c5c0 ffff88037ae40000

[20980.219875]  ffff88037ae40000 ffff88042f3947f8 ffff880415552f10 ffff880415552ee0

[20980.219879] Call Trace:

[20980.219888]  [<ffffffff816ca8a9>] schedule+0x29/0x70

[20980.219892]  [<ffffffff816ca97f>] io_schedule+0x8f/0xd0

[20980.219897]  [<ffffffff81325a67>] get_request+0x197/0x6d0

[20980.219902]  [<ffffffff8107dc80>] ? finish_wait+0x80/0x80

[20980.219906]  [<ffffffff8132704d>] blk_queue_bio+0x7d/0x3d0

[20980.219909]  [<ffffffff813254b2>] generic_make_request+0xc2/0x110

[20980.219913]  [<ffffffff813257e9>] submit_bio+0x79/0x160

[20980.219917]  [<ffffffff811cac35>] ? bio_alloc_bioset+0x65/0x120

[20980.219922]  [<ffffffff811c5ea2>] submit_bh+0x112/0x1e0

[20980.219926]  [<ffffffff811c7d70>] __block_write_full_page+0x1e0/0x350

[20980.219929]  [<ffffffff811c7540>] ? __bread+0xa0/0xa0

[20980.219932]  [<ffffffff811cbd70>] ? I_BDEV+0x10/0x10

[20980.219935]  [<ffffffff811cbd70>] ? I_BDEV+0x10/0x10

[20980.219938]  [<ffffffff811c831b>] block_write_full_page_endio+0xfb/0x100

[20980.219942]  [<ffffffff811c8335>] block_write_full_page+0x15/0x20

[20980.219945]  [<ffffffff811cc3e8>] blkdev_writepage+0x18/0x20

[20980.219950]  [<ffffffff81138af3>] __writepage+0x13/0x40

[20980.219954]  [<ffffffff8113951a>] write_cache_pages+0x22a/0x460

[20980.219958]  [<ffffffff81138ae0>] ? mapping_tagged+0x20/0x20

[20980.219963]  [<ffffffff8113979a>] generic_writepages+0x4a/0x70

[20980.219967]  [<ffffffff8113a70e>] do_writepages+0x1e/0x40

[20980.219971]  [<ffffffff811bd8ab>] __writeback_single_inode+0x3b/0x160

[20980.219974]  [<ffffffff811be935>] writeback_sb_inodes+0x195/0x380

[20980.219978]  [<ffffffff811bebbf>] __writeback_inodes_wb+0x9f/0xd0

[20980.219982]  [<ffffffff811bee33>] wb_writeback+0x243/0x2c0

[20980.219986]  [<ffffffff811bfff8>] wb_do_writeback+0x158/0x200

[20980.219989]  [<ffffffff811c012b>] bdi_writeback_thread+0x8b/0x210

[20980.219993]  [<ffffffff811c00a0>] ? wb_do_writeback+0x200/0x200

[20980.219996]  [<ffffffff8107d370>] kthread+0xc0/0xd0

[20980.219999]  [<ffffffff8107d2b0>] ? kthread_create_on_node+0x120/0x120

[20980.220004]  [<ffffffff816d3fac>] ret_from_fork+0x7c/0xb0

[20980.220007]  [<ffffffff8107d2b0>] ? kthread_create_on_node+0x120/0x120

```

----------

## TomWij

Sounds like a bad hard drive, inspect the S.M.A.R.T. status with smartmontools.

----------

## naviathan

Bad hard drive? Bad Thumb Drive? Bad everything that I can plug into it and copy files to? Plug it into USB2 ports and it's fine. Even copies faster in USB2.

----------

## TomWij

Okay, I just now see this is regarding multiple external devices; if it were a single drive, it is very possible for USB 3 speeds to provoke this whereas USB 2 still runs fine. But well, as you describe it it ain't that.

Since this looks like a kernel bug, could you file it at https://bugs.gentoo.org and attach .config, two dmesgs and the package name and version of your kernel? Two dmesgs as in one with an external HDD, one with a USB thumb drive / stick; to cross-verify the common warnings and errors. We don't keep track or deeply look into bugs on our forum.

----------

## VinzC

I'm just stepping in and if that can help: what I'd do in this case would be install a bootable, small, live distribution on the USB drive (just the base system, a few megabytes) on a squashed file system to see if it is a hardware issue (especially on the motherboard) or anything else. You could then double check on other systems with USB3 if the same problem arises or not.

----------

## naviathan

I've run Gentoo and Ubuntu on this system both with the same problem. Had windows installed at one point with no issues so it looks like it's a problem with the kernel module for xhci.

----------

## VinzC

I meant on another system=machine.

EDIT: running windows and having no (apparent) issue with it still doesn't exclude a hardware problem. Having the same issue on a different hardware would definitely make sure it's a kernel bug.

----------

## naviathan

I only have one machine with USB3 and I don't know anyone with a similar machine.

----------

## Artcfox

I just built a new Haswell based system using a GIGABYTE Z87MX-D3H motherboard and I'm getting the same

```
xHCI xhci_drop_endpoint called with disabled ep
```

errors no matter if I'm using Gentoo, Ubuntu 13.10, or anything else. If I tried to transfer data to/from a drive, suddenly my USB 3.0 drives would disappear.

The only way I've been able to fix it is to disable XHCI in the BIOS, turning all of my USB 3.0 ports into USB 2.0 ports.

----------

## naviathan

Good, so I'm not loosing my mind.

----------

## rogerx

Getting the same thing here using USB-3 ports, but only when using VFAT partitions and not NTFS formatted partitions.

I've specified using shortname-mixed to enforce using the default codepage=437 without any success.

Seems the buffered writing to VFAT partitions is getting screwed-up, causing the USB reset.  I've heard within an earlier post elsewhere utf8 was causing problems with vfat, but that doesn't seem to be happening now.

Seems a similar bug was posted here with a kernel regression during kernel-3.3, and was supposedly fixed within kernel-3.4.  Now somebody else has just posted they now have this bug showing again within kernel-3.13, similar to this one.

2014.04.05: I've performed more testing, and it would appear mounting a NTFS partition using the USB-3.0 (AKA Superspeed) port offered far better write performance, alongside having no apparent problems compared to others' posts above using Linux 3.12.13-gentoo kernel. (I think from memory. ;-)  This problem seems to arise now only when writing FAT32 partitions using the USB-3.0 port.  Switching Fat32 partition to a USB-2.0 (AKA Highspeed) port, this problem or bug doesn't show itself.  Matter of fact after comparing FAT32 write performance between USB-2.0 an USB-3.0 ports, I think almost all USB-3 speed benefits are disabled (USB 3.0 port reverts to USB 2.0 speeds) when using a FAT32 partition on a USB-3.0 port!  (Albeit writing to a FAT32 partition using a USB-3.0 port under Windows 7 seems to appear more stable, and maybe slightly more robust at times.)  Think this whole bug has to deal more with the file system cache (or write buffer) during writing.  If the drive can't keep up with the write speed, something kernel/driver wise is quitting due to excessive write cache/buffers being used.  If you also do some research concerning write speeds for various partition types, you'll easily find NTFS outperforms FAT32 when comparing write speeds.  And, USB 3.0 (AKA Superspeed) speed factor seems to be triggering this with the FAT32 partition.  (Guess work.)

----------

## VinzC

Now, *that* is interesting. I also happen to transfer files onto the FAT part of my USB stick. I'll definitely avoid plugging it into the fastest port. (Too bad FAT is the only thing that many commercial device recognize BTW.)

----------

## Anon-E-moose

 *Quote:*   

> Matter of fact after comparing FAT32 write performance between USB-2.0 an USB-3.0 ports, I think almost all USB-3 speed benefits are disabled (USB 3.0 port reverts to USB 2.0 speeds) when using a FAT32 partition on a USB-3.0 port! 

 

The usb3 port will only go as fast as the device plugged into it.

It will use usb3 speeds when a usb3 device is plugged into it.

It will always use usb2 speeds when a usb2 device is plugged into it.

That's because of the extra connectors that define a usb1/2 device vs a usb3 device.

Having said that I regularly plug my usb2 devices into my usb3 port both ntfs and vfat partitions and have never had problems with any type corruption.

I am still running kernel 3.9.1 so that may be part of it.

----------

## rogerx

Using a 128GB USB 3.0 stick.

Seems there's also a good driver matching USB|HID driver pairing bug with the Intel USB xHCI devices within Windows 7.  To work around the resulting device manager hang, disabled the Intel xHCI (AKA USB 3.0) support within the BIOS for that chip.  Matter of fact, I just plan on disabling the Intel USB 3.0 support over all for all my operating systems.  Seems the other VIA & Etron USB 3.0 chips do publish updated drivers for all Windows 7 & XP versions, and the chips maybe a bit more stable.  But with this buffer bug under this thread, all (Intel, VIA, Etron, ...) USB 3.0 chips seem to be afflicted.  As they say, where there's smoke there's fire.

----------

## Anon-E-moose

My USB3 ports are "ASMedia Technology Inc. ASM1042"

That may be part of it too.

Edit to add: A couple of things I had forgotten about.

I had an add in usb3 controller that didn't work well with windows until I updated both the windows driver and the firmware on the card.

For onboard chipsets, I don't know if they can be firmware updated, but I would check with the board manufacturer for updated firmware/bios that addresses the usb3 ports.

Good luck

----------

## rogerx

Ditto concerning firmware, etc...  as to why I made mention of the Windows USB 3.0 driver stability issues, as everything is layered.  (ie. Hardware, Hardware firmware, software drivers, software UI or frontends, ...)  And both VIA and Etron have both released new drivers for 2014 for their USB 3.0 chipsets for Windows XP/7 platforms.  (Intel only released USB 3.0 chipset drivers for Windows 7/8, think also dated 2014 or late 2013.)  As to whether firmware is included is unknown, as most of the Windows' driver software is distributed within Executable formats which are not archived compressed EXE files.  (ie. 7z cannot open these driver Executable formated files.)

And speculating per Wikipedia USB 3.0 article, "Intel released its first chipset with integrated USB 3.0 ports in 2012 with the release of the Panther Point chipset. Some industry analysts have claimed that Intel was slow to integrate USB 3.0 into the chipset...", in which case my motherboard with three integrated USB 3.0 chips was released sometime within 2012, but this particular motherboard was likely manufactured in late 2012 or early 2013.  Hence, likely a bundle of joy here. ;-)

And as I do perform more copy tests, my eye is starting to seriously think USB 3.0 transfer rates for Fat32 is bumped down to USB 2.0 transfer rates under Windows 7, or very similar.  I should have probably tried using ext3/ext4 on the USB 3.0 128GB flash memory, as NTFS transferring was just apparently fine without signs of this bug.  That would have further pointed the finger at the possibility of a partition type specific bug.  And whomever fixed this particular NTFS regression mentioned on this thread, will likely understand the same thing is now happening to Fat16/32 partition types.  Anyways, this external device only supports Fat32 and the media has been successfully written to.  My testing is pretty much done.

----------

## AaronPPC

 *Anon-E-moose wrote:*   

> My USB3 ports are "ASMedia Technology Inc. ASM1042"

 

I have the same interface and it has worked flawlessly.  My experience is somewhat limited, but I have a 64GiB USB3 stick and I have not seen any corruption.  I even formatted it with NTFS when I bought it (odd that there is less hastle to do it with ntfs3g than under Windows 7, but I digress).  I have also used a USB3 SATA adapter (for use with internal hard drives) with no problems.

I am currently using pf-kernel 3.12.3.  I was thinking about updating the kernel, but I think I will wait and see how this thread shakes out.

----------

## rogerx

Gentoo kernel here, 3.12.13-gentoo

----------

## mmokrejs

Hi,

  you should have posted your:

0. re-post your kernel version, lspci, lsusb

1. lsusb -vvv output (of the XHCI controller and of the USB3.0 flaky device)

2. obtain your device firmware version, e.g. via AsmShowFwVersion_v1.0.zip (eventually think of firmware disabling drive sleeping, e.g. search for UASP1-130107.exe but do not flash it as it could be vendor specific, just learn what is it about)

3. post how is your device recognized by kernel and what quirks were enabled, e.g.

```
[   48.717605] usb 4-2.1: new SuperSpeed USB device number 3 using xhci_hcd

[   48.737729] usb 4-2.1: Parent hub missing LPM exit latency info.  Power management will be impacted.

[   48.743738] usb 4-2.1: New USB device found, idVendor=174c, idProduct=55aa

[   48.743740] usb 4-2.1: New USB device strings: Mfr=2, Product=3, SerialNumber=1

[   48.743742] usb 4-2.1: Product: ASMT1053

[   48.743743] usb 4-2.1: Manufacturer: asmedia

[   48.743745] usb 4-2.1: SerialNumber: 123456789012

[   48.745679] usb-storage 4-2.1:1.0: USB Mass Storage device detected

[   48.745768] usb-storage 4-2.1:1.0: Quirks match for vid 174c pid 55aa: 400000

[   48.750630] scsi7 : usb-storage 4-2.1:1.0

[   49.747342] scsi 7:0:0:0: Direct-Access     ASMT     2105             0    PQ: 0 ANSI: 6

[   49.748683] sd 7:0:0:0: Attached scsi generic sg3 type 0

[   49.751626] sd 7:0:0:0: [sdc] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)

[   49.751629] sd 7:0:0:0: [sdc] 4096-byte physical blocks

[   49.753251] sd 7:0:0:0: [sdc] Write Protect is off

[   49.753254] sd 7:0:0:0: [sdc] Mode Sense: 43 00 00 00

[   49.754872] sd 7:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

[   49.834353]  sdc: sdc1

[   49.844430] sd 7:0:0:0: [sdc] Attached SCSI disk
```

4. disable powersaving using /etc/default/grub and append to your kernel commandline to usbcore.autosuspend=-1

5. alternatively or in addition to 4., disable UASP in your kernel

----------

