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