Skip to contentSkip to conversation

External USB3 disk fails with "Invalid field in cdb"

PATCH In review Michael Büsch 6 participants 16 messages Jun 26, 2014 – Jun 30, 2014 2 messages not in the archive

Subsystems (3)
SCSI USB USB mass storage driver
lore
Share & tools
lore

Michael Büsch

author
#0 lore raw

Hi,

I got a new USB3->SATA adapter that throws the following errors when trying to mount the ext4 file system on the attached disk.

Jun 26 20:47:11 wiggum kernel: [156016.840175] usb 4-2: new SuperSpeed USB device number 8 using xhci_hcd
Jun 26 20:47:11 wiggum kernel: [156016.856962] usb 4-2: New USB device found, idVendor=152d, idProduct=0567
Jun 26 20:47:11 wiggum kernel: [156016.856969] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun 26 20:47:11 wiggum kernel: [156016.856972] usb 4-2: Product: USB to ATA/ATAPI Bridge
Jun 26 20:47:11 wiggum kernel: [156016.856975] usb 4-2: Manufacturer: JMicron
Jun 26 20:47:11 wiggum kernel: [156016.856977] usb 4-2: SerialNumber: xxx
Jun 26 20:47:11 wiggum kernel: [156016.858030] usb-storage 4-2:1.0: USB Mass Storage device detected
Jun 26 20:47:11 wiggum kernel: [156016.858141] scsi22 : usb-storage 4-2:1.0
Jun 26 20:47:12 wiggum kernel: [156017.857096] scsi 22:0:0:0: Direct-Access     JMicron  Generic          0114 PQ: 0 ANSI: 6
Jun 26 20:47:12 wiggum kernel: [156017.857427] sd 22:0:0:0: Attached scsi generic sg1 type 0
Jun 26 20:47:12 wiggum kernel: [156017.860670] sd 22:0:0:0: [sdb] Spinning up disk...
Jun 26 20:47:14 wiggum kernel: [156018.865281] ..ready
Jun 26 20:47:14 wiggum kernel: [156019.870310] sd 22:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/465 GiB)
Jun 26 20:47:14 wiggum kernel: [156019.870653] sd 22:0:0:0: [sdb] Write Protect is off
Jun 26 20:47:14 wiggum kernel: [156019.870659] sd 22:0:0:0: [sdb] Mode Sense: 47 00 10 08
Jun 26 20:47:14 wiggum kernel: [156019.870956] sd 22:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
Jun 26 20:47:14 wiggum kernel: [156019.924517]  sdb: sdb1
Jun 26 20:47:14 wiggum kernel: [156019.928649] sd 22:0:0:0: [sdb] Attached SCSI disk
Jun 26 20:47:27 wiggum kernel: [156032.936896] JBD2: Clearing recovery information on journal
Jun 26 20:47:27 wiggum kernel: [156032.938218] sd 22:0:0:0: [sdb] Invalid command failure
Jun 26 20:47:27 wiggum kernel: [156032.938222] sd 22:0:0:0: [sdb]
Jun 26 20:47:27 wiggum kernel: [156032.938225] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jun 26 20:47:27 wiggum kernel: [156032.938228] sd 22:0:0:0: [sdb]
Jun 26 20:47:27 wiggum kernel: [156032.938230] Sense Key : Illegal Request [current]
Jun 26 20:47:27 wiggum kernel: [156032.938234] sd 22:0:0:0: [sdb]
Jun 26 20:47:27 wiggum kernel: [156032.938237] Add. Sense: Invalid field in cdb
Jun 26 20:47:27 wiggum kernel: [156032.938239] sd 22:0:0:0: [sdb] CDB:
Jun 26 20:47:27 wiggum kernel: [156032.938241] Write(10): 2a 08 1d 04 00 3f 00 00 08 00
Jun 26 20:47:27 wiggum kernel: [156032.938247] end_request: critical target error, dev sdb, sector 486801471
Jun 26 20:47:27 wiggum kernel: [156032.938249] Buffer I/O error on device sdb1, logical block 60850176
Jun 26 20:47:27 wiggum kernel: [156032.938251] lost page write due to I/O error on sdb1
Jun 26 20:47:27 wiggum kernel: [156032.938260] JBD2: Error -5 detected when updating journal superblock for sdb1-8.

Does somebody have a hint to debug this?

Signature · 1 line
Michael.
#1 lore raw
Quoted 3 lines · Michael Büsch
Jun 26 20:47:14 wiggum kernel: [156019.870310] sd 22:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/465 GiB)
Jun 26 20:47:14 wiggum kernel: [156019.870653] sd 22:0:0:0: [sdb] Write Protect is off
Jun 26 20:47:14 wiggum kernel: [156019.870659] sd 22:0:0:0: [sdb] Mode Sense: 47 00 10 08

The disk says it supports FUA:

Quoted 8 lines
Jun 26 20:47:14 wiggum kernel: [156019.870956] sd 22:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
Jun 26 20:47:14 wiggum kernel: [156019.924517]  sdb: sdb1
Jun 26 20:47:14 wiggum kernel: [156019.928649] sd 22:0:0:0: [sdb] Attached SCSI disk
Jun 26 20:47:27 wiggum kernel: [156032.936896] JBD2: Clearing recovery information on journal
Jun 26 20:47:27 wiggum kernel: [156032.938218] sd 22:0:0:0: [sdb] Invalid command failure
Jun 26 20:47:27 wiggum kernel: [156032.938222] sd 22:0:0:0: [sdb]
Jun 26 20:47:27 wiggum kernel: [156032.938225] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jun 26 20:47:27 wiggum kernel: [156032.938228] sd 22:0:0:0: [sdb]

The disk doesn't like the command we sent it:

Quoted 3 lines
Jun 26 20:47:27 wiggum kernel: [156032.938230] Sense Key : Illegal Request [current]
Jun 26 20:47:27 wiggum kernel: [156032.938234] sd 22:0:0:0: [sdb]
Jun 26 20:47:27 wiggum kernel: [156032.938237] Add. Sense: Invalid field in cdb

Looks like a WRITE(10) with the FUA bit set:

Quoted 4 lines
Jun 26 20:47:27 wiggum kernel: [156032.938239] sd 22:0:0:0: [sdb] CDB:
Jun 26 20:47:27 wiggum kernel: [156032.938241] Write(10): 2a 08 1d 04 00 3f 00 00 08 00

Does somebody have a hint to debug this?

I'd guess the device lies about supporting FUA. There seems to be another report on the Debian lists of the same problem with a similar JMicron enclosure:

https://lists.debian.org/debian-user/2014/05/msg02066.html

Regards,
Bryn.

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

author
#2 lore raw

Thanks for your analysis.

Quoted 6 lines · On Fri, 27 Jun 2014 11:15:41 +0100 "Bryn M. Reeves" <[email protected]> wrote:
Quoted 3 lines · Michael Büsch
Jun 26 20:47:14 wiggum kernel: [156019.870310] sd 22:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/465 GiB)
Jun 26 20:47:14 wiggum kernel: [156019.870653] sd 22:0:0:0: [sdb] Write Protect is off
Jun 26 20:47:14 wiggum kernel: [156019.870659] sd 22:0:0:0: [sdb] Mode Sense: 47 00 10 08

The disk says it supports FUA:

Is this the disk reporting that, or the USB->SATA controller?

The disk works perfectly fine, if connected via on board SATA controller.

Quoted 10 lines

Looks like a WRITE(10) with the FUA bit set:

Quoted 4 lines
Jun 26 20:47:27 wiggum kernel: [156032.938239] sd 22:0:0:0: [sdb] CDB:
Jun 26 20:47:27 wiggum kernel: [156032.938241] Write(10): 2a 08 1d 04 00 3f 00 00 08 00

Does somebody have a hint to debug this?

I'd guess the device lies about supporting FUA. There seems to be another report on the Debian lists of the same problem with a similar JMicron enclosure:

Is there a workaround for this problem, or even a quirk-patch that I could test?

Signature · 1 line
Michael.
author
#3 lore raw

I tried the following patch:

drivers/scsi/sd.c +1 -1
Index: linux/drivers/scsi/sd.c
===================================================================
@@ -2440,7 +2440,7 @@ sd_read_cache_type(struct scsi_disk *sdk
 			sdkp->RCD = 0;
 		}
 
-		sdkp->DPOFUA = (data.device_specific & 0x10) != 0;
+		sdkp->DPOFUA = 0;
 		if (sdkp->DPOFUA && !sdkp->device->use_10_for_rw) {
 			sd_first_printk(KERN_NOTICE, sdkp,
 				  "Uses READ/WRITE(6), disabling FUA\n");

This obviously is not the correct thing to do, but it makes the disk usable:

Jun 27 17:26:50 marge kernel: [  523.909815] usb 2-1: new SuperSpeed USB device number 2 using xhci_hcd
Jun 27 17:26:50 marge kernel: [  523.929246] usb 2-1: New USB device found, idVendor=152d, idProduct=0567
Jun 27 17:26:50 marge kernel: [  523.929258] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun 27 17:26:50 marge kernel: [  523.929265] usb 2-1: Product: USB to ATA/ATAPI Bridge
Jun 27 17:26:50 marge kernel: [  523.929271] usb 2-1: Manufacturer: JMicron
Jun 27 17:26:50 marge kernel: [  523.929276] usb 2-1: SerialNumber: xxx
Jun 27 17:26:50 marge kernel: [  523.930999] usb-storage 2-1:1.0: USB Mass Storage device detected
Jun 27 17:26:50 marge kernel: [  523.931237] scsi12 : usb-storage 2-1:1.0
Jun 27 17:26:51 marge kernel: [  524.930451] scsi 12:0:0:0: Direct-Access     JMicron  Generic          0114 PQ: 0 ANSI: 6
Jun 27 17:26:51 marge kernel: [  524.931228] sd 12:0:0:0: Attached scsi generic sg3 type 0
Jun 27 17:26:51 marge kernel: [  524.932964] sd 12:0:0:0: [sdd] Spinning up disk...
Jun 27 17:26:53 marge kernel: [  525.937848] ..ready
Jun 27 17:26:53 marge kernel: [  526.942395] sd 12:0:0:0: [sdd] 976773168 512-byte logical blocks: (500 GB/465 GiB)
Jun 27 17:26:53 marge kernel: [  526.943037] sd 12:0:0:0: [sdd] Write Protect is off
Jun 27 17:26:53 marge kernel: [  526.943048] sd 12:0:0:0: [sdd] Mode Sense: 47 00 10 08
Jun 27 17:26:53 marge kernel: [  526.943662] sd 12:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jun 27 17:26:53 marge kernel: [  526.987919]  sdd: sdd1
Jun 27 17:26:53 marge kernel: [  526.990055] sd 12:0:0:0: [sdd] Attached SCSI disk
Jun 27 17:27:29 marge kernel: [  563.227849] EXT4-fs (sdd1): warning: mounting fs with errors, running e2fsck is recommended
Jun 27 17:27:29 marge kernel: [  563.228043] EXT4-fs (sdd1): mounted filesystem with ordered data mode. Opts: (null)

(This is on another machine, but it shows the same behavior without the patch.)

Does somebody have a hint for a real fix?

Note that I also tried the following change, which did _not_ fix the issue:

drivers/scsi/scsi_lib.c +1 -1
Index: linux/drivers/scsi/scsi_lib.c
===================================================================
@@ -824,7 +824,7 @@ void scsi_io_completion(struct scsi_cmnd
 			 * read past the end of the disk.
 			 */
 			if ((cmd->device->use_10_for_rw &&
-			    sshdr.asc == 0x20 && sshdr.ascq == 0x00) &&
+			    (sshdr.asc == 0x20 || sshdr.asc == 0x24) && sshdr.ascq == 0x00) &&
 			    (cmd->cmnd[0] == READ_10 ||
 			     cmd->cmnd[0] == WRITE_10)) {
 				/* This will issue a new 6-byte command. */
Signature · 1 line
Michael
maintainer
#4 lore raw
Quoted 40 lines · Michael Büsch

I tried the following patch:

Index: linux/drivers/scsi/sd.c
===================================================================

drivers/scsi/sd.c +1 -1
@@ -2440,7 +2440,7 @@ sd_read_cache_type(struct scsi_disk *sdk
 			sdkp->RCD = 0;
 		}
 
-		sdkp->DPOFUA = (data.device_specific & 0x10) != 0;
+		sdkp->DPOFUA = 0;
 		if (sdkp->DPOFUA && !sdkp->device->use_10_for_rw) {
 			sd_first_printk(KERN_NOTICE, sdkp,
 				  "Uses READ/WRITE(6), disabling FUA\n");

This obviously is not the correct thing to do, but it makes the disk usable:

Jun 27 17:26:50 marge kernel: [  523.909815] usb 2-1: new SuperSpeed USB device number 2 using xhci_hcd
Jun 27 17:26:50 marge kernel: [  523.929246] usb 2-1: New USB device found, idVendor=152d, idProduct=0567
Jun 27 17:26:50 marge kernel: [  523.929258] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun 27 17:26:50 marge kernel: [  523.929265] usb 2-1: Product: USB to ATA/ATAPI Bridge
Jun 27 17:26:50 marge kernel: [  523.929271] usb 2-1: Manufacturer: JMicron
Jun 27 17:26:50 marge kernel: [  523.929276] usb 2-1: SerialNumber: xxx
Jun 27 17:26:50 marge kernel: [  523.930999] usb-storage 2-1:1.0: USB Mass Storage device detected
Jun 27 17:26:50 marge kernel: [  523.931237] scsi12 : usb-storage 2-1:1.0
Jun 27 17:26:51 marge kernel: [  524.930451] scsi 12:0:0:0: Direct-Access     JMicron  Generic          0114 PQ: 0 ANSI: 6
Jun 27 17:26:51 marge kernel: [  524.931228] sd 12:0:0:0: Attached scsi generic sg3 type 0
Jun 27 17:26:51 marge kernel: [  524.932964] sd 12:0:0:0: [sdd] Spinning up disk...
Jun 27 17:26:53 marge kernel: [  525.937848] ..ready
Jun 27 17:26:53 marge kernel: [  526.942395] sd 12:0:0:0: [sdd] 976773168 512-byte logical blocks: (500 GB/465 GiB)
Jun 27 17:26:53 marge kernel: [  526.943037] sd 12:0:0:0: [sdd] Write Protect is off
Jun 27 17:26:53 marge kernel: [  526.943048] sd 12:0:0:0: [sdd] Mode Sense: 47 00 10 08
Jun 27 17:26:53 marge kernel: [  526.943662] sd 12:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jun 27 17:26:53 marge kernel: [  526.987919]  sdd: sdd1
Jun 27 17:26:53 marge kernel: [  526.990055] sd 12:0:0:0: [sdd] Attached SCSI disk
Jun 27 17:27:29 marge kernel: [  563.227849] EXT4-fs (sdd1): warning: mounting fs with errors, running e2fsck is recommended
Jun 27 17:27:29 marge kernel: [  563.228043] EXT4-fs (sdd1): mounted filesystem with ordered data mode. Opts: (null)
Quoted 3 lines

(This is on another machine, but it shows the same behavior without the patch.)

Does somebody have a hint for a real fix?

I suspect the problem is in the USB bridge: The device reports FUA support in its initial IDENTIFY, which gets translated to the correct mode page bits, but when we send a READ/WRITE with the FUA bit set, the bridge doesn't know how to translate it and gives us the error. There's probably some way in USB to blacklist the bridge, but we need to understand the consequences of the blacklist: The device is claiming a writeback cache which means if it won't do either FUA or SYNC CACHE, there's going to be a data integrity failure.

The fact that your initial hack works suggests that sync cache is accepted by it, so we probably just need a USB blacklist fixing the FUA problem.

James

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

author
#5 lore raw
Quoted 54 lines · On Fri, 27 Jun 2014 08:48:01 -0700 James Bottomley…
Quoted 40 lines · Michael Büsch

I tried the following patch:

Index: linux/drivers/scsi/sd.c
===================================================================

drivers/scsi/sd.c +1 -1
@@ -2440,7 +2440,7 @@ sd_read_cache_type(struct scsi_disk *sdk
 			sdkp->RCD = 0;
 		}
 
-		sdkp->DPOFUA = (data.device_specific & 0x10) != 0;
+		sdkp->DPOFUA = 0;
 		if (sdkp->DPOFUA && !sdkp->device->use_10_for_rw) {
 			sd_first_printk(KERN_NOTICE, sdkp,
 				  "Uses READ/WRITE(6), disabling FUA\n");

This obviously is not the correct thing to do, but it makes the disk usable:

Jun 27 17:26:50 marge kernel: [  523.909815] usb 2-1: new SuperSpeed USB device number 2 using xhci_hcd
Jun 27 17:26:50 marge kernel: [  523.929246] usb 2-1: New USB device found, idVendor=152d, idProduct=0567
Jun 27 17:26:50 marge kernel: [  523.929258] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun 27 17:26:50 marge kernel: [  523.929265] usb 2-1: Product: USB to ATA/ATAPI Bridge
Jun 27 17:26:50 marge kernel: [  523.929271] usb 2-1: Manufacturer: JMicron
Jun 27 17:26:50 marge kernel: [  523.929276] usb 2-1: SerialNumber: xxx
Jun 27 17:26:50 marge kernel: [  523.930999] usb-storage 2-1:1.0: USB Mass Storage device detected
Jun 27 17:26:50 marge kernel: [  523.931237] scsi12 : usb-storage 2-1:1.0
Jun 27 17:26:51 marge kernel: [  524.930451] scsi 12:0:0:0: Direct-Access     JMicron  Generic          0114 PQ: 0 ANSI: 6
Jun 27 17:26:51 marge kernel: [  524.931228] sd 12:0:0:0: Attached scsi generic sg3 type 0
Jun 27 17:26:51 marge kernel: [  524.932964] sd 12:0:0:0: [sdd] Spinning up disk...
Jun 27 17:26:53 marge kernel: [  525.937848] ..ready
Jun 27 17:26:53 marge kernel: [  526.942395] sd 12:0:0:0: [sdd] 976773168 512-byte logical blocks: (500 GB/465 GiB)
Jun 27 17:26:53 marge kernel: [  526.943037] sd 12:0:0:0: [sdd] Write Protect is off
Jun 27 17:26:53 marge kernel: [  526.943048] sd 12:0:0:0: [sdd] Mode Sense: 47 00 10 08
Jun 27 17:26:53 marge kernel: [  526.943662] sd 12:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jun 27 17:26:53 marge kernel: [  526.987919]  sdd: sdd1
Jun 27 17:26:53 marge kernel: [  526.990055] sd 12:0:0:0: [sdd] Attached SCSI disk
Jun 27 17:27:29 marge kernel: [  563.227849] EXT4-fs (sdd1): warning: mounting fs with errors, running e2fsck is recommended
Jun 27 17:27:29 marge kernel: [  563.228043] EXT4-fs (sdd1): mounted filesystem with ordered data mode. Opts: (null)
Quoted 3 lines

(This is on another machine, but it shows the same behavior without the patch.)

Does somebody have a hint for a real fix?

I suspect the problem is in the USB bridge: The device reports FUA support in its initial IDENTIFY, which gets translated to the correct mode page bits, but when we send a READ/WRITE with the FUA bit set, the bridge doesn't know how to translate it and gives us the error. There's probably some way in USB to blacklist the bridge, but we need to understand the consequences of the blacklist: The device is claiming a writeback cache which means if it won't do either FUA or SYNC CACHE, there's going to be a data integrity failure.

Quoted 3 lines

The fact that your initial hack works suggests that sync cache is accepted by it, so we probably just need a USB blacklist fixing the FUA problem.

[Added USB lists to Cc]

Signature · 1 line
Michael
maintainer
#6 lore raw
Quoted 57 lines · Michael Büsch
Quoted 54 lines · On Fri, 27 Jun 2014 08:48:01 -0700 James Bottomley…
Quoted 40 lines · Michael Büsch

I tried the following patch:

Index: linux/drivers/scsi/sd.c
===================================================================

drivers/scsi/sd.c +1 -1
@@ -2440,7 +2440,7 @@ sd_read_cache_type(struct scsi_disk *sdk
 			sdkp->RCD = 0;
 		}
 
-		sdkp->DPOFUA = (data.device_specific & 0x10) != 0;
+		sdkp->DPOFUA = 0;
 		if (sdkp->DPOFUA && !sdkp->device->use_10_for_rw) {
 			sd_first_printk(KERN_NOTICE, sdkp,
 				  "Uses READ/WRITE(6), disabling FUA\n");

This obviously is not the correct thing to do, but it makes the disk usable:

Jun 27 17:26:50 marge kernel: [  523.909815] usb 2-1: new SuperSpeed USB device number 2 using xhci_hcd
Jun 27 17:26:50 marge kernel: [  523.929246] usb 2-1: New USB device found, idVendor=152d, idProduct=0567
Jun 27 17:26:50 marge kernel: [  523.929258] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun 27 17:26:50 marge kernel: [  523.929265] usb 2-1: Product: USB to ATA/ATAPI Bridge
Jun 27 17:26:50 marge kernel: [  523.929271] usb 2-1: Manufacturer: JMicron
Jun 27 17:26:50 marge kernel: [  523.929276] usb 2-1: SerialNumber: xxx
Jun 27 17:26:50 marge kernel: [  523.930999] usb-storage 2-1:1.0: USB Mass Storage device detected
Jun 27 17:26:50 marge kernel: [  523.931237] scsi12 : usb-storage 2-1:1.0
Jun 27 17:26:51 marge kernel: [  524.930451] scsi 12:0:0:0: Direct-Access     JMicron  Generic          0114 PQ: 0 ANSI: 6
Jun 27 17:26:51 marge kernel: [  524.931228] sd 12:0:0:0: Attached scsi generic sg3 type 0
Jun 27 17:26:51 marge kernel: [  524.932964] sd 12:0:0:0: [sdd] Spinning up disk...
Jun 27 17:26:53 marge kernel: [  525.937848] ..ready
Jun 27 17:26:53 marge kernel: [  526.942395] sd 12:0:0:0: [sdd] 976773168 512-byte logical blocks: (500 GB/465 GiB)
Jun 27 17:26:53 marge kernel: [  526.943037] sd 12:0:0:0: [sdd] Write Protect is off
Jun 27 17:26:53 marge kernel: [  526.943048] sd 12:0:0:0: [sdd] Mode Sense: 47 00 10 08
Jun 27 17:26:53 marge kernel: [  526.943662] sd 12:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jun 27 17:26:53 marge kernel: [  526.987919]  sdd: sdd1
Jun 27 17:26:53 marge kernel: [  526.990055] sd 12:0:0:0: [sdd] Attached SCSI disk
Jun 27 17:27:29 marge kernel: [  563.227849] EXT4-fs (sdd1): warning: mounting fs with errors, running e2fsck is recommended
Jun 27 17:27:29 marge kernel: [  563.228043] EXT4-fs (sdd1): mounted filesystem with ordered data mode. Opts: (null)
Quoted 3 lines

(This is on another machine, but it shows the same behavior without the patch.)

Does somebody have a hint for a real fix?

I suspect the problem is in the USB bridge: The device reports FUA support in its initial IDENTIFY, which gets translated to the correct mode page bits, but when we send a READ/WRITE with the FUA bit set, the bridge doesn't know how to translate it and gives us the error. There's probably some way in USB to blacklist the bridge, but we need to understand the consequences of the blacklist: The device is claiming a writeback cache which means if it won't do either FUA or SYNC CACHE, there's going to be a data integrity failure.

Quoted 3 lines
Quoted 3 lines

The fact that your initial hack works suggests that sync cache is accepted by it, so we probably just need a USB blacklist fixing the FUA problem.

Michael, can you post the "lsusb -v" output for this device? I see it is made by JMicron; they are notorious for buggy USB-ATA bridges.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

author
#7 lore raw
Quoted 2 lines · On Fri, 27 Jun 2014 14:42:01 -0400 (EDT) Alan Stern…

Michael, can you post the "lsusb -v" output for this device? I see it is made by JMicron; they are notorious for buggy USB-ATA bridges.

Of course. Here you go:

Bus 004 Device 009: ID 152d:0567 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          0x0567 
  bcdDevice            1.14
  iManufacturer           1 JMicron
  iProduct                2 USB to ATA/ATAPI Bridge
  iSerial                 3 xxx
  bNumConfigurations      1

Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 121
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4 USB Mass Storage
bmAttributes 0xc0
Self Powered
MaxPower 2mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 6 MSC Bulk-Only Transport
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 1
bNumEndpoints 4
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 98
iInterface 10 MSC USB Attached SCSI
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Command pipe (0x01)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
MaxStreams 16
Status pipe (0x02)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
MaxStreams 16
Data-in pipe (0x03)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
MaxStreams 16
Data-out pipe (0x04)
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength 22
bNumDeviceCaps 2
USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType 16
bDevCapabilityType 2
bmAttributes 0x00000002
Link Power Management (LPM) Supported
SuperSpeed USB Device Capability:
bLength 10
bDescriptorType 16
bDevCapabilityType 3
bmAttributes 0x00
wSpeedsSupported 0x000e
Device can operate at Full Speed (12Mbps)
Device can operate at High Speed (480Mbps)
Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport 1
Lowest fully-functional device speed is Full Speed (12Mbps)
bU1DevExitLat 10 micro seconds
bU2DevExitLat 32 micro seconds
Device Status: 0x000d
Self Powered
U1 Enabled
U2 Enabled

MaxPower=2mA is a nice guess for a hard disk. ;)

Signature · 1 line
Michael
#8 lore raw
Quoted 34 lines · Michael Büsch
Quoted 2 lines · On Fri, 27 Jun 2014 14:42:01 -0400 (EDT) Alan Stern…

Michael, can you post the "lsusb -v" output for this device? I see it is made by JMicron; they are notorious for buggy USB-ATA bridges.

Of course. Here you go:

Bus 004 Device 009: ID 152d:0567 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          0x0567 
  bcdDevice            1.14
  iManufacturer           1 JMicron
  iProduct                2 USB to ATA/ATAPI Bridge
  iSerial                 3 xxx
  bNumConfigurations      1

Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 121
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4 USB Mass Storage
bmAttributes 0xc0
Self Powered
MaxPower 2mA

...

Quoted 1 line

MaxPower=2mA is a nice guess for a hard disk. ;)

That refers to the amount of power the device draws from the USB bus. Since the disk drive is self-powered, it doesn't use much bus power.

Does the patch below do what you and James want?

Alan Stern

include/linux/usb_usual.h +3 -1
Index: usb-3.16/include/linux/usb_usual.h
===================================================================
@@ -70,7 +70,9 @@
 	US_FLAG(NEEDS_CAP16,	0x00400000)			\
 		/* cannot handle READ_CAPACITY_10 */		\
 	US_FLAG(IGNORE_UAS,	0x00800000)			\
-		/* Device advertises UAS but it is broken */
+		/* Device advertises UAS but it is broken */	\
+	US_FLAG(BROKEN_FUA,	0x01000000)			\
+		/* Cannot handle FUA in WRITE CDBs */		\
 
 #define US_FLAG(name, value)	US_FL_##name = value ,
 enum { US_DO_ALL_FLAGS };
include/scsi/scsi_device.h +1 -0
Index: usb-3.16/include/scsi/scsi_device.h
===================================================================
@@ -173,6 +173,7 @@ struct scsi_device {
 	unsigned is_visible:1;	/* is the device visible in sysfs */
 	unsigned wce_default_on:1;	/* Cache is ON by default */
 	unsigned no_dif:1;	/* T10 PI (DIF) should be disabled */
+	unsigned broken_fua:1;		/* Don't set FUA bit */
 
 	atomic_t disk_events_disable_depth; /* disable depth for disk events */
drivers/usb/storage/unusual_devs.h +7 -0
Index: usb-3.16/drivers/usb/storage/unusual_devs.h
===================================================================
@@ -1936,6 +1936,13 @@ UNUSUAL_DEV(  0x14cd, 0x6600, 0x0201, 0x
 		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
 		US_FL_IGNORE_RESIDUE ),
 
+/* Reported by Michael Büsch <[email protected]> */
+UNUSUAL_DEV(  0x152d, 0x0567, 0x0114, 0x0114,
+		"JMicron",
+		"USB to ATA/ATAPI Bridge",
+		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+		US_FL_BROKEN_FUA ),
+
 /* Reported by Alexandre Oliva <[email protected]>
  * JMicron responds to USN and several other SCSI ioctls with a
  * residue that causes subsequent I/O requests to fail.  */
drivers/usb/storage/scsiglue.c +4 -0
Index: usb-3.16/drivers/usb/storage/scsiglue.c
===================================================================
@@ -256,6 +256,10 @@ static int slave_configure(struct scsi_d
 		if (us->fflags & US_FL_WRITE_CACHE)
 			sdev->wce_default_on = 1;
 
+		/* A few buggy USB-ATA bridges don't understand FUA */
+		if (us->fflags & US_FL_BROKEN_FUA)
+			sdev->broken_fua = 1;
+
 	} else {
 
 		/* Non-disk-type devices don't need to blacklist any pages
drivers/scsi/sd.c +4 -1
Index: usb-3.16/drivers/scsi/sd.c
===================================================================
@@ -2441,7 +2441,10 @@ sd_read_cache_type(struct scsi_disk *sdk
 		}
 
 		sdkp->DPOFUA = (data.device_specific & 0x10) != 0;
-		if (sdkp->DPOFUA && !sdkp->device->use_10_for_rw) {
+		if (sdp->broken_fua) {
+			sd_first_printk(KERN_NOTICE, sdkp, "Disabling FUA\n");
+			sdkp->DPOFUA = 0;
+		} else if (sdkp->DPOFUA && !sdkp->device->use_10_for_rw) {
 			sd_first_printk(KERN_NOTICE, sdkp,
 				  "Uses READ/WRITE(6), disabling FUA\n");
 			sdkp->DPOFUA = 0;

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

author Tested-by
#9 lore raw
Quoted 4 lines · On Fri, 27 Jun 2014 15:23:42 -0400 (EDT) Alan Stern…
Quoted 1 line

MaxPower=2mA is a nice guess for a hard disk. ;)

That refers to the amount of power the device draws from the USB bus. Since the disk drive is self-powered, it doesn't use much bus power.

Unless the device uses free energy or some other perpetual motion power source, it seems that it actually is bus-powered.
So the self-powered from the descriptor is a lie, too.

Quoted 1 line

Does the patch below do what you and James want?

Yes, this does work. Thanks!

You can add my

Tested-by Michael Büsch <[email protected]>
Signature · 1 line
Michael
author
#10 lore raw
Quoted 8 lines · On Fri, 27 Jun 2014 21:52:35 +0200 Michael Büsch <[email protected]> wrote:
Quoted 1 line · On Fri, 27 Jun 2014 15:23:42 -0400 (EDT) Alan Stern…

Does the patch below do what you and James want?

Yes, this does work. Thanks!

You can add my

Tested-by Michael Büsch <[email protected]>

Does somebody pick this up for inclusion?
It'd also be good, if this hit stable.

Signature · 1 line
Michael
maintainer
#11 lore raw

PATCH 1/1 usb-storage/SCSI: Add broken_fua blacklist flag

In reply to Michael Büsch

Some buggy JMicron USB-ATA bridges don't know how to translate the FUA bit in READs or WRITEs. This patch adds an entry in unusual_devs.h and a blacklist flag to tell the sd driver not to use FUA.

Signed-off-by Alan Stern <[email protected]>
Reported-by Michael Büsch <[email protected]>
Tested-by Michael Büsch <[email protected]>
Acked-by James Bottomley <[email protected]>
CC Matthew Dharm <[email protected]>
CC <[email protected]>

---

[as1751]

 drivers/scsi/sd.c                  |    5 ++++-
 drivers/usb/storage/scsiglue.c     |    4 ++++
 drivers/usb/storage/unusual_devs.h |    7 +++++++
 include/linux/usb_usual.h          |    4 +++-
 include/scsi/scsi_device.h         |    1 +
 5 files changed, 19 insertions(+), 2 deletions(-)
include/linux/usb_usual.h +3 -1
Index: usb-3.16/include/linux/usb_usual.h
===================================================================
@@ -70,7 +70,9 @@
 	US_FLAG(NEEDS_CAP16,	0x00400000)			\
 		/* cannot handle READ_CAPACITY_10 */		\
 	US_FLAG(IGNORE_UAS,	0x00800000)			\
-		/* Device advertises UAS but it is broken */
+		/* Device advertises UAS but it is broken */	\
+	US_FLAG(BROKEN_FUA,	0x01000000)			\
+		/* Cannot handle FUA in WRITE or READ CDBs */	\
 
 #define US_FLAG(name, value)	US_FL_##name = value ,
 enum { US_DO_ALL_FLAGS };
include/scsi/scsi_device.h +1 -0
Index: usb-3.16/include/scsi/scsi_device.h
===================================================================
@@ -173,6 +173,7 @@ struct scsi_device {
 	unsigned is_visible:1;	/* is the device visible in sysfs */
 	unsigned wce_default_on:1;	/* Cache is ON by default */
 	unsigned no_dif:1;	/* T10 PI (DIF) should be disabled */
+	unsigned broken_fua:1;		/* Don't set FUA bit */
 
 	atomic_t disk_events_disable_depth; /* disable depth for disk events */
drivers/usb/storage/unusual_devs.h +7 -0
Index: usb-3.16/drivers/usb/storage/unusual_devs.h
===================================================================
@@ -1936,6 +1936,13 @@ UNUSUAL_DEV(  0x14cd, 0x6600, 0x0201, 0x
 		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
 		US_FL_IGNORE_RESIDUE ),
 
+/* Reported by Michael Büsch <[email protected]> */
+UNUSUAL_DEV(  0x152d, 0x0567, 0x0114, 0x0114,
+		"JMicron",
+		"USB to ATA/ATAPI Bridge",
+		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+		US_FL_BROKEN_FUA ),
+
 /* Reported by Alexandre Oliva <[email protected]>
  * JMicron responds to USN and several other SCSI ioctls with a
  * residue that causes subsequent I/O requests to fail.  */
drivers/usb/storage/scsiglue.c +4 -0
Index: usb-3.16/drivers/usb/storage/scsiglue.c
===================================================================
@@ -256,6 +256,10 @@ static int slave_configure(struct scsi_d
 		if (us->fflags & US_FL_WRITE_CACHE)
 			sdev->wce_default_on = 1;
 
+		/* A few buggy USB-ATA bridges don't understand FUA */
+		if (us->fflags & US_FL_BROKEN_FUA)
+			sdev->broken_fua = 1;
+
 	} else {
 
 		/* Non-disk-type devices don't need to blacklist any pages
drivers/scsi/sd.c +4 -1
Index: usb-3.16/drivers/scsi/sd.c
===================================================================
@@ -2441,7 +2441,10 @@ sd_read_cache_type(struct scsi_disk *sdk
 		}
 
 		sdkp->DPOFUA = (data.device_specific & 0x10) != 0;
-		if (sdkp->DPOFUA && !sdkp->device->use_10_for_rw) {
+		if (sdp->broken_fua) {
+			sd_first_printk(KERN_NOTICE, sdkp, "Disabling FUA\n");
+			sdkp->DPOFUA = 0;
+		} else if (sdkp->DPOFUA && !sdkp->device->use_10_for_rw) {
 			sd_first_printk(KERN_NOTICE, sdkp,
 				  "Uses READ/WRITE(6), disabling FUA\n");
 			sdkp->DPOFUA = 0;

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

maintainer
#12 lore raw

Re: [PATCH] usb-storage/SCSI: Add broken_fua blacklist flag

Quoted 10 lines · Alan Stern

Some buggy JMicron USB-ATA bridges don't know how to translate the FUA bit in READs or WRITEs. This patch adds an entry in unusual_devs.h and a blacklist flag to tell the sd driver not to use FUA.

Signed-off-by Alan Stern <[email protected]>
Reported-by Michael Büsch <[email protected]>
Tested-by Michael Büsch <[email protected]>
Acked-by James Bottomley <[email protected]>
CC Matthew Dharm <[email protected]>
CC <[email protected]>

Greg:

I forgot to add your name to the recipient list on this patch. Since James has already Ack'ed it, would you like to take it for your USB tree?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): Pine.LNX.4.44L0.1406301115010.1550-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org

#14 lore raw

Re: [PATCH] usb-storage/SCSI: Add broken_fua blacklist flag

Quoted 13 lines · Alan Stern
Quoted 10 lines · Alan Stern

Some buggy JMicron USB-ATA bridges don't know how to translate the FUA bit in READs or WRITEs. This patch adds an entry in unusual_devs.h and a blacklist flag to tell the sd driver not to use FUA.

Signed-off-by Alan Stern <stern-nwvwT67g6+6dFdvTe/[email protected]>
Reported-by Michael Büsch <[email protected]>
Tested-by Michael Büsch <[email protected]>
Acked-by James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/[email protected]>
CC Matthew Dharm <[email protected]>
CC <[email protected]>
Quoted 5 lines

Greg:

I forgot to add your name to the recipient list on this patch. Since James has already Ack'ed it, would you like to take it for your USB tree?

Sure, I can take it, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

maintainer
#15 lore raw
In reply to Alan Stern
Quoted 36 lines · Alan Stern
Quoted 24 lines · Michael Büsch
Quoted 2 lines · On Fri, 27 Jun 2014 14:42:01 -0400 (EDT) Alan Stern…

Michael, can you post the "lsusb -v" output for this device? I see it is made by JMicron; they are notorious for buggy USB-ATA bridges.

Of course. Here you go:

Bus 004 Device 009: ID 152d:0567 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          0x0567 
  bcdDevice            1.14
  iManufacturer           1 JMicron
  iProduct                2 USB to ATA/ATAPI Bridge
  iSerial                 3 xxx
  bNumConfigurations      1
Quoted 10 lines

Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 121
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4 USB Mass Storage
bmAttributes 0xc0
Self Powered
MaxPower 2mA

Quoted 8 lines

...

Quoted 1 line

MaxPower=2mA is a nice guess for a hard disk. ;)

That refers to the amount of power the device draws from the USB bus. Since the disk drive is self-powered, it doesn't use much bus power.

Does the patch below do what you and James want?

Yes, that's the usual annoying additions to our blacklist. You can add my acked-by and could you cc stable?

Thanks,

James

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

#17 lore raw
Quoted 4 lines · James Bottomley
Quoted 1 line

Does the patch below do what you and James want?

Yes, that's the usual annoying additions to our blacklist. You can add my acked-by and could you cc stable?

Will do.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html