Re: "Illegal Request" with JMicron JMS567-based USB3 HDD enclosure

2017-12-04 Thread Alan Stern
On Sun, 3 Dec 2017, David Kozub wrote:

> Hi all,
> 
> I'm observing the following error with a JMS567-based USB3 HDD enclosure:
> 
> sd 6:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK 
> driverbyte=DRIVER_SENSE
> sd 6:0:0:0: [sda] tag#0 Sense Key : Illegal Request [current]
> sd 6:0:0:0: [sda] tag#0 Add. Sense: Invalid field in cdb
> 
> It's reproducible with Linus' master - I tested with 2db767d988.
> 
> Looking into drivers/usb/storage I see there is already a bunch of 
> UNUSUAL_DEV entries for the JMS567 but my device (Icy Box IB-254U3) has a 
> different USB product ID:
> 
> Bus 004 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA 
> Technology Corp.
> 
> When I add an UNUSUAL_DEV entry for this ID too, the issue seems to go 
> away. But I'm not sure what is the proper way to add this:
> 
> * US_FL_BROKEN_FUA seems to be the important quirk but I see some other 
> JMS567 entries also use US_FL_NO_REPORT_OPCODES. Is there a way to test if 
> this quirk is needed for my device? The enclosure seems to work OK even 
> without this.

If it works okay without that quirk then you don't need to add it.

> * While normally the device is used via UAS (so I added the UNUSUAL_DEV to 
> unusual_uas.h), it's possible to use it in mass storage mode too (e.g. by 
> building a kernel without CONFIG_USB_UAS), and when I do so, I get the 
> same "Illegal Request", so I should add an UNUSUAL_DEV in unusual_devs.h 
> too, right?

Sure, go ahead.

> * What values should I use for bcdDeviceMin and bcdDeviceMax? I only have 
> two such enclosures bought at different times and both have bcdDevice = 
> 1.14 so should I specify bcdDeviceMin = bcdDeviceMax = 0x0114 or should 
> I use 0x and 0x as some other UNUSUAL_DEVs do?

This is a matter of judgment.  Given that other JMicron devices need
the quirk and how unlikely it seems that the company will fix their
bug, you can justify using the full range of bcdDevice values.

Alan Stern

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


"Illegal Request" with JMicron JMS567-based USB3 HDD enclosure

2017-12-03 Thread David Kozub

Hi all,

I'm observing the following error with a JMS567-based USB3 HDD enclosure:

sd 6:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE

sd 6:0:0:0: [sda] tag#0 Sense Key : Illegal Request [current]
sd 6:0:0:0: [sda] tag#0 Add. Sense: Invalid field in cdb

It's reproducible with Linus' master - I tested with 2db767d988.

Looking into drivers/usb/storage I see there is already a bunch of 
UNUSUAL_DEV entries for the JMS567 but my device (Icy Box IB-254U3) has a 
different USB product ID:


Bus 004 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA 
Technology Corp.


When I add an UNUSUAL_DEV entry for this ID too, the issue seems to go 
away. But I'm not sure what is the proper way to add this:


* US_FL_BROKEN_FUA seems to be the important quirk but I see some other 
JMS567 entries also use US_FL_NO_REPORT_OPCODES. Is there a way to test if 
this quirk is needed for my device? The enclosure seems to work OK even 
without this.


* While normally the device is used via UAS (so I added the UNUSUAL_DEV to 
unusual_uas.h), it's possible to use it in mass storage mode too (e.g. by 
building a kernel without CONFIG_USB_UAS), and when I do so, I get the 
same "Illegal Request", so I should add an UNUSUAL_DEV in unusual_devs.h 
too, right?


* What values should I use for bcdDeviceMin and bcdDeviceMax? I only have 
two such enclosures bought at different times and both have bcdDevice = 
1.14 so should I specify bcdDeviceMin = bcdDeviceMax = 0x0114 or should 
I use 0x and 0x as some other UNUSUAL_DEVs do?


Best regards,

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