Synchronisation/close /dev/sdX: i/o error on target host

[Bib]

Ubuntu 14.04.1 x86-64
wanting to unmout a pata drive (usb attached), I get this (title) "Warning from libparted" when gparted launches.
Same issue with another pc x86-64
Errors retries then ignore, shred /dev/sdi fails:

shred: /dev/sdi : pass 1/2 (random)…
shred: /dev/sdi : pass 1/2 (random)…231MiB/94GiB 0 %
shred: /dev/sdi : failure of fdatasync: i/o error on target host

I reached to shred the drive from a 12.04.4 i386 pc with no error.

Sep 7 15:07:08 nux kernel: [261448.072475] usb 5-1: new high-speed USB device number 10 using xhci_hcd
Sep 7 15:07:09 nux kernel: [261448.202999] usb 5-1: New USB device found, idVendor=04cf, idProduct=8818
Sep 7 15:07:09 nux kernel: [261448.203008] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 7 15:07:09 nux kernel: [261448.203013] usb 5-1: Product: USB Mass Storage Device
Sep 7 15:07:09 nux kernel: [261448.203018] usb 5-1: Manufacturer: Myson Century, Inc.
Sep 7 15:07:09 nux kernel: [261448.205463] usb-storage 5-1:1.0: USB Mass Storage device detected
Sep 7 15:07:09 nux kernel: [261448.205673] scsi20 : usb-storage 5-1:1.0
Sep 7 15:07:10 nux kernel: [261449.206849] scsi 20:0:0:0: Direct-Access HTS72101 0G9AT00 MCZO PQ: 0 ANSI: 0 CCS
Sep 7 15:07:10 nux kernel: [261449.207763] sd 20:0:0:0: Attached scsi generic sg7 type 0
Sep 7 15:07:10 nux kernel: [261449.207901] sd 20:0:0:0: [sdi] 195371568 512-byte logical blocks: (100 GB/93.1 GiB)
Sep 7 15:07:10 nux kernel: [261449.208068] sd 20:0:0:0: [sdi] Write Protect is off
Sep 7 15:07:10 nux kernel: [261449.208074] sd 20:0:0:0: [sdi] Mode Sense: 00 14 00 00
Sep 7 15:07:10 nux kernel: [261449.208280] sd 20:0:0:0: [sdi] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Sep 7 15:07:10 nux kernel: [261449.555232] sdi: unknown partition table
Sep 7 15:07:10 nux kernel: [261449.555926] sd 20:0:0:0: [sdi] Attached SCSI disk
Sep 7 15:07:43 nux kernel: [261482.219026] end_request: critical target error, dev sdi, sector 0
Sep 7 15:07:52 nux kernel: [261492.015180] end_request: critical target error, dev sdi, sector 0
Sep 7 15:07:55 nux kernel: [261494.261159] end_request: critical target error, dev sdi, sector 0
Sep 7 15:16:23 nux kernel: [262003.027005] end_request: critical target error, dev sdi, sector 0
Sep 7 15:16:35 nux kernel: [262014.215352] end_request: critical target error, dev sdi, sector 0
Sep 7 15:16:35 nux kernel: [262014.859651] end_request: critical target error, dev sdi, sector 0

[EDIT:
Once shreded, no error on the i386, but still same error on the 2 x86-64]

[Curtis Gedak (gedakc)]

These appear to be hardware errors. You might check to ensure that all cables are securely plugged in and then try again.

The output from the following command would also be useful:

    sudo parted -l

[Bib (bybeu)]

In the lap time, I got the very same behaviour with another pata drive, i.e. errors with 2 x86-64 14.04.1 PCs (one dektop and one laptop) and no error with my old i386 12.04.4 laptop. A strange fortune circumstance I notice just at the moment of writing is that the 2 drives were genuine from old PackardBell computers.

Sep 9 11:46:50 nux kernel: [422242.805648] usb 5-1: new high-speed USB device number 14 using xhci_hcd
Sep 9 11:46:50 nux kernel: [422242.940165] usb 5-1: New USB device found, idVendor=04cf, idProduct=8818
Sep 9 11:46:50 nux kernel: [422242.940174] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 9 11:46:50 nux kernel: [422242.940180] usb 5-1: Product: USB Mass Storage Device
Sep 9 11:46:50 nux kernel: [422242.940184] usb 5-1: Manufacturer: Myson Century, Inc.
Sep 9 11:46:50 nux kernel: [422242.942743] usb-storage 5-1:1.0: USB Mass Storage device detected
Sep 9 11:46:50 nux kernel: [422242.943033] scsi29 : usb-storage 5-1:1.0
Sep 9 11:46:51 nux kernel: [422243.946537] scsi 29:0:0:0: Direct-Access ST312002 2A 3.04 PQ: 0 ANSI: 0 CCS
Sep 9 11:46:51 nux kernel: [422243.947425] sd 29:0:0:0: Attached scsi generic sg7 type 0
Sep 9 11:46:51 nux kernel: [422243.947571] sd 29:0:0:0: [sdk] 234441648 512-byte logical blocks: (120 GB/111 GiB)
Sep 9 11:46:51 nux kernel: [422243.947734] sd 29:0:0:0: [sdk] Write Protect is off
Sep 9 11:46:51 nux kernel: [422243.947740] sd 29:0:0:0: [sdk] Mode Sense: 00 14 00 00
Sep 9 11:46:51 nux kernel: [422243.947895] sd 29:0:0:0: [sdk] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Sep 9 11:46:51 nux kernel: [422243.972855] sdk: unknown partition table
Sep 9 11:46:51 nux kernel: [422243.973712] sd 29:0:0:0: [sdk] Attached SCSI disk
Sep 9 11:47:45 nux kernel: [422298.195272] end_request: critical target error, dev sdk, sector 0
Sep 9 11:47:45 nux kernel: [422298.464477] end_request: critical target error, dev sdk, sector 0

I don't know what parted would say, as at the moment the "guilty" drives are shreded, no partitions at all, not even an empty table if even possible. Although:
sudo parted -l

Model: ATA MAXTOR STM316021 (scsi)
Disque /dev/sda : 160GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos

Numéro Début Fin Taille Type Système de fichiers Fanions
 1 1049kB 160GB 160GB primary ext4 démarrage

Modèle: ATA SAMSUNG HD321KJ (scsi)
Disque /dev/sdb : 320GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos

Numéro Début Fin Taille Type Système de fichiers Fanions
 1 1049kB 320GB 320GB primary ext4

Modèle: ATA Hitachi HDS72101 (scsi)
Disque /dev/sdc : 1000GB
Taille des secteurs (logiques/physiques): 512B/4096B
Table de partitions : msdos

Numéro Début Fin Taille Type Système de fichiers Fanions
 1 1049kB 4000MB 3999MB primary linux-swap(v1)
 2 4000MB 990GB 986GB primary ext4
 3 990GB 995GB 5000MB primary ext4
 4 995GB 1000GB 5204MB primary ext4

Erreur: Impossible d'ouvrir /dev/sdk - étiquette de disque non reconnue.
Avertissement: Erreur de synch...

[Bib (bybeu)]

I attached the drive on the pci host adapter : no error
I also tried to attach it with the usb adaptator to a usb2 mobo port instead of an usb3 : errors again. The strange is that I don't get errors with the same cable+usb adaptator when I plug that stack into my i386 12.04.4.

[Phillip Susi (psusi)]

Yep, these are hardware errors; nothing to do with parted.

One of the many down sides to USB attached storage is that they do not do proper error reporting so you can diagnose the problem. They simply fail with no explanation.

[Bib (bybeu)]

Hi Phillip
So why do the drives work fine OK when usb attached to a 12.04.4 i386 laptop?

[Phillip Susi (psusi)]

Without being able to troubleshoot the setup I can not say; I only know that the kernel is saying there was a hardware error, so there's nothing parted can do.

[Martien (sbtsnlag)]

Please remove the "Invalid" status from this ticket. I can confirm that this is a linux kernel issue. This happened to me:

1) Attached a external USB harddrive (an 'oldie': the Lacie 250GB) to PC running Ubuntu 14.04.1 with latest kernel update installed.
2) Formatted the harddrive to ext4, already seeing "end_request: critical target error, dev sdX, sector 0" kernel messages.
3) Installed Ubuntu 14.04.1 to the USB harddrive (by booting the Ubuntu 14.04.1 live installer from a USB stick).
4) Booted from the USB harddrive - no problems at all.
5) Updated ONLY the linux-* packages of the Ubuntu running on the USB harddrive.
6) Rebooted the USB harddrive (which auto-selects the latest kernel version in grub), and the filesystem got completely corruppted.

Please note that a VFAT filesystem doesn't get corrupted, but the "end_request: critical target error, dev sdX, sector 0" messages also appear in the syslog.

Also tested the following:
1) Ubuntu 14.10 - same issue.
2) openSUSE 13.2 Factory (latest live version) - same issue.

Searching the internet showed that other distributions have the same issue, e.g.:
- Raspberry Pi: https://github.com/raspberrypi/linux/issues/703
- Ubuntu 14.04: http://unix.stackexchange.com/questions/156704/cannot-mount-fresh-partition-twice
- Ubuntu 14.04: with kernel version .35: Bug #1368299
- Xubuntu 14.04: http://ubuntuforums.org/showthread.php?t=2243515
- I also came accros Arch-Linux and Debian-Linux pages describing the same error, but can't find them atm, sorry for that.

If you need more details, please let me know, I will be happy to provide them.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.18 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-rc3-vivid/

[gianluca (amato)]

I tried with the new kernel, but I have the same issue. I also tried with a Fedora 21: also same issue.

[Bib (bybeu)]

I smell the bissection request...

[Martien (sbtsnlag)]

Changed status to "Confirmed", since it was found in the new kernel:

<quote>
gianluca (amato) wrote on 2014-11-03: #10

I tried with the new kernel, but I have the same issue.
</quote>

[Bib (bybeu)]

Just a comment about the text in bug description: the shred thing WAS NOT about any workaround purpose, it was just what I first wanted to do when I plugged the drive.

[TwinPrimes (twin-primes)]

I can add another data point: Same thing happened to me. I have a 300GB external Seagate drive that was working fine for a few years with no problems attached to the USB 2.0 port of my Gigabyte motherboard. After upgrading to 14.04 with kernel 3.13.0-39-generic (64-bit) the drive switches to read-only FS after the first write operation and I see a number of "end_request: critical target error" messages in kern.log.

The drive also has a firewire port, so I unplugged the USB cable and plugged in a Firewire cable and now all is well. I've written multiple GBs to it with no problems. The only issue is that the throughput is substantially lower now -- around 25 MB/s compared to around 43 MB/s I was seeing before with USB but I can live with that for a while.

[gianluca (amato)]

The culprit is the upgrade to 3.13.0-35. Until -34 it works fine. I am trying the mainline kernels to see when the regression happens there.

[gianluca (amato)]

In the mainline kernel (not really mainline, because it is an extended version maintained by Canonical), the problem occurs between 3.13.11.5 and 3.13.11.6. I checked the git logs, but I am not expert enough to understand which commit may be the cause of the problem. I'll try to git bisect when I have some time.

[gianluca (amato)]

I found the commit which causes this error.

commit 1918a05d9621d9659783dfaf7b009f873e835d53
Author: James Bottomley <email address hidden>
Date: Thu Jul 3 19:17:34 2014 +0200

    scsi: handle flush errors properly

    commit 89fb4cd1f717a871ef79fa7debbe840e3225cd54 upstream.

    Flush commands don't transfer data and thus need to be special cased
    in the I/O completion handler so that we can propagate errors to
    the block layer and filesystem.

    Signed-off-by: James Bottomley <email address hidden>
    Reported-by: Steven Haber <email address hidden>
    Tested-by: Steven Haber <email address hidden>
    Reviewed-by: Martin K. Petersen <email address hidden>
    Signed-off-by: Christoph Hellwig <email address hidden>
    Signed-off-by: Kamal Mostafa <email address hidden>

[Bib (bybeu)]

Great gianluca, far better than peremtory autistic "hardware error" that didn't even take into account circumstances (trusty 64 KO vs precise 32 OK).
Thank you.

[Joseph Salisbury (jsalisbury)]

I built a Trusty test kernel with a revert of the commit mentioned in comment #18. Can you test this kernel and confirm it fixes this bug?

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1366538/

This is commit d215f91 in the Trusty repo.

[gianluca (amato)]

Joseph, your kernel works for me.

[Steven Haber (sthaber)]

Hello! I found the original bug and proposed the original patch to the kernel SCSI guys. Here's some context:

The SCSI flush command was being treated by a zero-byte write, which means that if an error was returned, you wouldn't catch it until a subsequent write (or flush). The way writes work is that all possible bytes are written, and if something bad happens, an error bubbles out on the next write attempt. This holds true even for a zero-byte write. This means that before this bug, to guarantee durability you had to flush twice (and verify both were error-free). I'm working on a storage appliance that relies on the fact that a single flush command guarantees a write made durably to a SCSI device. I'm sure many other storage products rely on this behavior, too.

I'm not sure why certain USB drives are failing in the flush path on unmount. Since the flush bug existed for such a long time, I suspect certain drivers coded around this behavior, and now that it is correct we are seeing new bugs exposed.

Based on the simplicity and obviousness of our patch for the flush bug, it would really be ideal to diagnose this further rather than reverting.

[Steven Haber (sthaber)]

The patch James shipped fixes this bug by special-casing the flush error path. Before flush wouldn't return errors; now it does.

[brad haack (bradhaack-g)]

Is this patch going to be incorporated soon? I have 2 USB drive that are useless until this is fixed. 'Importance' is more than medium for me!

[kaefert (kaefert)]

manually installing all the deb packages from
http://kernel.ubuntu.com/~jsalisbury/lp1366538/

fixes the issue for me on linux mint 17.1

[brad haack (bradhaack-g)]

Is installing the jsalisbury test kernel the recommended fix for a user at this time?

[Joseph Salisbury (jsalisbury)]

I'm trying to reproduce this issue to gather addition data. Can folks affected by this bug attach the section of syslog that is generated after attaching the external USB drive.

Specifically, I'm looking to see if the Write cache is enabled or disabled.

For example, my syslog shows the cache is disabled:

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

I see that the original bug reporter shows that the write cache is enable, so I'm wondering if that is required to reproduce this:
Sep 7 15:07:10 nux kernel: [261449.208280] sd 20:0:0:0: [sdi] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

[brad haack (bradhaack-g)]

syslog:

Feb 1 19:21:12 dt1 kernel: [ 5378.841282] usb 1-1.4: new high-speed USB device number 4 using ehci-pci
Feb 1 19:21:12 dt1 kernel: [ 5378.934784] usb 1-1.4: New USB device found, idVendor=0d49, idProduct=7110
Feb 1 19:21:12 dt1 kernel: [ 5378.934788] usb 1-1.4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
Feb 1 19:21:12 dt1 kernel: [ 5378.934790] usb 1-1.4: Product: OneTouch II
Feb 1 19:21:12 dt1 kernel: [ 5378.934792] usb 1-1.4: Manufacturer: Maxtor
Feb 1 19:21:12 dt1 kernel: [ 5378.934794] usb 1-1.4: SerialNumber: B203Y4HH
Feb 1 19:21:12 dt1 kernel: [ 5378.935181] usb-storage 1-1.4:1.0: USB Mass Storage device detected
Feb 1 19:21:12 dt1 kernel: [ 5378.935557] scsi5 : usb-storage 1-1.4:1.0
Feb 1 19:21:12 dt1 mtp-probe: checking bus 1, device 4: "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4"
Feb 1 19:21:12 dt1 mtp-probe: bus: 1, device: 4 was not an MTP device
Feb 1 19:21:13 dt1 kernel: [ 5379.986719] scsi 5:0:0:0: Direct-Access Maxtor OneTouch II 023g PQ: 0 ANSI: 4
Feb 1 19:21:13 dt1 kernel: [ 5379.987148] sd 5:0:0:0: Attached scsi generic sg2 type 0
Feb 1 19:21:13 dt1 kernel: [ 5380.040401] sd 5:0:0:0: [sdb] 195813072 512-byte logical blocks: (100 GB/93.3 GiB)
Feb 1 19:21:13 dt1 kernel: [ 5380.094154] sd 5:0:0:0: [sdb] Write Protect is off
Feb 1 19:21:13 dt1 kernel: [ 5380.094159] sd 5:0:0:0: [sdb] Mode Sense: 24 00 00 00
Feb 1 19:21:13 dt1 kernel: [ 5380.147874] sd 5:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Feb 1 19:21:13 dt1 kernel: [ 5380.328920] sdb: sdb1
Feb 1 19:21:14 dt1 kernel: [ 5380.507089] sd 5:0:0:0: [sdb] Attached SCSI disk

[Joseph Salisbury (jsalisbury)]

Can you post the output of:
sudo hdparm -I /dev/sdb

or what ever sdN is if it changes?

Also, can you see if setting the cache off makes the bug go away? It can be done with:
sudo hdparm -W0 /dev/sdc

To confirm it is off, you can run:
sudo hdparm -W /dev/sdc

[brad haack (bradhaack-g)]

Can't seem to turn off write caching.

~
dt1:sudo hdparm -I /dev/sdc1

/dev/sdc1:
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

ATA device, with non-removable media
 Model Number: ��+@�Z#��C����`@�������`�O�@�_�@��=�����
 Serial Number: i`�ih���I@�k= �l��
 Firmware Revision: ����퉠
�� Media Serial Num: Ơ��K���`��,���|�
  ���`
 Media Manufacturer: ���Š��
��`���
 Transport: Parallel; Revision: 0xf4bb
Standards:
 Used: unknown (minor revision code 0xf35e)
 Supported: 12 10
 Likely used: 12
Configuration:
 CHS addressing not supported
 LBA user addressable sectors: 4085503040
 Logical Sector size: 3431065366 bytes
 Physical Sector size: 3431065366 bytes
 device size with M = 1024*1024: 13368250701391 MBytes
 device size with M = 1000*1000: 14017626847461 MBytes (14017626847 GB)
 cache/buffer size = unknown
 Nominal Media Rotation Rate: 62291
Capabilities:
 LBA, IORDY(may be)(cannot be disabled)
 Queue depth: 13
 Standby timer values: spec'd by Standard, no device specific minimum
 R/W multiple sector transfer: Max = 129 Current = 94
 Recommended acoustic management value: 68, current value: 32
 DMA: *mdma0 *mdma1 mdma3 *mdma4 *mdma5 *mdma6 *mdma7 (?)
      Cycle time: min=62312ns recommended=57024ns
 PIO: pio0 pio1 pio2
      Cycle time: no flow control=62367ns IORDY flow control=41600ns
    * reserved 69[2]
    * reserved 69[3]
    * reserved 69[4]
    * reserved 69[6]
    * DOWNLOAD MICROCODE DMA command
    * SET MAX SETPASSWORD/UNLOCK DMA commands
    * DEVICE CONFIGURATION SET/IDENTIFY DMA commands
    * Long physical sector diagnostics
    * CFast specification support
    * Data Set Management TRIM supported (limit 62355 blocks)
    * Deterministic read ZEROs after TRIM
  Removable Media Status Notification feature set supported
Security:
 Master password revision code = 34944
 not supported
 not enabled
 not locked
 not frozen
 not expired: security count
  supported: enhanced erase
Integrity word not set (found 0xf371, expected 0x88a5)
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Device Sleep:
 DEVSLP Exit Timeout (DETO): 20 ms (default)
 Minimum DEVSLP Assertion Time (MDAT): 10 ms (default)
~
~
dt1:sudo hdparm -W /dev/sdc1

/dev/sdc1:
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 write-caching = not supported
~
~
dt1:sudo hdparm -W0 /dev/sdc1

/dev/sdc1:
 setting drive write-caching to 0 (off)
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00...

[brad haack (bradhaack-g)]

These are consecutive cmds, wirte cach goes from on, to not supported, to off . Further tries for this show that it seems random.

~
dt1:sudo hdparm -W /dev/sdc

/dev/sdc:
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 write-caching = 1 (on)
~
dt1:sudo hdparm -W /dev/sdc

/dev/sdc:
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 write-caching = not supported
~
dt1:sudo hdparm -W /dev/sdc

/dev/sdc:
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 write-caching = 0 (off)

[jmp (jmp-v)]

I use a Maxtor OneTouch 250GB, and can confirm the previous reports:
even an fsck that returns "clean" (ext3 partition inside) is followed by 2 errors like:

end_request: critical target error, dev sdX, sector 0

Any subsequent fsck turns off the journal and finds many previously non existent errors.
All consistent with the diagnose and explanations given (see dmesg log below).

(Can't run smartmontools nor hdparm, "unsupported USB bridge").

Tried with all trusty linux-image updates since 3.13.0-35, even linux-image-generic-lts-utopic
(3.16.0.31.24) . All have this bug.

Reinstalled 3.13.0-34 just to be able to use this drive. It's really unfortunate that kernel maintainers refuse to fix this; seems my Ubuntus are stuck with this version 3.13.0-34 then.

Relevant dmesg:

[ 935.744030] usb 1-2: new high-speed USB device number 3 using ehci-pci
[ 935.876881] usb 1-2: New USB device found, idVendor=0d49, idProduct=7010
[ 935.876885] usb 1-2: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[ 935.876888] usb 1-2: Product: OneTouch
[ 935.876890] usb 1-2: Manufacturer: Maxtor
[ 935.876893] usb 1-2: SerialNumber: Y61JF0XE
[ 935.943600] usbcore: registered new interface driver usb-storage
[ 935.958880] usbcore: registered new interface driver uas
[ 935.960525] ums-onetouch 1-2:1.0: USB Mass Storage device detected
[ 935.960754] input: Maxtor OneTouch as /devices/pci0000:00/0000:00:1a.7/usb1/1-2/input/input11
[ 935.961336] scsi6 : usb-storage 1-2:1.0
[ 935.961819] usbcore: registered new interface driver ums-onetouch
[ 937.166087] scsi 6:0:0:0: Direct-Access Maxtor OneTouch 0200 PQ: 0 ANSI: 0 CCS
[ 937.168548] sd 6:0:0:0: Attached scsi generic sg3 type 0
[ 937.169183] sd 6:0:0:0: [sdc] 490232832 512-byte logical blocks: (250 GB/233 GiB)
[ 937.375463] sd 6:0:0:0: [sdc] Write Protect is off
[ 937.375468] sd 6:0:0:0: [sdc] Mode Sense: 1c 00 00 00
[ 937.581825] sd 6:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 938.025841] sdc: sdc1
[ 938.469132] sd 6:0:0:0: [sdc] Attached SCSI disk
[ 1060.257726] end_request: critical target error, dev sdc, sector 0
[ 1060.260096] end_request: critical target error, dev sdc, sector 0
[ 1091.387256] usb 1-2: USB disconnect, device number 3
[ 1091.387810] sd 6:0:0:0: [sdc] Synchronizing SCSI cache
[ 1091.387842] sd 6:0:0:0: [sdc]
[ 1091.387845] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK

[jkampe (jkampe)]

I can confirm same with old LACIE 250GB

However adding usb-storage quirks 'uw' for it _may_ work around the issue;
e.g. add (just substitute vendor and product id for yours)

options usb-storage quirks=059f:0651:uw

dmesg with above quirks / kernel 3.16.0-31-generic
[ 57.952732] usb 2-4: new high-speed USB device number 3 using ehci-pci
[ 58.085433] usb 2-4: New USB device found, idVendor=059f, idProduct=0651
[ 58.085442] usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 58.085447] usb 2-4: Product: LaCie Hard Drive USB
[ 58.085451] usb 2-4: Manufacturer: LaCie
[ 58.085454] usb 2-4: SerialNumber: 10000E000CD8F66F
[ 58.086821] usb-storage 2-4:1.0: USB Mass Storage device detected
[ 58.088781] usb-storage 2-4:1.0: Quirks match for vid 059f pid 0651: 800200
[ 58.088857] scsi11 : usb-storage 2-4:1.0
[ 59.088892] scsi 11:0:0:0: Direct-Access SEAGATE ST3250820A 3.AA PQ: 0 ANSI: 2
[ 59.089927] sd 11:0:0:0: Attached scsi generic sg5 type 0
[ 59.090800] sd 11:0:0:0: [sdf] 488397168 512-byte logical blocks: (250 GB/232 GiB)
[ 59.090805] sd 11:0:0:0: [sdf] Assuming Write Enabled
[ 59.090808] sd 11:0:0:0: [sdf] Assuming drive cache: write through
[ 59.110410] sdf: sdf1
[ 59.112295] sd 11:0:0:0: [sdf] Attached SCSI disk

relevant dmesg _without_ quirks;
[12768.255738] usb 2-4: new high-speed USB device number 3 using ehci-pci
[12768.388658] usb 2-4: New USB device found, idVendor=059f, idProduct=0651
[12768.388667] usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[12768.388672] usb 2-4: Product: LaCie Hard Drive USB
[12768.388676] usb 2-4: Manufacturer: LaCie
[12768.388679] usb 2-4: SerialNumber: 10000E000CD8F66F
[12768.389259] usb-storage 2-4:1.0: USB Mass Storage device detected
[12768.389422] usb-storage 2-4:1.0: Quirks match for vid 059f pid 0651: 908420
[12768.389475] scsi11 : usb-storage 2-4:1.0
[12769.387735] scsi 11:0:0:0: Direct-Access SEAGATE ST3250820A 3.AA PQ: 0 ANSI: 2
[12769.388477] sd 11:0:0:0: Attached scsi generic sg5 type 0
[12769.389527] sd 11:0:0:0: [sdf] 488397168 512-byte logical blocks: (250 GB/232 GiB)
[12769.395049] sd 11:0:0:0: [sdf] Write Protect is off
[12769.395056] sd 11:0:0:0: [sdf] Mode Sense: 53 00 00 08
[12769.397128] sd 11:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[12769.423794] sdf: sdf1
[12769.427236] sd 11:0:0:0: [sdf] Attached SCSI disk

[jmp (jmp-v)]

jkampe: I tried your workaround of adding usb-storage quirks 'uw' with my Maxtor OneTouch 250GB, same kernel as yours (3.16.0-31-generic #43~14.04.1-Ubuntu - x86_64). So far,

IT WORKS.

I'll have to test it further: I'm still running a (lengthy as in hours long) fsck caused by the previous test _without_ the quirks parameter ("filesystem with errors," etc.). But it does look good, I attached and detached the disk several times without the dreaded "end_request: critical target error, dev sdc, sector 0" that spelled trouble every time.

(In this case,
$ cat /etc/modprobe.d/maxtor-quirks.conf
options usb-storage quirks=0d49:7010:uw
)

I confirm the difference in dmesg, the line

(...) Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

changes to

(...) Assuming drive cache: write through

-- As it should, I think, since this disk does not expose any caches/cache control to the kernel. But what do I know?

Relevant messages:

[ 1301.964044] usb 1-2: new high-speed USB device number 5 using ehci-pci
[ 1302.096937] usb 1-2: New USB device found, idVendor=0d49, idProduct=7010
[ 1302.096940] usb 1-2: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[ 1302.096943] usb 1-2: Product: OneTouch
[ 1302.096945] usb 1-2: Manufacturer: Maxtor
[ 1302.096948] usb 1-2: SerialNumber: Y61JF0XE
[ 1302.117520] usbcore: registered new interface driver usb-storage
[ 1302.119336] usbcore: registered new interface driver uas
[ 1302.120923] ums-onetouch 1-2:1.0: USB Mass Storage device detected
[ 1302.121003] ums-onetouch 1-2:1.0: Quirks match for vid 0d49 pid 7010: 800200
[ 1302.121070] input: Maxtor OneTouch as /devices/pci0000:00/0000:00:1a.7/usb1/1-2/input/input13
[ 1302.121215] scsi9 : usb-storage 1-2:1.0
[ 1302.121303] usbcore: registered new interface driver ums-onetouch
[ 1303.326245] scsi 9:0:0:0: Direct-Access Maxtor OneTouch 0200 PQ: 0 ANSI: 0 CCS
[ 1303.326528] sd 9:0:0:0: Attached scsi generic sg3 type 0
[ 1303.327979] sd 9:0:0:0: [sdc] 490232832 512-byte logical blocks: (250 GB/233 GiB)
[ 1303.327984] sd 9:0:0:0: [sdc] Assuming Write Enabled
[ 1303.327987] sd 9:0:0:0: [sdc] Assuming drive cache: write through
[ 1303.362025] sdc: sdc1
[ 1303.363363] sd 9:0:0:0: [sdc] Attached SCSI disk

Thank you three times. This is some wizard level advice. :-) I never had heard about that "quirks" parameter... Let alone what might the value "uw" do.

[brad haack (bradhaack-g)]

Can someone outline for a noob how to use usb-storage quirks. I'd like to get my Maxtor working. thx

[Christopher A. Chavez (chrstphrchvz)]

I have used this workaround for a LaCie DVD RW (being used as a USB hard drive adapter): 059f:0363 (I obtain the usb id for my particular enclosure using `lsusb`).

 - For temporarily adding the quirks, I stop the kernel module: `modprobe -r usb-storage` (I may also need to stop dependent kernel modules, e.g. `modprobe -r uas` beforehand), and then restart with quirks: `modprobe usb-storage quirks=059f:0363:uw`.

 - For permanently adding the quirks, I followed the suggest in #34 where I use e.g. `sudo sh -c 'echo "options usb-storage quirks=059f:0363:uw" > /etc/modprobe.d/lacie-quirks.conf'`. Replace 059f:0363 with usb id for your enclosure, and maybe call it "maxtor-quirks.conf" if that's what you have.

[brad haack (bradhaack-g)]

Thanks, I tried that & there was no change. I got it working with
sudo -s
echo 'temporary write through' > /sys/block/sdb/device/scsi_disk/*/cache_type

It seems to be permanent :)

[jkampe (jkampe)]

To verify if quirks parameter is in place inspect `dmesg` _after_ plugging in the device.
You should have a line indicating "quirks match" for your device - e.g. (in my case)

[ 2266.284812] usb-storage 8-4:1.0: USB Mass Storage device detected
[ 2266.284979] usb-storage 8-4:1.0: Quirks match for vid 059f pid 0651: 800200

If not check if the module was loaded with quirks parameter by
`cat /sys/module/usb_storage/parameters/quirks`

You may need to update initramfs if the device is plugged in while booting.

[cgrote (curtiswgrote)]

I have also experienced this problem with a USB connected Seagate ST3300601CB-RK 300 GB external hard drive. The issue is still present in Ubuntu Server 13.10 with kernel level 4.2.0-30-generic. Using the command suggested by Brad in #37 above fixed the problem. I have not rebooted to see if the fix persists.

echo 'temporary write through' > /sys/block/sde/device/scsi_disk/*/cache_type

[Rolf Leggewie (r0lf)]

utopic has seen the end of its life and is no longer receiving any updates. Marking the utopic task for this ticket as "Won't Fix".

[Andy Whitcroft (apw)]

This bug was nominated against a series that is no longer supported, ie vivid. The bug task representing the vivid nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.