Re: [PATCH] usb-storage: Fix scsi-sd failure "Invalid field in cdb" for USB adapter JMicron
On 20/11/2015 17:08, Alan Stern wrote: > On Fri, 20 Nov 2015, Dmitry Katsubo wrote: > >> From: Dmitry Katsubo <dmitry.kats...@gmail.com> >> >> The patch extends the family of SATA-to-USB JMicron adapters that need >> FUA to be disabled and applies the same policy for uas driver. >> See details in http://unix.stackexchange.com/questions/237204/ >> >> Signed-off-by: Dmitry Katsubo <dmitry.kats...@gmail.com> >> Tested-by: Dmitry Katsubo <dmitry.kats...@gmail.com> >> --- >> The change is trivial, however it spans also to JMicron adapter with >> bcdDevice 1.15, which I haven't tested. Nevertheless it is very likely >> that it is buggy as well. Patch was applied and tested on Debian Jessie >> 4.2.5-1~bpo8+1. There is a checkpatch warning, but it is caused by original >> source code formatting. > > Acked-by: Alan Stern <st...@rowland.harvard.edu> > > Greg, please apply this. > > Dmitry, do you want this be applied to the -stable kernels too? That is not necessary. I have working kernel which I am happy with -- many thanks for your guidance. What is the next lowest kernel version it will be applied to? -- With best regards, Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb-storage: Fix scsi-sd failure "Invalid field in cdb" for USB adapter JMicron
From: Dmitry Katsubo <dmitry.kats...@gmail.com> The patch extends the family of SATA-to-USB JMicron adapters that need FUA to be disabled and applies the same policy for uas driver. See details in http://unix.stackexchange.com/questions/237204/ Signed-off-by: Dmitry Katsubo <dmitry.kats...@gmail.com> Tested-by: Dmitry Katsubo <dmitry.kats...@gmail.com> --- The change is trivial, however it spans also to JMicron adapter with bcdDevice 1.15, which I haven't tested. Nevertheless it is very likely that it is buggy as well. Patch was applied and tested on Debian Jessie 4.2.5-1~bpo8+1. There is a checkpatch warning, but it is caused by original source code formatting. --- drivers/usb/storage/uas.c | 4 drivers/usb/storage/unusual_devs.h | 2 +- drivers/usb/storage/unusual_uas.h | 2 +- 3 files changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c index 48ca9c2..ce37e30 100644 --- a/drivers/usb/storage/uas.c +++ b/drivers/usb/storage/uas.c @@ -796,6 +796,10 @@ static int uas_slave_configure(struct scsi_device *sdev) if (devinfo->flags & US_FL_NO_REPORT_OPCODES) sdev->no_report_opcodes = 1; + /* A few buggy USB-ATA bridges don't understand FUA */ + if (devinfo->flags & US_FL_BROKEN_FUA) + sdev->broken_fua = 1; + scsi_change_queue_depth(sdev, devinfo->qdepth - 2); return 0; } diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h index 6b24791..7ffe420 100644 --- a/drivers/usb/storage/unusual_devs.h +++ b/drivers/usb/storage/unusual_devs.h @@ -1987,7 +1987,7 @@ UNUSUAL_DEV( 0x14cd, 0x6600, 0x0201, 0x0201, US_FL_IGNORE_RESIDUE ), /* Reported by Michael Büsch <m...@bues.ch> */ -UNUSUAL_DEV( 0x152d, 0x0567, 0x0114, 0x0114, +UNUSUAL_DEV( 0x152d, 0x0567, 0x0114, 0x0116, "JMicron", "USB to ATA/ATAPI Bridge", USB_SC_DEVICE, USB_PR_DEVICE, NULL, diff --git a/drivers/usb/storage/unusual_uas.h b/drivers/usb/storage/unusual_uas.h index c85ea53..ccc113e 100644 --- a/drivers/usb/storage/unusual_uas.h +++ b/drivers/usb/storage/unusual_uas.h @@ -132,7 +132,7 @@ UNUSUAL_DEV(0x152d, 0x0567, 0x, 0x, "JMicron", "JMS567", USB_SC_DEVICE, USB_PR_DEVICE, NULL, - US_FL_NO_REPORT_OPCODES), + US_FL_BROKEN_FUA | US_FL_NO_REPORT_OPCODES), /* Reported-by: Hans de Goede <hdego...@redhat.com> */ UNUSUAL_DEV(0x2109, 0x0711, 0x, 0x, -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi-sd fails with error "Invalid field in cdb" for SATA-to-USB adapter JMicron
On 2015-11-17 19:18, Alan Stern wrote: > That line is completely inappropriate for uas; it applies only to > usb-storage. Don't add it. I got it. My first thought was like you have said (every module uses its own structure), but I blindly tried to guess. > Here you need to test devinfo->flags & US_FL_BROKEN_FUA. Great, that worked! scsi host6: uas scsi 6:0:0:0: Direct-Access JMicron Generic 0116 PQ: 0 ANSI: 6 sd 6:0:0:0: Attached scsi generic sg2 type 0 sd 6:0:0:0: [sdb] 312581808 512-byte logical blocks: (160 GB/149 GiB) sd 6:0:0:0: [sdb] 4096-byte physical blocks sd 6:0:0:0: [sdb] Write Protect is off sd 6:0:0:0: [sdb] Mode Sense: 53 00 10 08 sd 6:0:0:0: [sdb] Disabling FUA sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 6:0:0:0: [sdb] Attached SCSI disk >> The show-stopper for me is to know, how the us->fflags is initialized >> from list of "unusual devices". There is some magic in there, at least >> this is not something on the surface. I can't get how the definition of >> these unusual devices is shared between scsiglue.c and uas.c, basically, >> where is the code that matches the USB vendor/product and sets >> us->fflags. That code should be called before uas.c: >> uas_slave_configure():792. > > The code that sets devinfo->flags is in uas_probe(). The flags value > comes from uas_use_uas_driver() in uas_detect.h. The table used by uas > is stored in unusual_uas.h, not unusual_devs.h, so you'll have to add a > completely new entry there. > > Actually, you should modify both unusual_*.h files, because someone > might want to use that device with the usb-storage driver rather than > the uas driver. Actually there is an entry in unusual_uas.h but there is a minor difference: unusual_uas.h uses UNUSUAL_DEV(0x152d, 0x0567, 0x, 0x, ... unusual_devs.h uses UNUSUAL_DEV(0x152d, 0x0567, 0x0114, 0x0116, ... so uas module captures the wider set of devices (effectively ignores bcdDevice). Should it be left like that (then behaviour could be different for usb-storage vs uas driver) or it makes sense to align these two? -- With best regards, Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi-sd fails with error "Invalid field in cdb" for SATA-to-USB adapter JMicron
On 2015-11-12 13:09, Dmitry Katsubo wrote:
> On 2015-11-11 16:16, Alan Stern wrote:
>>> Bus 001 Device 007: ID 152d:0567 JMicron Technology Corp. / JMicron USA
>>> Technology Corp.
>>> Device Descriptor:
>>>bLength18
>>>bDescriptorType 1
>>>bcdUSB 2.10
>>>bDeviceClass0 (Defined at Interface level)
>>>bDeviceSubClass 0
>>>bDeviceProtocol 0
>>>bMaxPacketSize064
>>>idVendor 0x152d JMicron Technology Corp. / JMicron USA
>>> Technology Corp.
>>>idProduct 0x0567
>>>bcdDevice1.16
>>
>> Yes, that's the problem. The blacklist entry only covers bcdDevice =
>> 1.14. The line in unusual_devs.h should be changed from
>>
>> UNUSUAL_DEV( 0x152d, 0x0567, 0x0114, 0x0114,
>>
>> to
>>
>> UNUSUAL_DEV( 0x152d, 0x0567, 0x0114, 0x0116,
>>
>> Would you like to write a patch to do this?
>
> Thanks for pointing that: after you have mentioned bcdDevice writing a
> patch becomes trivial, however I also would like to test it. I will post
> a patch once I confirm the fix is working. I think the whole cycle will
> take me a week.
>
> Should I create a patch against master
> (git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git)?
> (unlikely there will be conflicts in unusual_devs.h).
Alan, I have difficulties with making it working. The patch that was
supposed to be trivial, does not work. The problem is that given USB
adapter is detected as "uas" device (so, driven by uas.ko module). It
took me few days to understand that, because I literally got lost in
code trying to understand why scsiglue.c:slave_configure():114 is not
called (if it would be called, then the job is done).
> scsi host7: uas
> scsi 7:0:0:0: Direct-Access JMicron Generic 0116 PQ: 0 ANSI: 6
> sd 7:0:0:0: Attached scsi generic sg4 type 0
I have added the following code, which I copied from scsiglue.c:
> --- uas.c.orig 2015-10-27 01:53:59.0 +0100
> +++ uas.c 2015-11-17 12:32:52.976121206 +0100
> @@ -792,10 +792,21 @@
> static int uas_slave_configure(struct scsi_device *sdev)
> {
> struct uas_dev_info *devinfo = sdev->hostdata;
> + struct us_data *us = host_to_us(sdev->host);
>
> if (devinfo->flags & US_FL_NO_REPORT_OPCODES)
> sdev->no_report_opcodes = 1;
>
> + printk(KERN_ERR "uas: " ">> uas_slave_configure(): sdev->type: 0x%02X
> us->fflags: 0x%02X\n", sdev->type, us->fflags);
> +
> + if (sdev->type == TYPE_DISK) {
> + /* A few buggy USB-ATA bridges don't understand FUA */
> + if (us->fflags & US_FL_BROKEN_FUA) {
> + sdev->broken_fua = 1;
> + printk(KERN_ERR "uas: " ">> fua: set sdev->broken_fua
> = 1\n");
> + }
> + }
> +
> scsi_change_queue_depth(sdev, devinfo->qdepth - 2);
> return 0;
> }
>
It outputs the following to dmesg:
uas: >> uas_slave_configure(): sdev->type: 0x00 us->fflags: 0x00
The show-stopper for me is to know, how the us->fflags is initialized
from list of "unusual devices". There is some magic in there, at least
this is not something on the surface. I can't get how the definition of
these unusual devices is shared between scsiglue.c and uas.c, basically,
where is the code that matches the USB vendor/product and sets
us->fflags. That code should be called before uas.c:
uas_slave_configure():792.
Many thanks.
--
With best regards,
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi-sd fails with error "Invalid field in cdb" for SATA-to-USB adapter JMicron
On 2015-11-11 16:16, Alan Stern wrote: >> Bus 001 Device 007: ID 152d:0567 JMicron Technology Corp. / JMicron USA >> Technology Corp. >> Device Descriptor: >>bLength18 >>bDescriptorType 1 >>bcdUSB 2.10 >>bDeviceClass0 (Defined at Interface level) >>bDeviceSubClass 0 >>bDeviceProtocol 0 >>bMaxPacketSize064 >>idVendor 0x152d JMicron Technology Corp. / JMicron USA >> Technology Corp. >>idProduct 0x0567 >>bcdDevice1.16 > > Yes, that's the problem. The blacklist entry only covers bcdDevice = > 1.14. The line in unusual_devs.h should be changed from > > UNUSUAL_DEV( 0x152d, 0x0567, 0x0114, 0x0114, > > to > > UNUSUAL_DEV( 0x152d, 0x0567, 0x0114, 0x0116, > > Would you like to write a patch to do this? Thanks for pointing that: after you have mentioned bcdDevice writing a patch becomes trivial, however I also would like to test it. I will post a patch once I confirm the fix is working. I think the whole cycle will take me a week. Should I create a patch against master (git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git)? (unlikely there will be conflicts in unusual_devs.h). -- With best regards, Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi-sd fails with error "Invalid field in cdb" for SATA-to-USB adapter JMicron
On 10/11/2015 16:00, Alan Stern wrote: On Tue, 10 Nov 2015, Dmitry Katsubo wrote: Hello everyone, Sorry for cross-posting from linux-s...@vger.kernel.org In continuation to the issue described in [1] and [2]: Unfortunately, I still suffer from the same problem on Linux kernel v4.2.3. The problem is in detailed described in [3], in particular I see the following in dmesg: sd 6:0:0:0: [sdd] 234441648 512-byte logical blocks: (120 GB/111 GiB) sd 6:0:0:0: [sdd] 4096-byte physical blocks sd 6:0:0:0: [sdd] Write Protect is off sd 6:0:0:0: [sdd] Mode Sense: 53 00 10 08 sd 6:0:0:0: [sdd] Write cache: enabled, read cache: enabled, supports DPO and FUA ... sd 6:0:0:0: [sdd] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE sd 6:0:0:0: [sdd] tag#0 Sense Key : Illegal Request [current] sd 6:0:0:0: [sdd] tag#0 Add. Sense: Invalid field in cdb sd 6:0:0:0: [sdd] tag#0 CDB: Write(10) 2a 08 00 00 10 80 00 00 08 00 blk_update_request: critical target error, dev sdd, sector 4224 BTRFS: lost page write due to I/O error on /dev/sdd1 BTRFS: bdev /dev/sdd1 errs: wr 9, rd 0, flush 0, corrupt 0, gen 0 I believe that according to patches [4], [5] I should see something like "Disabling FUA" in logs, but that is not the case Any information about how to fix the problem is appreciated. # lsusb Bus 001 Device 007: ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. Please post the output from lsusb -v. Probably your device has a bcdDevice value that's outside the range in the blacklist entry. Many thanks for looking into that. Bus 001 Device 007: ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x152d JMicron Technology Corp. / JMicron USA Technology Corp. idProduct 0x0567 bcdDevice1.16 iManufacturer 1 JMicron iProduct2 USB to ATA/ATAPI Bridge iSerial 3 373710661 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 85 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 bmAttributes 0xc0 Self Powered MaxPower 30mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 6 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 1 bNumEndpoints 4 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 98 iInterface 10 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Command pipe (0x01) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Status pipe (0x02) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None
scsi-sd fails with error "Invalid field in cdb" for SATA-to-USB adapter JMicron
Hello everyone, Sorry for cross-posting from linux-s...@vger.kernel.org In continuation to the issue described in [1] and [2]: Unfortunately, I still suffer from the same problem on Linux kernel v4.2.3. The problem is in detailed described in [3], in particular I see the following in dmesg: sd 6:0:0:0: [sdd] 234441648 512-byte logical blocks: (120 GB/111 GiB) sd 6:0:0:0: [sdd] 4096-byte physical blocks sd 6:0:0:0: [sdd] Write Protect is off sd 6:0:0:0: [sdd] Mode Sense: 53 00 10 08 sd 6:0:0:0: [sdd] Write cache: enabled, read cache: enabled, supports DPO and FUA ... sd 6:0:0:0: [sdd] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE sd 6:0:0:0: [sdd] tag#0 Sense Key : Illegal Request [current] sd 6:0:0:0: [sdd] tag#0 Add. Sense: Invalid field in cdb sd 6:0:0:0: [sdd] tag#0 CDB: Write(10) 2a 08 00 00 10 80 00 00 08 00 blk_update_request: critical target error, dev sdd, sector 4224 BTRFS: lost page write due to I/O error on /dev/sdd1 BTRFS: bdev /dev/sdd1 errs: wr 9, rd 0, flush 0, corrupt 0, gen 0 I believe that according to patches [4], [5] I should see something like "Disabling FUA" in logs, but that is not the case Any information about how to fix the problem is appreciated. # lsusb Bus 001 Device 007: ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. [1] http://permalink.gmane.org/gmane.linux.scsi/91997 [2] http://permalink.gmane.org/gmane.linux.usb.general/120430 [3] http://unix.stackexchange.com/questions/237204/ [4] https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable/+blame/v4.2.3/drivers/scsi/sd.c#2446 [5] https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable/+blame/v4.2.3/drivers/usb/storage/unusual_devs.h#1990 -- With best regards, Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
