Re: BUG xhci_hcd usb3 module WARNS with JMicron JMS567 when writing to disk

[Menion]

I think that JMS567 is mostly broken nowadays in Linux UAS
Mine in an Orico multibay encolsure produce a lot of CMD timeout
Recently Orico is just silently disabling in firmware the UAS support
for this bridge (still advertising it on the webpage, usual chinese
behaviour)
Try to disable UAS with usb-storage quirks instead of blacklisting the
entire usb-storage

2018-04-20 16:10 GMT+02:00 Tomas M :
> Hello,
>
> Tested 4.16.2 with the same results. Anything i can do to help find the 
> problem?
>
> Thanks
>
> Tomas
>
> On Mon, Mar 12, 2018 at 8:22 AM, Tomas M  wrote:
>> Hello, I think its UAS:
>> From the dmesg:
>> [  652.335275] usb 1-1.3: Product: SABRENT
>> [  652.335279] usb 1-1.3: Manufacturer: SABRENT
>> [  652.335283] usb 1-1.3: SerialNumber: DB98765432123
>> [  652.337283] scsi host8: uas
>> [  652.338731] scsi 8:0:0:0: Direct-Access SABRENT
>>   4101 PQ: 0 ANSI: 6
>>
>> SABRENT Is the HDD craddle.
>>
>> I have an external Toshiba HDD running on the same computer with the
>> xhci_hcd driver for years without problems. But it reads:
>>  >>> usb-storage 4-1:1.0: USB Mass Storage device detected
>> so i think its fundamentally different.
>>
>> Yes. data corruption ocurred when Oopsing.
>>
>> Like i said, i tried different HDDs and have two HDD Craddles to play
>> with. all combinations brought the same result. Both craddles have
>> SATA-USB3 chipsets from JMicrion. running on a USB2 chipset with the
>> ehci driver works fine.
>>
>> Regards
>>
>> Tomas
>>
>> On Mon, Mar 12, 2018 at 6:52 AM, Oliver Neukum  wrote:
>>> Am Sonntag, den 11.03.2018, 10:48 -0300 schrieb Tomas M:
 Hello,

 I reported the bug here and was suggested to forward it to the ML.
 https://bugzilla.kernel.org/show_bug.cgi?id=199075

 find attached the owed dmesg with the stack trace.

 using the ehci ports produces no error.
 using the xhci ports fails very fast when writing.

 this happens with the
 Bus 001 Device 005: ID 152d:0578 JMicron Technology Corp. / JMicron
 USA Technology Corp. JMS567 SATA 6Gb/s bridge

 and another similar chipset from JMicron too.

 I have another external USB3 drive using the xhci driver without problems.

 Regards
>>>
>>> UAS or storage?
>>>
>>> A CRC error is really unusual and an oops in RCU is arcane.
>>> Do you have errors with other Super Speed devices? This looks
>>> like data corruption.
>>>
>>> Regards
>>> Oliver
>>>
> --
> 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
--
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: ASMedia SATA Bridge not enumerating without quirk

[Menion]

Mine was just a question from a non expert in kernel internals
Bye

2018-03-22 18:29 GMT+01:00 Alan Stern <st...@rowland.harvard.edu>:
> On Thu, 22 Mar 2018, Menion wrote:
>
>> You are right.
>> But what if usb-storage check if the deferred uas bind does not succeed?
>
> That is not possible, for two reasons.  First, the kernel does not keep
> track of binding attempts that fail.  Second, the kernel can only try
> to bind one driver to a device at a time.  So if usb-storage tries to
> bind first, it can't wait to see what will happen with uas -- because
> nothing at all will happen until the usb-storage bind fails.
>
> It sounds like you're trying to figure out a bunch of far-out, overly
> complex schemes to work around the fact that you simply didn't have the
> right driver module present on your system.  Wouldn't it be easier to
> just fix your system than to try and complicate a kernel which already
> is very complicated?
>
> In your case, the real problem was the missing kernel module.  It seems
> to me that you should have gotten an appropriate error message about
> this somewhere -- perhaps in the system log.  Was there such an error
> message?  If not, maybe one could be added.  After all, if the kernel's
> configuration indicates that a particular module was built, but it
> can't be loaded, that definitely shows that something isn't working
> right.
>
> 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

Re: ASMedia SATA Bridge not enumerating without quirk

[Menion]

Would be technically possible that the function uas_use_uas_driver
checks if the uas driver is loaded (not just configured) before
telling the usb-storage to leave the device to the uas module?
Bye

2018-03-22 16:16 GMT+01:00 Alan Stern <st...@rowland.harvard.edu>:
> On Wed, 21 Mar 2018, Menion wrote:
>
>> Well, still, my two cents here, is it really that if you have UAS in a
>> module and you don't load it but connect an UAS capable device, this
>> device is not enumerated rather than downgraded to usb-storage?
>
> Let's be precise.  The device _is_ enumerated, because the kernel can't
> tell what driver is appropriate without first reading the device's
> descriptors, which happens during enumeration.  Once the enumeration is
> over, the kernel tries to bind the device to an appropriate driver; if
> the binding fails then the device won't be used.
>
> If a device is UAS-capable and the kernel was built with UAS support,
> then the appropriate driver is uas.  In fact, there is a special check
> inside usb-storage for precisely this situation:
>
> /* If uas is enabled and this device can do uas then ignore it. */
> #if IS_ENABLED(CONFIG_USB_UAS)
> if (uas_use_uas_driver(intf, id, NULL))
> return -ENXIO;
> #endif
>
> There are some special cases embedded in the uas_use_uas_driver()
> routine.  For instance, if the US_FL_IGNORE_UAS quirk flag is set then
> uas_use_uas_driver() will return 0, and then usb-storage will bind to
> the device.
>
> But assuming none of the special cases apply, if the uas driver was
> built as a module and the module can't be loaded then the binding to
> uas will fail.  As a result, the device will not be used.
>
> 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

Re: ASMedia SATA Bridge not enumerating without quirk

[Menion]

Well, still, my two cents here, is it really that if you have UAS in a
module and you don't load it but connect an UAS capable device, this
device is not enumerated rather than downgraded to usb-storage?

2018-03-21 19:10 GMT+01:00 Mike Lothian <m...@fireburn.co.uk>:
> So this is a brown paper bag moment, I don't use usb-uas on my laptop,
> so the kernel always does the right thing (I've enabled it now I know
> about it)
>
> The router has usb-uas compiled as a module, but didn't have it
> installed, it's not one of the default ones it seems
>
> After installing kmod-usb-storage-uas everything kicked into life
>
> Sorry for the noise
>
> On 21 March 2018 at 17:55, Mike Lothian <m...@fireburn.co.uk> wrote:
>> Lastly here's the lsusb -v and dmesg from 4.9.87 on the router without
>> the quirk added
>>
>> On 21 March 2018 at 17:50, Mike Lothian <m...@fireburn.co.uk> wrote:
>>> Also here's the kernel config for the router, it's now 4.9.87
>>>
>>>
>>>
>>> On 21 March 2018 at 17:23, Menion <men...@gmail.com> wrote:
>>>> Yes that was the point.
>>>> Curious that the device worked fine in 17.01.4 and not in snapshot,
>>>> but in 17.01.4 do you remember if it went in UAS or USB-STORAGE mode?
>>>> I cannot answer here, but I am wondering if it is possible that if the
>>>> kernel is compiled without UAS support, then a device showing UASP
>>>> capability won't get enumerated at all instead of being downgraded to
>>>> usb-storage.
>>>>
>>>> 2018-03-21 18:19 GMT+01:00 Mike Lothian <m...@fireburn.co.uk>:
>>>>> Sorry I'm not sure what you mean by that, would you like the output of
>>>>> lsusb -v before and after the quirk is added? And again from my
>>>>> laptop?
>>>>>
>>>>> I'd like to point the device worked fine when running a 4.4 kernel on
>>>>> LEDE 17.01.4
>>>>>
>>>>> On 21 March 2018 at 17:10, Menion <men...@gmail.com> wrote:
>>>>>> Then it is so strange, it is completely dead from USB host perspective
>>>>>> in UASP mode
>>>>>> What lsusb shows when it is attached in UASP mode?
>>>>>> Can you test it with some "regular" host with USB 3.0, like a PC?
>>>>>>
>>>>>> 2018-03-21 18:07 GMT+01:00 Mike Lothian <m...@fireburn.co.uk>:
>>>>>>> Sorry, yes that was me disconnecting the device and reconnecting it,
>>>>>>> just to confirm that it was the quirk that was fixing things (I might
>>>>>>> not have connected it into the same port)
>>>>>>>
>>>>>>> I am changing the quirks in the modules config and reattaching,
>>>>>>> modprobe on this device doesn't seem to let me specify options
>>>>>>>
>>>>>>> It's a USB3 caddy that has its own power supply, that you can put any
>>>>>>> SATA hard disk into, I currently have a 1.5TB drive in it.
>>>>>>>
>>>>>>> On 21 March 2018 at 17:00, Menion <men...@gmail.com> wrote:
>>>>>>>> I see a disconnect from port 4:1 of some un-enumerated device then
>>>>>>>> connect to port 2:1 with UAS blacklist:
>>>>>>>>
>>>>>>>> [  281.814757] usb 4-1: USB disconnect, device number 2
>>>>>>>> [  283.418292] usb 2-1: new SuperSpeed USB device number 2 using 
>>>>>>>> xhci-hcd
>>>>>>>> [  482.153319] usb 2-1: USB disconnect, device number 2
>>>>>>>> [  484.250856] usb 2-1: UAS is blacklisted for this device, using
>>>>>>>> usb-storage instead
>>>>>>>> [  484.250901] usb-storage 2-1:1.0: USB Mass Storage device detected
>>>>>>>> [  484.258055] usb-storage 2-1:1.0: Quirks match for vid 174c pid 
>>>>>>>> 55aa: c0
>>>>>>>> [  484.264432] scsi host1: usb-storage 2-1:1.0
>>>>>>>>
>>>>>>>> Are you peraphs changing the quirks in the modules config and reattach
>>>>>>>> the device?
>>>>>>>> Anyhow I see some strange reset from the USB host. What is this
>>>>>>>> device? Perhaps some self-powered external HDD?
>>>>>>>>
>>>>>>>> 2018-03-21 17:56 GMT+01:00 Mike Lothian <m...@fireburn.co.uk>:

Re: ASMedia SATA Bridge not enumerating without quirk

[Menion]

Yes that was the point.
Curious that the device worked fine in 17.01.4 and not in snapshot,
but in 17.01.4 do you remember if it went in UAS or USB-STORAGE mode?
I cannot answer here, but I am wondering if it is possible that if the
kernel is compiled without UAS support, then a device showing UASP
capability won't get enumerated at all instead of being downgraded to
usb-storage.

2018-03-21 18:19 GMT+01:00 Mike Lothian <m...@fireburn.co.uk>:
> Sorry I'm not sure what you mean by that, would you like the output of
> lsusb -v before and after the quirk is added? And again from my
> laptop?
>
> I'd like to point the device worked fine when running a 4.4 kernel on
> LEDE 17.01.4
>
> On 21 March 2018 at 17:10, Menion <men...@gmail.com> wrote:
>> Then it is so strange, it is completely dead from USB host perspective
>> in UASP mode
>> What lsusb shows when it is attached in UASP mode?
>> Can you test it with some "regular" host with USB 3.0, like a PC?
>>
>> 2018-03-21 18:07 GMT+01:00 Mike Lothian <m...@fireburn.co.uk>:
>>> Sorry, yes that was me disconnecting the device and reconnecting it,
>>> just to confirm that it was the quirk that was fixing things (I might
>>> not have connected it into the same port)
>>>
>>> I am changing the quirks in the modules config and reattaching,
>>> modprobe on this device doesn't seem to let me specify options
>>>
>>> It's a USB3 caddy that has its own power supply, that you can put any
>>> SATA hard disk into, I currently have a 1.5TB drive in it.
>>>
>>> On 21 March 2018 at 17:00, Menion <men...@gmail.com> wrote:
>>>> I see a disconnect from port 4:1 of some un-enumerated device then
>>>> connect to port 2:1 with UAS blacklist:
>>>>
>>>> [  281.814757] usb 4-1: USB disconnect, device number 2
>>>> [  283.418292] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
>>>> [  482.153319] usb 2-1: USB disconnect, device number 2
>>>> [  484.250856] usb 2-1: UAS is blacklisted for this device, using
>>>> usb-storage instead
>>>> [  484.250901] usb-storage 2-1:1.0: USB Mass Storage device detected
>>>> [  484.258055] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa: 
>>>> c0
>>>> [  484.264432] scsi host1: usb-storage 2-1:1.0
>>>>
>>>> Are you peraphs changing the quirks in the modules config and reattach
>>>> the device?
>>>> Anyhow I see some strange reset from the USB host. What is this
>>>> device? Perhaps some self-powered external HDD?
>>>>
>>>> 2018-03-21 17:56 GMT+01:00 Mike Lothian <m...@fireburn.co.uk>:
>>>>> It had both, as did my follow up, the follow up should be more clear 
>>>>> though
>>>>>
>>>>> On 21 March 2018 at 16:45, Menion <men...@gmail.com> wrote:
>>>>>> You sent the dmesg with quirks :u enabled
>>>>>> We need the one without quirks :u, when the device takes UAS driver
>>>>>> Bye
>>>>>>
>>>>>> 2018-03-21 17:41 GMT+01:00 Mike Lothian <m...@fireburn.co.uk>:
>>>>>>> Hi
>>>>>>>
>>>>>>> Please find attached my dmesg
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>> On 21 March 2018 at 16:12, Oliver Neukum <oneu...@suse.com> wrote:
>>>>>>>> Am Mittwoch, den 21.03.2018, 17:09 +0100 schrieb Greg KH:
>>>>>>>>> > I'm guessing it doesn't quite match up with the rules already in 
>>>>>>>>> > place
>>>>>>>>> > in uas-detect.h
>>>>>>>>>
>>>>>>>>> That device has a quirk already as a "normal" usb-storage device.
>>>>>>>>> Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add 
>>>>>>>>> quirk
>>>>>>>>> for mandatory READ_CAPACITY_16")
>>>>>>>>
>>>>>>>> That should cause different symptoms.
>>>>>>>>
>>>>>>>>> > Looks like it's an ASM1053 that can't do UAS
>>>>>>>>>
>>>>>>>>> No, it's not a UAS device, is someone trying to recycle device ids to 
>>>>>>>>> do
>>>>>>>>> different things now?  That's not good :(
>>>>>>>>
>>>>>>>> The second interface looks like UAS though. The second interface looks
>>>>>>>> like UAS though. What exactly does happen when you ennumerate?
>>>>>>>> Dmesg please.
>>>>>>>>
>>>>>>>> We may need some exotic logic for these devices.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Oliver
>>>>>>>>
--
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: ASMedia SATA Bridge not enumerating without quirk

[Menion]

Then it is so strange, it is completely dead from USB host perspective
in UASP mode
What lsusb shows when it is attached in UASP mode?
Can you test it with some "regular" host with USB 3.0, like a PC?

2018-03-21 18:07 GMT+01:00 Mike Lothian <m...@fireburn.co.uk>:
> Sorry, yes that was me disconnecting the device and reconnecting it,
> just to confirm that it was the quirk that was fixing things (I might
> not have connected it into the same port)
>
> I am changing the quirks in the modules config and reattaching,
> modprobe on this device doesn't seem to let me specify options
>
> It's a USB3 caddy that has its own power supply, that you can put any
> SATA hard disk into, I currently have a 1.5TB drive in it.
>
> On 21 March 2018 at 17:00, Menion <men...@gmail.com> wrote:
>> I see a disconnect from port 4:1 of some un-enumerated device then
>> connect to port 2:1 with UAS blacklist:
>>
>> [  281.814757] usb 4-1: USB disconnect, device number 2
>> [  283.418292] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
>> [  482.153319] usb 2-1: USB disconnect, device number 2
>> [  484.250856] usb 2-1: UAS is blacklisted for this device, using
>> usb-storage instead
>> [  484.250901] usb-storage 2-1:1.0: USB Mass Storage device detected
>> [  484.258055] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa: 
>> c0
>> [  484.264432] scsi host1: usb-storage 2-1:1.0
>>
>> Are you peraphs changing the quirks in the modules config and reattach
>> the device?
>> Anyhow I see some strange reset from the USB host. What is this
>> device? Perhaps some self-powered external HDD?
>>
>> 2018-03-21 17:56 GMT+01:00 Mike Lothian <m...@fireburn.co.uk>:
>>> It had both, as did my follow up, the follow up should be more clear though
>>>
>>> On 21 March 2018 at 16:45, Menion <men...@gmail.com> wrote:
>>>> You sent the dmesg with quirks :u enabled
>>>> We need the one without quirks :u, when the device takes UAS driver
>>>> Bye
>>>>
>>>> 2018-03-21 17:41 GMT+01:00 Mike Lothian <m...@fireburn.co.uk>:
>>>>> Hi
>>>>>
>>>>> Please find attached my dmesg
>>>>>
>>>>> Cheers
>>>>>
>>>>> Mike
>>>>>
>>>>> On 21 March 2018 at 16:12, Oliver Neukum <oneu...@suse.com> wrote:
>>>>>> Am Mittwoch, den 21.03.2018, 17:09 +0100 schrieb Greg KH:
>>>>>>> > I'm guessing it doesn't quite match up with the rules already in place
>>>>>>> > in uas-detect.h
>>>>>>>
>>>>>>> That device has a quirk already as a "normal" usb-storage device.
>>>>>>> Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add quirk
>>>>>>> for mandatory READ_CAPACITY_16")
>>>>>>
>>>>>> That should cause different symptoms.
>>>>>>
>>>>>>> > Looks like it's an ASM1053 that can't do UAS
>>>>>>>
>>>>>>> No, it's not a UAS device, is someone trying to recycle device ids to do
>>>>>>> different things now?  That's not good :(
>>>>>>
>>>>>> The second interface looks like UAS though. The second interface looks
>>>>>> like UAS though. What exactly does happen when you ennumerate?
>>>>>> Dmesg please.
>>>>>>
>>>>>> We may need some exotic logic for these devices.
>>>>>>
>>>>>> Regards
>>>>>> Oliver
>>>>>>
--
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: ASMedia SATA Bridge not enumerating without quirk

[Menion]

I see a disconnect from port 4:1 of some un-enumerated device then
connect to port 2:1 with UAS blacklist:

[  281.814757] usb 4-1: USB disconnect, device number 2
[  283.418292] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
[  482.153319] usb 2-1: USB disconnect, device number 2
[  484.250856] usb 2-1: UAS is blacklisted for this device, using
usb-storage instead
[  484.250901] usb-storage 2-1:1.0: USB Mass Storage device detected
[  484.258055] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa: c0
[  484.264432] scsi host1: usb-storage 2-1:1.0

Are you peraphs changing the quirks in the modules config and reattach
the device?
Anyhow I see some strange reset from the USB host. What is this
device? Perhaps some self-powered external HDD?

2018-03-21 17:56 GMT+01:00 Mike Lothian <m...@fireburn.co.uk>:
> It had both, as did my follow up, the follow up should be more clear though
>
> On 21 March 2018 at 16:45, Menion <men...@gmail.com> wrote:
>> You sent the dmesg with quirks :u enabled
>> We need the one without quirks :u, when the device takes UAS driver
>> Bye
>>
>> 2018-03-21 17:41 GMT+01:00 Mike Lothian <m...@fireburn.co.uk>:
>>> Hi
>>>
>>> Please find attached my dmesg
>>>
>>> Cheers
>>>
>>> Mike
>>>
>>> On 21 March 2018 at 16:12, Oliver Neukum <oneu...@suse.com> wrote:
>>>> Am Mittwoch, den 21.03.2018, 17:09 +0100 schrieb Greg KH:
>>>>> > I'm guessing it doesn't quite match up with the rules already in place
>>>>> > in uas-detect.h
>>>>>
>>>>> That device has a quirk already as a "normal" usb-storage device.
>>>>> Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add quirk
>>>>> for mandatory READ_CAPACITY_16")
>>>>
>>>> That should cause different symptoms.
>>>>
>>>>> > Looks like it's an ASM1053 that can't do UAS
>>>>>
>>>>> No, it's not a UAS device, is someone trying to recycle device ids to do
>>>>> different things now?  That's not good :(
>>>>
>>>> The second interface looks like UAS though. The second interface looks
>>>> like UAS though. What exactly does happen when you ennumerate?
>>>> Dmesg please.
>>>>
>>>> We may need some exotic logic for these devices.
>>>>
>>>> Regards
>>>> Oliver
>>>>
--
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: ASMedia SATA Bridge not enumerating without quirk

[Menion]

You sent the dmesg with quirks :u enabled
We need the one without quirks :u, when the device takes UAS driver
Bye

2018-03-21 17:41 GMT+01:00 Mike Lothian :
> Hi
>
> Please find attached my dmesg
>
> Cheers
>
> Mike
>
> On 21 March 2018 at 16:12, Oliver Neukum  wrote:
>> Am Mittwoch, den 21.03.2018, 17:09 +0100 schrieb Greg KH:
>>> > I'm guessing it doesn't quite match up with the rules already in place
>>> > in uas-detect.h
>>>
>>> That device has a quirk already as a "normal" usb-storage device.
>>> Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add quirk
>>> for mandatory READ_CAPACITY_16")
>>
>> That should cause different symptoms.
>>
>>> > Looks like it's an ASM1053 that can't do UAS
>>>
>>> No, it's not a UAS device, is someone trying to recycle device ids to do
>>> different things now?  That's not good :(
>>
>> The second interface looks like UAS though. The second interface looks
>> like UAS though. What exactly does happen when you ennumerate?
>> Dmesg please.
>>
>> We may need some exotic logic for these devices.
>>
>> Regards
>> Oliver
>>
--
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: ASMedia SATA Bridge not enumerating without quirk

[Menion]

READ_CAPACITY_16 does not have anything to do in blacklisting via
quirks the device to usb-storage
I have checked it in 4.9.86 and it is not quirked to usb-storage:

/* Reported by Oliver Neukum  */
UNUSUAL_DEV(  0x174c, 0x55aa, 0x0100, 0x0100,
"ASMedia",
"AS2105",
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_NEEDS_CAP16),

2018-03-21 17:09 GMT+01:00 Greg KH :
> On Wed, Mar 21, 2018 at 03:39:06PM +, Mike Lothian wrote:
>> Hi
>>
>> I'm running kernel 4.9.86 on my router
>>
>> I have to:
>>
>> echo 174c:55aa:u > /sys/module/usb_storage/parameters/quirks
>>
>> To get it to work correctly
>>
>> I'm attaching the output of lsusb -v
>>
>> I'm guessing it doesn't quite match up with the rules already in place
>> in uas-detect.h
>
> That device has a quirk already as a "normal" usb-storage device.
> Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add quirk
> for mandatory READ_CAPACITY_16")
>
>> Looks like it's an ASM1053 that can't do UAS
>
> No, it's not a UAS device, is someone trying to recycle device ids to do
> different things now?  That's not good :(
>
> thanks,
>
> greg k-h
> --
> 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
--
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: ASMedia SATA Bridge not enumerating without quirk

[Menion]

Can you please attach dmesg output?

2018-03-21 16:39 GMT+01:00 Mike Lothian :
> Hi
>
> I'm running kernel 4.9.86 on my router
>
> I have to:
>
> echo 174c:55aa:u > /sys/module/usb_storage/parameters/quirks
>
> To get it to work correctly
>
> I'm attaching the output of lsusb -v
>
> I'm guessing it doesn't quite match up with the rules already in place
> in uas-detect.h
>
> Looks like it's an ASM1053 that can't do UAS
>
> Regards
>
> Mike
--
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: Forcibly bind a device to UAS

[Menion]

So in summary Orico is lying about this particular enclosure

2018-03-16 16:20 GMT+01:00 Alan Stern <st...@rowland.harvard.edu>:
> On Fri, 16 Mar 2018, Menion wrote:
>
>> Hi Alan
>> Yes, sorry, I thought it was simpler. I confirm that also the 4
>> endpoints required for UAS operation are missing, so everything is
>> coherent to say "no UASP sorry"
>> From the VID:PID you can see that the chipset is a JMS567, which does
>> support UASP: http://www.jmicron.com/PDF/brief/jms567.pdf
>> As mentioned, I have another enclosure (not the same hardware model of
>> this one) with exactly the same chipset (even the VID:PID is
>
> The VID and PID are determined by the firmware, not by the chipset.
>
>> identical) that show up as UASP capable when attached to the same Atom
>> embedded PC USB 3.1 port
>> For sure the firmware of the two devices is different
>> To recap: the capabilities are shown by the device itself, it is not
>> possible that the USB host itself takes the decision to "filter" out
>> some capabilities, right?
>
> Right.  The USB host does not filter anything; it just passes data
> between the computer and the device.
>
> 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

Re: Forcibly bind a device to UAS

[Menion]

Hi Alan
Yes, sorry, I thought it was simpler. I confirm that also the 4
endpoints required for UAS operation are missing, so everything is
coherent to say "no UASP sorry"
>From the VID:PID you can see that the chipset is a JMS567, which does
support UASP: http://www.jmicron.com/PDF/brief/jms567.pdf
As mentioned, I have another enclosure (not the same hardware model of
this one) with exactly the same chipset (even the VID:PID is
identical) that show up as UASP capable when attached to the same Atom
embedded PC USB 3.1 port
For sure the firmware of the two devices is different
To recap: the capabilities are shown by the device itself, it is not
possible that the USB host itself takes the decision to "filter" out
some capabilities, right?

2018-03-16 15:53 GMT+01:00 Alan Stern <st...@rowland.harvard.edu>:
> On Fri, 16 Mar 2018, Menion wrote:
>
>> Hi Greg
>> Yes Orico is a kind of crap, but it is not so easy to find those kind
>> of devices.
>> My concern is that we may see one of this crappy implementation of
>> device, such that it actually supports perfectly UASP but they
>> "forgot" to set something in the firmware, maybe just the capability
>> My question was more to see if there is already something in the
>> USB-STORAGE that allow it or if we may endup in another "quirks" for
>> addressing these problem
>
> It's not just a question of binding the uas driver to the device.  The
> driver has to know which USB endpoints to use for sending/receiving
> data and status, and that information is contained in the missing
> firmware.
>
> Without those values, even if you could somehow bind the driver to the
> device, the driver wouldn't be able to communicate with it.
>
>> Honestly, with all the concern I can have about Orico, if they advice
>> the device as UASP capable and the chipset support it, I think it
>> should really support it in the end
>
> How do you know that the chipset supports UAS?
>
>> The device is this one: http://www.orico.cc/goods.php?id=6538
>> Is it possible that the USB host (in my case it is a modern Intel USB
>> 3.1 controller from an Atom embedded PC) play a role in this?
>
> That is possible.  Maybe the chipset supports UAS only when it runs at
> USB-2 high speed (480 Mb/s) but not at USB-3 SuperSpeed (5 Gb/s).
>
>> I have another Orico multy bay, older, same JMS567 chipset that show
>> up as UASP capable
>
> 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

Re: Forcibly bind a device to UAS

[Menion]

Hi Greg
Yes Orico is a kind of crap, but it is not so easy to find those kind
of devices.
My concern is that we may see one of this crappy implementation of
device, such that it actually supports perfectly UASP but they
"forgot" to set something in the firmware, maybe just the capability
My question was more to see if there is already something in the
USB-STORAGE that allow it or if we may endup in another "quirks" for
addressing these problem
Honestly, with all the concern I can have about Orico, if they advice
the device as UASP capable and the chipset support it, I think it
should really support it in the end
The device is this one: http://www.orico.cc/goods.php?id=6538
Is it possible that the USB host (in my case it is a modern Intel USB
3.1 controller from an Atom embedded PC) play a role in this?
I have another Orico multy bay, older, same JMS567 chipset that show
up as UASP capable

2018-03-16 15:04 GMT+01:00 Greg KH <g...@kroah.com>:
> On Fri, Mar 16, 2018 at 02:10:43PM +0100, Menion wrote:
>> Hi all
>> I have in my hands a multi bay SATA enclosure, with some unidentified
>> SATA multiport but using the JMicron JMS567 USB to SATA bridge.
>> This bridge is known to support UASP but in this particular
>> implementation, due to something weird/buggy (most probably the
>> firmware) doesn't who up as UASP capable, in fact a lsusb -t shows no
>> bInterfaceProtocol 98:
>>
>> Bus 002 Device 003: ID 152d:0567 JMicron Technology Corp. / JMicron
>> USA Technology Corp. JMS567 SATA 6Gb/s bridge
>> Device Descriptor:
>>   bLength18
>>   bDescriptorType 1
>>   bcdUSB   3.00
>>   bDeviceClass0 (Defined at Interface level)
>>   bDeviceSubClass 0
>>   bDeviceProtocol 0
>>   bMaxPacketSize0 9
>>   idVendor   0x152d JMicron Technology Corp. / JMicron USA
>> Technology Corp.
>>   idProduct  0x0567 JMS567 SATA 6Gb/s bridge
>>   bcdDevice3.24
>>   iManufacturer   1 JMicron
>>   iProduct2 USB to ATA/ATAPI Bridge
>>   iSerial 3 0123456789ABCDEF
>>   bNumConfigurations  1
>>   Configuration Descriptor:
>> bLength 9
>> bDescriptorType 2
>> wTotalLength   44
>> bNumInterfaces  1
>> bConfigurationValue 1
>> iConfiguration  0
>> bmAttributes 0xc0
>>   Self Powered
>> MaxPower2mA
>> Interface Descriptor:
>>   bLength 9
>>   bDescriptorType 4
>>   bInterfaceNumber0
>>   bAlternateSetting   0
>>   bNumEndpoints   2
>>   bInterfaceClass 8 Mass Storage
>>   bInterfaceSubClass  6 SCSI
>>   bInterfaceProtocol 80 Bulk-Only
>>   iInterface  0
>>   Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x81  EP 1 IN
>> bmAttributes2
>>   Transfer TypeBulk
>>   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
>> bmAttributes2
>>   Transfer TypeBulk
>>   Synch Type   None
>>   Usage Type   Data
>> wMaxPacketSize 0x0400  1x 1024 bytes
>> bInterval   0
>> bMaxBurst  15
>> Binary Object Store Descriptor:
>>   bLength 5
>>   bDescriptorType15
>>   wTotalLength   22
>>   bNumDeviceCaps  2
>>   USB 2.0 Extension Device Capability:
>> bLength 7
>> bDescriptorType16
>> bDevCapabilityType  2
>> bmAttributes   0x0f0e
>>   Link Power Management (LPM) Supported
>>   SuperSpeed USB Device Capability:
>> bLength10
>> bDescriptorType16
>> bDevCapabilityType  3
>> bmAttributes 0x00
>> wSpeedsSupported   0x000e
>>   Device can operate at Full Speed (12Mbps)
>>   Device can operate at High Speed (480Mbps)
>>   Device can operate at SuperS

Forcibly bind a device to UAS

[Menion]

Hi all
I have in my hands a multi bay SATA enclosure, with some unidentified
SATA multiport but using the JMicron JMS567 USB to SATA bridge.
This bridge is known to support UASP but in this particular
implementation, due to something weird/buggy (most probably the
firmware) doesn't who up as UASP capable, in fact a lsusb -t shows no
bInterfaceProtocol 98:

Bus 002 Device 003: ID 152d:0567 JMicron Technology Corp. / JMicron
USA Technology Corp. JMS567 SATA 6Gb/s bridge
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   3.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 9
  idVendor   0x152d JMicron Technology Corp. / JMicron USA
Technology Corp.
  idProduct  0x0567 JMS567 SATA 6Gb/s bridge
  bcdDevice3.24
  iManufacturer   1 JMicron
  iProduct2 USB to ATA/ATAPI Bridge
  iSerial 3 0123456789ABCDEF
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   44
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xc0
  Self Powered
MaxPower2mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass 8 Mass Storage
  bInterfaceSubClass  6 SCSI
  bInterfaceProtocol 80 Bulk-Only
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  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
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0400  1x 1024 bytes
bInterval   0
bMaxBurst  15
Binary Object Store Descriptor:
  bLength 5
  bDescriptorType15
  wTotalLength   22
  bNumDeviceCaps  2
  USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType16
bDevCapabilityType  2
bmAttributes   0x0f0e
  Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
bLength10
bDescriptorType16
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: 0x0001
  Self Powered

The vendor, Orico, claims explicitly that the enclosure shall support
UASP. But without the bInterfaceProtocol 98 the device is not bind to
UAS driver. So the question is: is there a way to forcibly bind a
device to UAS?
Bye
--
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: Without US_FL_NEEDS_CAP16 read_capacity_10 is forced despite of the device capability and HDD size

[Menion]

Yeah
I am in touch with scsi mantainers
I have already suggested to lower it to KERN_DEBUG, not really pushed
it, but they have said that from their perspective, this is a
sub-optimal read_capacity path taken, that shall be logged
Also, since this flag is named "try_rc_10_first" I have also suggested
that once the read_capacity_16 succeed and the attached device needs
the rad_capacity_16 due to large capacity, the scsi subsystem could
set this flag to 0 internally, but I am not sure how they feel about
this (if feasible), I am waiting for an answer
Bye

2018-03-09 17:29 GMT+01:00 Alan Stern <st...@rowland.harvard.edu>:
> On Fri, 9 Mar 2018, Menion wrote:
>
>> Hi all
>> I am discussing about an issue I get with my Orico USBtoSATA 5 bays enclosure
>> The issue is that every 5 minutes the BTRFS perform a revalidate
>> action that will fill the dmesg with this log:
>>
>> [   98.917660] sd 0:0:0:1: [sdb] Very big device. Trying to use READ
>> CAPACITY(16).
>> [   99.057592] sd 0:0:0:0: [sda] Very big device. Trying to use READ
>> CAPACITY(16).
>> [   99.304848] sd 0:0:0:2: [sdc] Very big device. Trying to use READ
>> CAPACITY(16).
>> [   99.465374] sd 0:0:0:3: [sdd] Very big device. Trying to use READ
>> CAPACITY(16).
>> [   99.669241] sd 0:0:0:4: [sde] Very big device. Trying to use READ
>> CAPACITY(16).
>>
>> After some investigation I think I have found out the reason
>> The sd_read_capacity in scsi layer check if read_capacity_10 or
>> read_capacity_16 should be used
>> It does it based on what this function return:
>>
>> static int sd_try_rc16_first(struct scsi_device *sdp)
>> {
>> if (sdp->host->max_cmd_len < 16)
>> return 0;
>> if (sdp->try_rc_10_first)
>> return 0;
>> if (sdp->scsi_level > SCSI_SPC_2)
>> return 1;
>> if (scsi_device_protection(sdp))
>> return 1;
>> return 0;
>> }
>>
>> the problem is that in the usb to scsi glue layer, the try_rc_10_first
>> is picked like this:
>>
>> /*
>>  * Many devices do not respond properly to READ_CAPACITY_16.
>>  * Tell the SCSI layer to try READ_CAPACITY_10 first.
>>  * However some USB 3.0 drive enclosures return capacity
>>  * modulo 2TB. Those must use READ_CAPACITY_16
>>  */
>> if (!(us->fflags & US_FL_NEEDS_CAP16))
>> sdev->try_rc_10_first = 1;
>>
>> Are we sure this is the correct option? I mean to me the default
>> should be to go for rc_10 if there is a specific request in the
>> unusual devices, rather then if we dont' need cap16 we go for it,
>> like:
>>
>> if ((us->fflags & US_FL_NEEDS_CAP10))
>> sdev->try_rc_10_first = 1;
>>
>> What you think about?
>
> I think there used to be a lot of USB devices which would work with
> READ CAPACITY 10 but would not work with READ CAPACITY 16.  The
> situation may not be quite so bad nowadays, but I would still prefer to
> have the kernel try RC10 first in all cases except when the NEEDS_CAP16
> flag is set.
>
> As for the the SCSI messages filling your log every 5 minutes, perhaps
> the SCSI maintainers could be convinced to change that message to be
> debug level.  It would still occupy space in the kernel's log buffer,
> but by default it would be ignored by userspace logging programs.
>
> If we changed the strategy the way you suggest, we would probably get a
> lot of errors from older devices that don't support RC16.  Some of them
> might even crash when they receive the command, which would make them
> unusable until a NEEDS_CAP10 flag entry was created for them.
>
> Or to put it another way, I think the population of devices which
> misbehave when they receive RC16 is probably larger than the population
> of devices which misbehave when they receive RC10.  :-)
>
> 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

Without US_FL_NEEDS_CAP16 read_capacity_10 is forced despite of the device capability and HDD size

[Menion]

Hi all
I am discussing about an issue I get with my Orico USBtoSATA 5 bays enclosure
The issue is that every 5 minutes the BTRFS perform a revalidate
action that will fill the dmesg with this log:

[   98.917660] sd 0:0:0:1: [sdb] Very big device. Trying to use READ
CAPACITY(16).
[   99.057592] sd 0:0:0:0: [sda] Very big device. Trying to use READ
CAPACITY(16).
[   99.304848] sd 0:0:0:2: [sdc] Very big device. Trying to use READ
CAPACITY(16).
[   99.465374] sd 0:0:0:3: [sdd] Very big device. Trying to use READ
CAPACITY(16).
[   99.669241] sd 0:0:0:4: [sde] Very big device. Trying to use READ
CAPACITY(16).

After some investigation I think I have found out the reason
The sd_read_capacity in scsi layer check if read_capacity_10 or
read_capacity_16 should be used
It does it based on what this function return:

static int sd_try_rc16_first(struct scsi_device *sdp)
{
if (sdp->host->max_cmd_len < 16)
return 0;
if (sdp->try_rc_10_first)
return 0;
if (sdp->scsi_level > SCSI_SPC_2)
return 1;
if (scsi_device_protection(sdp))
return 1;
return 0;
}

the problem is that in the usb to scsi glue layer, the try_rc_10_first
is picked like this:

/*
 * Many devices do not respond properly to READ_CAPACITY_16.
 * Tell the SCSI layer to try READ_CAPACITY_10 first.
 * However some USB 3.0 drive enclosures return capacity
 * modulo 2TB. Those must use READ_CAPACITY_16
 */
if (!(us->fflags & US_FL_NEEDS_CAP16))
sdev->try_rc_10_first = 1;

Are we sure this is the correct option? I mean to me the default
should be to go for rc_10 if there is a specific request in the
unusual devices, rather then if we dont' need cap16 we go for it,
like:

if ((us->fflags & US_FL_NEEDS_CAP10))
sdev->try_rc_10_first = 1;

What you think about?
Bye
--
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

Jmicron device 152d:0567 UAS off for some enclosure

[Menion]

Hi all
I am currently using two multi-bay USB-SATA3 enclosure with JMicron
JMS537 chipset 152d:0567
They are an Orico 9558ru3 and an Orico ns500rc3
According to the USB info they both use the JMS567 USBtoSATA bridge, I
cannot tell anything about the NS500rc3 SATA multiport chipset, while
the 9558ru3 is the JMB394
The firmware is different for sure
The strange thing here is that 9558ru3 goes in UAS mode (but it has
some problem already reported in the mainling list) unless I add the
quirks to modprobe.d, while the ns500rc3 silently stay in usb-storage
even if there are no quirks in modprobe.d
So somehow the usb-storage decides to turn off UAS for the ns500rc3
but the decision is clearly not taken on the vid:pid, and I would like
to understand how
Attached the dmesg without any quirks
The only suspecting row I can see is:

[3.894937] usb-storage 2-1.1:1.0: Quirks match for vid 152d pid
0567: 500


and here the usb info

menion@Menionubuntu:~$ lsusb
Bus 002 Device 005: ID 152d:0567 JMicron Technology Corp. / JMicron
USA Technology Corp. JMS567 SATA 6Gb/s bridge
Bus 002 Device 004: ID 1058:107c Western Digital Technologies, Inc.
Elements Desktop (WDBWLG)
Bus 002 Device 003: ID 152d:0567 JMicron Technology Corp. / JMicron
USA Technology Corp. JMS567 SATA 6Gb/s bridge
Bus 002 Device 002: ID 05e3:0612 Genesys Logic, Inc.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 003: ID 0681:0101 Siemens Information and Communication Products
Bus 001 Device 004: ID 1058:1021 Western Digital Technologies, Inc.
Elements Desktop (WDBAAU)
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
menion@Menionubuntu:~$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
|__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
|__ Port 4: Dev 5, If 0, Class=Mass Storage, Driver=uas, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/7p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 2: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 3: Dev 5, If 0, Class=Vendor Specific Class,
Driver=dvb_usb_rtl28xxu, 480M
|__ Port 3: Dev 5, If 1, Class=Vendor Specific Class, Driver=, 480M
menion@Menionubuntu:~$ dmesg
[0.00] Linux version 4.15.5-041505-generic (kernel@gloin) (gcc version 
7.2.0 (Ubuntu 7.2.0-8ubuntu3.2)) #201802221031 SMP Thu Feb 22 15:32:28 UTC 2018
[0.00] Command line: BOOT_IMAGE=/@/boot/vmlinuz-4.15.5-041505-generic 
root=UUID=6db4baf7-fda8-41ac-a6ad-1ca7b083430f ro rootflags=subvol=@
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Centaur CentaurHauls
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0008efff] usable
[0.00] BIOS-e820: [mem 0x0008f000-0x0008] ACPI NVS
[0.00] BIOS-e820: [mem 0x0009-0x0009dfff] usable
[0.00] BIOS-e820: [mem 0x0009e000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x201f] reserved
[0.00] BIOS-e820: [mem 0x2020-0x7b631fff] usable
[0.00] BIOS-e820: [mem 0x7b632000-0x7b661fff] reserved
[0.00] BIOS-e820: [mem 0x7b662000-0x7b685fff] usable
[0.00] BIOS-e820: [mem 0x7b686000-0x7b76bfff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7b76c000-0x7ba20fff] reserved
[0.00] BIOS-e820: [mem 0x7ba21000-0x7ba71fff] type 20
[0.00] BIOS-e820: [mem 0x7ba72000-0x7ba76fff] usable
[0.00] BIOS-e820: [mem 0x7ba77000-0x7ba77fff] reserved
[0.00] BIOS-e820: [mem 0x7ba78000-0x7ba7afff] usable
[0.00] BIOS-e820: [mem 0x7ba7b000-0x7ba7bfff] reserved
[0.00] BIOS-e820: [mem 0x7ba7c000-0x7bff] usable
[0.00] BIOS-e820: [mem 0xe000-0xe3ff] reserved
[0.00] BIOS-e820: [mem 0xfea0-0xfeaf] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed01000-0xfed01fff] reserved
[0.00] BIOS-e820: [mem 0xfed03000-0xfed03fff

Re: JMicron based usb 3.0 to sata enclosure, hangs, numerous errors

[Menion]

 host2: uas_eh_device_reset_handler success
[ 2696.612066] scsi host2: uas_eh_device_reset_handler start
[ 2696.691299] usb 2-1.4: reset SuperSpeed USB device number 4 using xhci_hcd
[ 2696.714701] scsi host2: uas_eh_device_reset_handler success


2018-02-14 9:29 GMT+01:00 Menion <men...@gmail.com>:
> Upgraded to 4.15.3 and now UAS works, strange...
> Anyhow now the enclosure is connected via an USB 3.0 HUB (self powered
> in my case) and it seems to be stable
> Devs, apparently there is some problem operating this chipset with
> Intel USB controller directly
> I have googled a little bit aroud and actually found someone
> complaining of a possible similar issue also on Windows:
>
> http://goughlui.com/2015/11/01/review-orico-usb-3-0-5-bay-raid-hdd-enclosure-9558ru3-part-2/
>
> Note that the USB controller I have is identical to the Chris one:
>
> 00:14.0 USB controller [0c03]: Intel Corporation Device [8086:22b5]
> (rev 36) (prog-if 30 [XHCI])
> Subsystem: Intel Corporation Device [8086:7270]
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>>TAbort- SERR-  Latency: 0
> Interrupt: pin A routed to IRQ 117
> Region 0: Memory at 9150 (64-bit, non-prefetchable) [size=64K]
> Capabilities: 
> Kernel driver in use: xhci_hcd
>
>
> 2018-02-14 8:36 GMT+01:00 Menion <men...@gmail.com>:
>> That is very strange
>> My device has same vid:pid of your one, but it goes blacklisted...
>> I am running kernel 4.15.1, I will try to upgrade
>> What kind of enclosure is yours? Mine is an Orico 9553RU3 5 bay
>> enclosure with RAID
>> Bye
>>
>> 2018-02-13 23:41 GMT+01:00 Chris Murphy <li...@colorremedies.com>:
>>> On Mon, Feb 12, 2018 at 12:57 AM, Menion <men...@gmail.com> wrote:
>>>
>>>>
>>>> I wanted to test my enclosure with an hub, but I have just realized
>>>> that now the JMS567 is UAS blacklisted by default in kernel
>>>> 4.15.x.
>>>> Can you check if it still works removing the dedicated hub external
>>>> power supply?
>>>
>>>
>>> I've upgraded to 4.15.3, and it does not appear to be blacklisted for uas
>>> driver.
>>>
>>> kernel: usbcore: registered new interface driver usb-storage
>>> kernel: scsi host2: uas
>>> kernel: usbcore: registered new interface driver uas
>>>
>>>
>>>
>>> Full kernel messages upon insertion directly to the computer's USB port
>>> (hub not involved at all):
>>> https://paste.fedoraproject.org/paste/bPPAl~ngYjktfC--i7NqJA/raw
>>>
>>>
>>>
>>> --
>>> Chris Murphy
--
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: JMicron based usb 3.0 to sata enclosure, hangs, numerous errors

[Menion]

Upgraded to 4.15.3 and now UAS works, strange...
Anyhow now the enclosure is connected via an USB 3.0 HUB (self powered
in my case) and it seems to be stable
Devs, apparently there is some problem operating this chipset with
Intel USB controller directly
I have googled a little bit aroud and actually found someone
complaining of a possible similar issue also on Windows:

http://goughlui.com/2015/11/01/review-orico-usb-3-0-5-bay-raid-hdd-enclosure-9558ru3-part-2/

Note that the USB controller I have is identical to the Chris one:

00:14.0 USB controller [0c03]: Intel Corporation Device [8086:22b5]
(rev 36) (prog-if 30 [XHCI])
Subsystem: Intel Corporation Device [8086:7270]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- SERR- 
Kernel driver in use: xhci_hcd


2018-02-14 8:36 GMT+01:00 Menion <men...@gmail.com>:
> That is very strange
> My device has same vid:pid of your one, but it goes blacklisted...
> I am running kernel 4.15.1, I will try to upgrade
> What kind of enclosure is yours? Mine is an Orico 9553RU3 5 bay
> enclosure with RAID
> Bye
>
> 2018-02-13 23:41 GMT+01:00 Chris Murphy <li...@colorremedies.com>:
>> On Mon, Feb 12, 2018 at 12:57 AM, Menion <men...@gmail.com> wrote:
>>
>>>
>>> I wanted to test my enclosure with an hub, but I have just realized
>>> that now the JMS567 is UAS blacklisted by default in kernel
>>> 4.15.x.
>>> Can you check if it still works removing the dedicated hub external
>>> power supply?
>>
>>
>> I've upgraded to 4.15.3, and it does not appear to be blacklisted for uas
>> driver.
>>
>> kernel: usbcore: registered new interface driver usb-storage
>> kernel: scsi host2: uas
>> kernel: usbcore: registered new interface driver uas
>>
>>
>>
>> Full kernel messages upon insertion directly to the computer's USB port
>> (hub not involved at all):
>> https://paste.fedoraproject.org/paste/bPPAl~ngYjktfC--i7NqJA/raw
>>
>>
>>
>> --
>> Chris Murphy
--
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: JMicron based usb 3.0 to sata enclosure, hangs, numerous errors

[Menion]

That is very strange
My device has same vid:pid of your one, but it goes blacklisted...
I am running kernel 4.15.1, I will try to upgrade
What kind of enclosure is yours? Mine is an Orico 9553RU3 5 bay
enclosure with RAID
Bye

2018-02-13 23:41 GMT+01:00 Chris Murphy <li...@colorremedies.com>:
> On Mon, Feb 12, 2018 at 12:57 AM, Menion <men...@gmail.com> wrote:
>
>>
>> I wanted to test my enclosure with an hub, but I have just realized
>> that now the JMS567 is UAS blacklisted by default in kernel
>> 4.15.x.
>> Can you check if it still works removing the dedicated hub external
>> power supply?
>
>
> I've upgraded to 4.15.3, and it does not appear to be blacklisted for uas
> driver.
>
> kernel: usbcore: registered new interface driver usb-storage
> kernel: scsi host2: uas
> kernel: usbcore: registered new interface driver uas
>
>
>
> Full kernel messages upon insertion directly to the computer's USB port
> (hub not involved at all):
> https://paste.fedoraproject.org/paste/bPPAl~ngYjktfC--i7NqJA/raw
>
>
>
> --
> Chris Murphy
--
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: JMicron based usb 3.0 to sata enclosure, hangs, numerous errors

[Menion]

2018-02-10 1:00 GMT+01:00 Chris Murphy <li...@colorremedies.com>:
> On Fri, Feb 9, 2018 at 3:57 AM, Menion <men...@gmail.com> wrote:
>> There are multiple reports of UAS issue together with JMS567 (from myself 
>> also)
>> Question: you mentioned that connecting the enclosure to an
>> intermediate USB HUB is a workaround.
>> Can you specify if your PC USB port is USB 3.0 and if the HUB is USB
>> 3.0 as well, and if it is self-powered or not?
>
> The port and hub are USB 3.0, and the hub has its own power supply (I
> guess that's self-powered, not bus powered?).
>
> [154810.100995] usb 2-4: new SuperSpeed USB device number 11 using xhci_hcd
> [154810.353775] usb 2-4: New USB device found, idVendor=2109, idProduct=0812
> [154810.353814] usb 2-4: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [154810.353841] usb 2-4: Product: USB3.0 Hub
> [154810.353862] usb 2-4: Manufacturer: VIA Labs, Inc.
> [154810.364888] hub 2-4:1.0: USB hub found
> [154810.365246] hub 2-4:1.0: 4 ports detected
> [154810.465557] usb 1-4: new high-speed USB device number 8 using xhci_hcd
> [154810.596631] usb 1-4: New USB device found, idVendor=2109, idProduct=2812
> [154810.596671] usb 1-4: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [154810.596697] usb 1-4: Product: USB2.0 Hub
> [154810.596718] usb 1-4: Manufacturer: VIA Labs, Inc.
> [154810.605720] hub 1-4:1.0: USB hub found
> [154810.606022] hub 1-4:1.0: 4 ports detected
>
>
>
> [chris@f27s ~]$ sudo lsusb
> Bus 002 Device 011: ID 2109:0812 VIA Labs, Inc. VL812 Hub
> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 001 Device 004: ID 8087:0a2a Intel Corp.
> Bus 001 Device 003: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
> Bus 001 Device 008: ID 2109:2812 VIA Labs, Inc. VL812 Hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> I'm not sure why there are two instances for this single hub with
> lsusb. The verbose output has some differences between the two
> instances.
>
>
> --
> Chris Murphy

You have two instance because usb 3.0 hubs present themself with an
USB 2.0 and USB 3.0 instance, due to the different stack.
I wanted to test my enclosure with an hub, but I have just realized
that now the JMS567 is UAS blacklisted by default in kernel
4.15.x.
Can you check if it still works removing the dedicated hub external
power supply?
Bye
--
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: JMicron based usb 3.0 to sata enclosure, hangs, numerous errors

[Menion]

There are multiple reports of UAS issue together with JMS567 (from myself also)
Question: you mentioned that connecting the enclosure to an
intermediate USB HUB is a workaround.
Can you specify if your PC USB port is USB 3.0 and if the HUB is USB
3.0 as well, and if it is self-powered or not?

2018-02-09 4:17 GMT+01:00 Chris Murphy :
> Problem summary:
> Out of the box, a USB 3.0 SATA 6.0 enclosure, hangs during reads or
> writes and spits out some errors, when directly connected to a
> computer's USB port. When connected via a USB hub, uas is still used,
> but the errors do not occur. When setting a quirk to blacklist the
> drive from uas, the problem doesn't happen when directly connected
> either.
>
> Host:
>
> Intel ® NUC Board NUC5PPYB
> kernel 4.14.18-300.fc27.x86_64
> Fedora 27
> One 1.5A port
> Multiple 900 mA ports
>
> lspci -vvnn
>
> 00:14.0 USB controller [0c03]: Intel Corporation Atom/Celeron/Pentium
> Processor x5-E8000/J3xxx/N3xxx Series USB xHCI Controller [8086:22b5]
> (rev 21) (prog-if 30 [XHCI])
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> SERR-  Latency: 0
> Interrupt: pin A routed to IRQ 116
> Region 0: Memory at 8140 (64-bit, non-prefetchable) [size=64K]
> Capabilities: [70] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
> PME(D0-,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
> Address: fee0300c  Data: 4122
> Kernel driver in use: xhci_hcd
>
>
> Enclosure:
>
> $ sudo lsusb -v
>
> Bus 002 Device 003: ID 152d:0567 JMicron Technology Corp. / JMicron
> USA Technology Corp. JMS567 SATA 6Gb/s bridge
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   3.00
>   bDeviceClass0
>   bDeviceSubClass 0
>   bDeviceProtocol 0
>   bMaxPacketSize0 9
>   idVendor   0x152d JMicron Technology Corp. / JMicron USA
> Technology Corp.
>   idProduct  0x0567 JMS567 SATA 6Gb/s bridge
>   bcdDevice7.01
>   iManufacturer   1 JMicron
>   iProduct2 USB3.0 Device
>   iSerial 3 DB98765433E84
>   bNumConfigurations  1
>   Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength  121
> bNumInterfaces  1
> bConfigurationValue 1
> iConfiguration  0
> bmAttributes 0x80
>   (Bus Powered)
> MaxPower  896mA
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber0
>   bAlternateSetting   0
>   bNumEndpoints   2
>   bInterfaceClass 8 Mass Storage
>   bInterfaceSubClass  6 SCSI
>   bInterfaceProtocol 80 Bulk-Only
>   iInterface  0
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81  EP 1 IN
> bmAttributes2
>   Transfer TypeBulk
>   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
> bmAttributes2
>   Transfer TypeBulk
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0400  1x 1024 bytes
> bInterval   0
> bMaxBurst  15
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber0
>   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
> bmAttributes2
>   Transfer TypeBulk
>   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
> bmAttributes2

Re: usb: uas : working uas devices ?

[Menion]

In which kernel version this commit endup?
The unusual device will be downgraded to BOT mode?

2018-02-07 15:52 GMT+01:00 Tushar Nimkar <tushar.n...@gmail.com>:
> JMS567 is already reported and under "unusual_devs.h"
> correct me if wrong.
>
> commit ID :d92146222c96c22b45486961be642b1ba1c4129c
>
> On Wed, Feb 7, 2018 at 8:09 PM, Menion <men...@gmail.com> wrote:
>> This is not fully true
>> Multibay enclosure may have problem, see my thread "uas failing on
>> multiple disk access on a jmicron JMS567 bridge"
>>
>> 2018-02-07 15:38 GMT+01:00 Tushar Nimkar <tushar.n...@gmail.com>:
>>> Thanks Adrian and Greg.
>>>
>>> On Wed, Feb 7, 2018 at 7:59 PM, Greg KH <g...@kroah.com> wrote:
>>>> On Wed, Feb 07, 2018 at 12:13:36PM +0530, Tushar Nimkar wrote:
>>>>> Can anyone help me in selecting UASP/UAS device ?
>>>>> Any link/ model no. will be helpful.
>>>>> I could see unusual_uas.h has many devices which are not behaving well
>>>>> so don't want to take risk in selecting.
>>>>
>>>> The majority work just fine, I've bought lots of them and they all work
>>>> with no issues at all.  Look for good reviews on sites like amazon
>>>> saying that the enclosure works on Linux, and you should be fine.
>>>>
>>>> good luck!
>>>>
>>>> greg k-h
>>>
>>>
>>>
>>> --
>>> Best Regards,
>>> Tushar R Nimkar
>>> Mob No : +91-9052258800
>>> --
>>> 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
>
>
>
> --
> Best Regards,
> Tushar R Nimkar
> Mob No : +91-9052258800
--
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: usb: uas : working uas devices ?

[Menion]

This is not fully true
Multibay enclosure may have problem, see my thread "uas failing on
multiple disk access on a jmicron JMS567 bridge"

2018-02-07 15:38 GMT+01:00 Tushar Nimkar :
> Thanks Adrian and Greg.
>
> On Wed, Feb 7, 2018 at 7:59 PM, Greg KH  wrote:
>> On Wed, Feb 07, 2018 at 12:13:36PM +0530, Tushar Nimkar wrote:
>>> Can anyone help me in selecting UASP/UAS device ?
>>> Any link/ model no. will be helpful.
>>> I could see unusual_uas.h has many devices which are not behaving well
>>> so don't want to take risk in selecting.
>>
>> The majority work just fine, I've bought lots of them and they all work
>> with no issues at all.  Look for good reviews on sites like amazon
>> saying that the enclosure works on Linux, and you should be fine.
>>
>> good luck!
>>
>> greg k-h
>
>
>
> --
> Best Regards,
> Tushar R Nimkar
> Mob No : +91-9052258800
> --
> 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
--
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: uas failing on multiple disk access on a jmicron JMS567 bridge

[Menion]

2018-02-06 11:18 GMT+01:00 Oliver Neukum <oneu...@suse.com>:
> Am Mittwoch, den 31.01.2018, 12:45 +0100 schrieb Menion:
>> you can see that short while after the two HD are mounted I start to
>> get any sort of USB command errors.
>
> Well, no, all errors are Write(10). Thus my question whether you can
> trigger it with any other command. Does it error out with Read(10),
> too?
>
> Regards
> Oliver
>

No
As said the problems start when there are multiple write operation
This is a multi bay enclosure. If there is only one HDD inside, there
are no problems
Unfortunately it is not simple to "silence" the activity on the HDD,
since I run BTRFS on it.
That is why I have asked also for a way to provide more info. If you
google a little bit you will see that it is a very common problem
--
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: uas failing on multiple disk access on a jmicron JMS567 bridge

[Menion]

Hello
Actually the mentioned ones are the very first synthomps that
something is going wrong:

Jan 27 08:56:06 Menionubuntu systemd[1]:
dev-disk-by\x2duuid-ba1e0d88\x2d2e26\x2d499d\x2d8fe3\x2d458b9c53349a.device:
Dev dev-disk-by\x2duuid-ba1e0d88\x2d2e26\x2d499d\x2d8fe3\x2d458b9c53349a.device
appeared twice wi$
Jan 27 08:56:06 Menionubuntu systemd[2308]:
dev-disk-by\x2duuid-ba1e0d88\x2d2e26\x2d499d\x2d8fe3\x2d458b9c53349a.device:
Dev dev-disk-by\x2duuid-ba1e0d88\x2d2e26\x2d499d\x2d8fe3\x2d458b9c53349a.device
appeared twice$
Jan 27 08:57:31 Menionubuntu systemd[1]: Started Session 6 of user menion.
Jan 27 08:57:54 Menionubuntu kernel: [  631.779771] sd 0:0:0:1: [sdb]
tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.779792] sd 0:0:0:1: [sdb]
tag#1 CDB: Write(10) 2a 00 00 35 ca 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.780155] sd 0:0:0:1: [sdb]
tag#14 uas_eh_abort_handler 0 uas-tag 15 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.780173] sd 0:0:0:1: [sdb]
tag#14 CDB: Write(10) 2a 00 00 35 c6 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.783903] sd 0:0:0:1: [sdb]
tag#13 uas_eh_abort_handler 0 uas-tag 14 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.783920] sd 0:0:0:1: [sdb]
tag#13 CDB: Write(10) 2a 00 00 35 c2 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.787408] sd 0:0:0:1: [sdb]
tag#12 uas_eh_abort_handler 0 uas-tag 13 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.787429] sd 0:0:0:1: [sdb]
tag#12 CDB: Write(10) 2a 00 00 35 be 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.791055] sd 0:0:0:1: [sdb]
tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.791076] sd 0:0:0:1: [sdb]
tag#0 CDB: Write(10) 2a 00 00 35 ba 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.795040] sd 0:0:0:1: [sdb]
tag#11 uas_eh_abort_handler 0 uas-tag 12 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.795062] sd 0:0:0:1: [sdb]
tag#11 CDB: Write(10) 2a 00 00 35 b6 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.797905] sd 0:0:0:1: [sdb]
tag#10 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.797925] sd 0:0:0:1: [sdb]
tag#10 CDB: Write(10) 2a 00 00 35 b2 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.801819] sd 0:0:0:1: [sdb]
tag#9 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.801838] sd 0:0:0:1: [sdb]
tag#9 CDB: Write(10) 2a 00 00 35 ae 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.805521] sd 0:0:0:1: [sdb]
tag#8 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.805543] sd 0:0:0:1: [sdb]
tag#8 CDB: Write(10) 2a 00 00 35 aa 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.808320] sd 0:0:0:1: [sdb]
tag#7 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.808338] sd 0:0:0:1: [sdb]
tag#7 CDB: Write(10) 2a 00 00 35 a6 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.812207] sd 0:0:0:1: [sdb]
tag#6 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.812224] sd 0:0:0:1: [sdb]
tag#6 CDB: Write(10) 2a 00 00 35 a2 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.815606] sd 0:0:0:1: [sdb]
tag#5 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.815623] sd 0:0:0:1: [sdb]
tag#5 CDB: Write(10) 2a 00 00 35 9e 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.819379] sd 0:0:0:1: [sdb]
tag#4 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.819397] sd 0:0:0:1: [sdb]
tag#4 CDB: Write(10) 2a 00 00 35 9a 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.823351] sd 0:0:0:1: [sdb]
tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.823372] sd 0:0:0:1: [sdb]
tag#3 CDB: Write(10) 2a 00 00 35 96 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.826296] sd 0:0:0:1: [sdb]
tag#27 uas_eh_abort_handler 0 uas-tag 28 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.826317] sd 0:0:0:1: [sdb]
tag#27 CDB: Write(10) 2a 00 00 35 92 70 00 04 00 00

you can see that short while after the two HD are mounted I start to
get any sort of USB command errors. The enclosure can run 5 HDD, but
when I took the logs, only 2 HDD were mounted, so I think I can
exclude any kind of power supply issue also because in BOT mode I
didn't get any kind of problem 3 days of operation.
I cannot tell if the firmware is buggy, but it is a quite standard
40.16 Jlink firmware version. If you go to the mailing list logs, with
the same subject there is another user reporting the same problem
fixed by the same workaround (blacklist and use BOT mode)
Also, if you google a little bit around, there are a number of same

uas failing on multiple disk access on a jmicron JMS567 bridge

[Menion]

Hello
I am trying to follow up on the original thread, opened on this issue
by Christoph Gohle May 2017 (same email subject)
I confirm that the same issue is still present on kernel 4.14.15
(Mainline build for Ubuntu xenial, amd64)
My enclosure is an Orico 9558RU3, using JMS567 USB 3.0 to SATA bridge
together with JMB394 multiplexer with RAID
As soon as more than one HD in inserted in the enclosure, when
parallel write operation are send to the HDs, you start to get
immediately CMD error on UAS driver, after a while the USB gets in an
inconsistent status and you are forced to reset.

Jan 27 08:59:53 Menionubuntu kernel: [  750.564095] sd 0:0:0:1: [sdb]
tag#22 CDB: Write(10) 2a 00 00 5e fb 10 00 04 00 00
Jan 27 08:59:53 Menionubuntu kernel: [  750.567579] sd 0:0:0:1: [sdb]
tag#17 uas_eh_abort_handler 0 uas-tag 18 inflight: CMD OUT
Jan 27 08:59:53 Menionubuntu kernel: [  750.567604] sd 0:0:0:1: [sdb]
tag#17 CDB: Write(10) 2a 00 00 5e f7 10 00 04 00 00
Jan 27 08:59:53 Menionubuntu kernel: [  750.571280] sd 0:0:0:1: [sdb]
tag#16 uas_eh_abort_handler 0 uas-tag 17 inflight: CMD OUT
Jan 27 08:59:53 Menionubuntu kernel: [  750.571299] sd 0:0:0:1: [sdb]
tag#16 CDB: Write(10) 2a 00 00 5e f3 10 00 04 00 00
Jan 27 08:59:53 Menionubuntu kernel: [  750.575292] sd 0:0:0:1: [sdb]
tag#15 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT
Jan 27 08:59:53 Menionubuntu kernel: [  750.575304] sd 0:0:0:1: [sdb]
tag#15 CDB: Write(10) 2a 00 00 5e ef 10 00 04 00 00


With BTFS the things go even worst:

Jan 26 18:46:01 Menionubuntu kernel: [22961.078609] sd 0:0:0:0: [sda]
Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jan 26 18:46:02 Menionubuntu kernel: [22961.160317] sd 0:0:0:0: [sda]
tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jan 26 18:46:02 Menionubuntu kernel: [22961.160378] sd 0:0:0:0: [sda]
tag#0 Sense Key : Aborted Command [current]
Jan 26 18:46:02 Menionubuntu kernel: [22961.160523] sd 0:0:0:0: [sda]
tag#0 Add. Sense: No additional sense information
Jan 26 18:46:02 Menionubuntu kernel: [22961.160544] sd 0:0:0:0: [sda]
tag#0 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00
Jan 26 18:46:02 Menionubuntu kernel: [22961.160558] print_req_error:
I/O error, dev sda, sector 0
Jan 26 18:46:02 Menionubuntu kernel: [22961.160597] Buffer I/O error
on dev sda, logical block 0, async page read
Jan 26 18:46:02 Menionubuntu kernel: [22961.244469] sd 0:0:0:0: [sda]
tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jan 26 18:46:02 Menionubuntu kernel: [22961.244539] sd 0:0:0:0: [sda]
tag#0 Sense Key : Aborted Command [current]
Jan 26 18:46:02 Menionubuntu kernel: [22961.244556] sd 0:0:0:0: [sda]
tag#0 Add. Sense: No additional sense information
Jan 26 18:46:02 Menionubuntu kernel: [22961.244577] sd 0:0:0:0: [sda]
tag#0 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00
Jan 26 18:46:02 Menionubuntu kernel: [22961.244590] print_req_error:
I/O error, dev sda, sector 0


Putting in UAS blacklist the device so running old BOT mode is a valid
workaround, the same enclosure with the same HDs run for days with no
USB error.
Due to the fact that I am running JBOD on BTRFS, I really need to run
in BOT mode, but I can try to provide some logs, if anyone is willing
to pick up the issue.
Bye
--
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