From: "Michael Büsch" <m@bues.ch>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: "Bryn M. Reeves" <bmr@redhat.com>,
linux-scsi@vger.kernel.org, linux-usb@vger.kernel.org,
usb-storage@lists.one-eyed-alien.net
Subject: Re: External USB3 disk fails with "Invalid field in cdb"
Date: Fri, 27 Jun 2014 19:55:03 +0200 [thread overview]
Message-ID: <20140627195503.49e2dc55@wiggum> (raw)
In-Reply-To: <1403884081.19382.7.camel@dabdike.int.hansenpartnership.com>
[-- 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 --]
next prev parent reply other threads:[~2014-06-27 17:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-26 18:55 External USB3 disk fails with "Invalid field in cdb" Michael Büsch
2014-06-27 10:15 ` Bryn M. Reeves
2014-06-27 12:22 ` Michael Büsch
2014-06-27 15:34 ` Michael Büsch
2014-06-27 15:48 ` James Bottomley
2014-06-27 17:55 ` Michael Büsch [this message]
2014-06-27 18:42 ` Alan Stern
2014-06-27 18:51 ` Michael Büsch
2014-06-27 19:23 ` [usb-storage] " Alan Stern
2014-06-27 19:52 ` Michael Büsch
2014-06-30 13:55 ` Michael Büsch
2014-06-30 15:04 ` [PATCH] usb-storage/SCSI: Add broken_fua blacklist flag Alan Stern
2014-06-30 15:16 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.1406301115010.1550-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2014-06-30 16:28 ` Greg KH
2014-06-30 14:12 ` [usb-storage] Re: External USB3 disk fails with "Invalid field in cdb" James Bottomley
[not found] ` <1404137562.2994.0.camel-doHRWNlmrt9+urZeOPWqwQ@public.gmane.org>
2014-06-30 14:27 ` Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140627195503.49e2dc55@wiggum \
--to=m@bues.ch \
--cc=James.Bottomley@HansenPartnership.com \
--cc=bmr@redhat.com \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=usb-storage@lists.one-eyed-alien.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.