External USB3 disk fails with "Invalid field in cdb"

External USB3 disk fails with "Invalid field in cdb"

[Michael Büsch]

[-- Attachment #1: Type: text/plain, Size: 3123 bytes --]

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?

-- 
Michael.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: External USB3 disk fails with "Invalid field in cdb"

[Bryn M. Reeves]

On Thu, Jun 26, 2014 at 08:55:19PM +0200, Michael Büsch wrote:
> 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:

> 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:

> 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:

> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: External USB3 disk fails with "Invalid field in cdb"

[Michael Büsch]

[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]

Thanks for your analysis.

On Fri, 27 Jun 2014 11:15:41 +0100
"Bryn M. Reeves" <bmr@redhat.com> wrote:

> On Thu, Jun 26, 2014 at 08:55:19PM +0200, Michael Büsch wrote:
> > 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.

> Looks like a WRITE(10) with the FUA bit set:
> 
> > 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?


-- 
Michael.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: External USB3 disk fails with "Invalid field in cdb"

[Michael Büsch]

I tried the following patch:

Index: linux/drivers/scsi/sd.c
===================================================================
--- linux.orig/drivers/scsi/sd.c	2014-06-26 18:40:39.214696552 +0200
+++ linux/drivers/scsi/sd.c	2014-06-27 15:52:30.776159456 +0200
@@ -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:

Index: linux/drivers/scsi/scsi_lib.c
===================================================================
--- linux.orig/drivers/scsi/scsi_lib.c	2014-06-27 17:30:27.901581410 +0200
+++ linux/drivers/scsi/scsi_lib.c	2014-06-27 17:32:12.044958922 +0200
@@ -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. */

-- 
Michael

Re: External USB3 disk fails with "Invalid field in cdb"

[James Bottomley]

On Fri, 2014-06-27 at 17:34 +0200, Michael Büsch wrote:
> I tried the following patch:
> 
> Index: linux/drivers/scsi/sd.c
> ===================================================================
> --- linux.orig/drivers/scsi/sd.c	2014-06-26 18:40:39.214696552 +0200
> +++ linux/drivers/scsi/sd.c	2014-06-27 15:52:30.776159456 +0200
> @@ -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?

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: External USB3 disk fails with "Invalid field in cdb"

[Michael Büsch]

[-- Attachment #1: Type: text/plain, Size: 3802 bytes --]

On Fri, 27 Jun 2014 08:48:01 -0700
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> On Fri, 2014-06-27 at 17:34 +0200, Michael Büsch wrote:
> > I tried the following patch:
> > 
> > Index: linux/drivers/scsi/sd.c
> > ===================================================================
> > --- linux.orig/drivers/scsi/sd.c	2014-06-26 18:40:39.214696552 +0200
> > +++ linux/drivers/scsi/sd.c	2014-06-27 15:52:30.776159456 +0200
> > @@ -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?
> 
> 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.
 

[Added USB lists to Cc]


-- 
Michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: External USB3 disk fails with "Invalid field in cdb"

[Alan Stern]

On Fri, 27 Jun 2014, Michael Büsch wrote:

> On Fri, 27 Jun 2014 08:48:01 -0700
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> > On Fri, 2014-06-27 at 17:34 +0200, Michael Büsch wrote:
> > > I tried the following patch:
> > > 
> > > Index: linux/drivers/scsi/sd.c
> > > ===================================================================
> > > --- linux.orig/drivers/scsi/sd.c	2014-06-26 18:40:39.214696552 +0200
> > > +++ linux/drivers/scsi/sd.c	2014-06-27 15:52:30.776159456 +0200
> > > @@ -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?
> > 
> > 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.

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: External USB3 disk fails with "Invalid field in cdb"

[Michael Büsch]

[-- Attachment #1: Type: text/plain, Size: 5734 bytes --]

On Fri, 27 Jun 2014 14:42:01 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:

> 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. ;)

-- 
Michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [usb-storage] Re: External USB3 disk fails with "Invalid field in cdb"

[Alan Stern]

On Fri, 27 Jun 2014, Michael Büsch wrote:

> On Fri, 27 Jun 2014 14:42:01 -0400 (EDT)
> Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
> 
> > 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
...

> 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



Index: usb-3.16/include/linux/usb_usual.h
===================================================================
--- usb-3.16.orig/include/linux/usb_usual.h
+++ 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 };
Index: usb-3.16/include/scsi/scsi_device.h
===================================================================
--- usb-3.16.orig/include/scsi/scsi_device.h
+++ 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 */
 
Index: usb-3.16/drivers/usb/storage/unusual_devs.h
===================================================================
--- usb-3.16.orig/drivers/usb/storage/unusual_devs.h
+++ 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 <m@bues.ch> */
+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 <oliva-RGTiaf7OHS4mmTcpzmvVSFAUjnlXr6A1@public.gmane.org>
  * JMicron responds to USN and several other SCSI ioctls with a
  * residue that causes subsequent I/O requests to fail.  */
Index: usb-3.16/drivers/usb/storage/scsiglue.c
===================================================================
--- usb-3.16.orig/drivers/usb/storage/scsiglue.c
+++ 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
Index: usb-3.16/drivers/scsi/sd.c
===================================================================
--- usb-3.16.orig/drivers/scsi/sd.c
+++ 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [usb-storage] Re: External USB3 disk fails with "Invalid field in cdb"

[Michael Büsch]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

On Fri, 27 Jun 2014 15:23:42 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:

> > 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.

> Does the patch below do what you and James want?

Yes, this does work. Thanks!

You can add my
Tested-by: Michael Büsch <m@bues.ch>

-- 
Michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [usb-storage] Re: External USB3 disk fails with "Invalid field in cdb"

[Michael Büsch]

[-- Attachment #1: Type: text/plain, Size: 424 bytes --]

On Fri, 27 Jun 2014 21:52:35 +0200
Michael Büsch <m@bues.ch> wrote:

> On Fri, 27 Jun 2014 15:23:42 -0400 (EDT)
> Alan Stern <stern@rowland.harvard.edu> wrote:
> > Does the patch below do what you and James want?
> 
> Yes, this does work. Thanks!
> 
> You can add my
> Tested-by: Michael Büsch <m@bues.ch>


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


-- 
Michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [usb-storage] Re: External USB3 disk fails with "Invalid field in cdb"

[James Bottomley]

On Fri, 2014-06-27 at 15:23 -0400, Alan Stern wrote:
> On Fri, 27 Jun 2014, Michael Büsch wrote:
> 
> > On Fri, 27 Jun 2014 14:42:01 -0400 (EDT)
> > Alan Stern <stern@rowland.harvard.edu> wrote:
> > 
> > > 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
> ...
> 
> > 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [usb-storage] Re: External USB3 disk fails with "Invalid field in cdb"

[Alan Stern]

On Mon, 30 Jun 2014, James Bottomley wrote:

> > 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[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@rowland.harvard.edu>
Reported-by: Michael Büsch <m@bues.ch>
Tested-by: Michael Büsch <m@bues.ch>
Acked-by: James Bottomley <James.Bottomley@HansenPartnership.com>
CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
CC: <stable@vger.kernel.org>

---


[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(-)

Index: usb-3.16/include/linux/usb_usual.h
===================================================================
--- usb-3.16.orig/include/linux/usb_usual.h
+++ 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 };
Index: usb-3.16/include/scsi/scsi_device.h
===================================================================
--- usb-3.16.orig/include/scsi/scsi_device.h
+++ 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 */
 
Index: usb-3.16/drivers/usb/storage/unusual_devs.h
===================================================================
--- usb-3.16.orig/drivers/usb/storage/unusual_devs.h
+++ 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 <m@bues.ch> */
+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 <oliva@lsd.ic.unicamp.br>
  * JMicron responds to USN and several other SCSI ioctls with a
  * residue that causes subsequent I/O requests to fail.  */
Index: usb-3.16/drivers/usb/storage/scsiglue.c
===================================================================
--- usb-3.16.orig/drivers/usb/storage/scsiglue.c
+++ 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
Index: usb-3.16/drivers/scsi/sd.c
===================================================================
--- usb-3.16.orig/drivers/scsi/sd.c
+++ 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Alan Stern]

On Mon, 30 Jun 2014, Alan Stern wrote:

> 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@rowland.harvard.edu>
> Reported-by: Michael Büsch <m@bues.ch>
> Tested-by: Michael Büsch <m@bues.ch>
> Acked-by: James Bottomley <James.Bottomley@HansenPartnership.com>
> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
> CC: <stable@vger.kernel.org>

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Greg KH]

On Mon, Jun 30, 2014 at 11:16:51AM -0400, Alan Stern wrote:
> On Mon, 30 Jun 2014, Alan Stern wrote:
> 
> > 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/nMLpVzexx5G7lz@public.gmane.org>
> > Reported-by: Michael Büsch <m@bues.ch>
> > Tested-by: Michael Büsch <m@bues.ch>
> > Acked-by: James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
> > CC: Matthew Dharm <mdharm-usb-JGfshJpz5UybPZpvUQj5UqxOck334EZe@public.gmane.org>
> > CC: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> 
> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html