Re: [PATCH v2] USB: uas: Add the no-UAS quirk for JMicron JMS561U

[Tim Schumacher <timschumi@gmx.de>]

On 25.01.20 19:37, Hans de Goede wrote:> Hi,
>
> On 1/25/20 6:00 PM, Tim Schumacher wrote:
>> The JMicron JMS561U (notably used in the Sabrent SATA-to-USB
>> bridge) appears to have UAS-related issues when copying large
>> amounts of data, causing it to stall.
>>
>> Disabling the advertised UAS (either through a command-line
>> quirk or through this patch) mitigates those issues.
>>
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Tim Schumacher <timschumi@gmx.de>
>
> Hmm, this is a quiete popular usb2sata bridge and disabling uas
> is quite bad for performance.

I haven't been able to notice any slowdown myself, averaging 350MB/s
while copying large files, before and after the patch. However, from
what I've been able to grasp, the actual advantage of UAS seems to
be located in even higher speeds, which I can't properly test with my
equipment.

It's a valid concern though, since SATA 3 theoretically goes way
higher than what I can reach.

>
> I notice that there is no link to a bug report and AFAIK we have
> no one else reporting this issue.

I haven't specifically looked on the kernel bug tracker yet, but I
found similiar UAS-related issues talking about the JMicron JMS567
and JMS579 on the Ubuntu kernel bug tracker [1], as well as the
Raspberry Pi bug tracker [2].

If it helps, I can make this a proper bug report first so that other
people can chime in, instead of burying the discussion in the mailing
list.

[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1789589
[2] https://github.com/raspberrypi/linux/issues/3070

>
> So this feels like a much too big hammer for the problem which you
> are seeing.
>
> When you say "stall" what exactly happens? Do you see any errors
> in dmesg for example?

Basically, the transfer just freezes at one point (be it an actual
file transfer or just browsing directories quite fast), and a few
seconds later, UAS-related errors start appearing in dmesg.

At this point, the device either never recovers and requires a reconnect
to work correctly or it eventually recovers (after about 15 to 20
seconds) and continues the transfer as expected.

A dmesg of the device failing to recover can be found here: [3]

I can't reproduce a case where the device recovers right now, but
I found a StackExchange question with the same problem and an attached
dmesg. The general content of those error messages (maybe apart
from the hex output) is similiar to what I've been seeing: [4]

I'll try and see if I can hit a recoverable error myself in the next
few days.

[3] https://pastebin.com/raw/ny128rB4
[4] https://pastebin.com/raw/i7KLzy6i

>
> Also note that using UAS, since it has much better performance,
> will often expose bugs which are not caused by it. One typical
> example is bus-powered devices where the USB port does not deliver
> enough power (typically the driver draws more then the port
> guanrantees). Copying large amounts of data on a fast device is
> a good way to make the current consumption go up and thus
> trigger these kind of issues.  Does the driver enclosure
> you see this on use a separate power supply, or is it
> bus-powered?

It is indeed a bus-powered enclosure/adapter, which I'm using with
an USB 3.0 port. The attached SSD is rated for 5V/0.7A. However,
(as mentioned above) I am reaching the same read speeds with and
without UAS, so I'm not quite sure whether it really is a power limit
caused by heavy load.

>
> Regards,
>
> Hans
>

Tim

>
>> ---
>> v2: Fixed entry order. Also, CCing the correct people now.
>> ---
>>    drivers/usb/storage/unusual_uas.h | 7 +++++++
>>    1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/usb/storage/unusual_uas.h b/drivers/usb/storage/unusual_uas.h
>> index 1b23741036ee..a590f4a0d4b9 100644
>> --- a/drivers/usb/storage/unusual_uas.h
>> +++ b/drivers/usb/storage/unusual_uas.h
>> @@ -73,6 +73,13 @@ UNUSUAL_DEV(0x152d, 0x0578, 0x0000, 0x9999,
>>    		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
>>    		US_FL_BROKEN_FUA),
>>
>> +/* Reported-by: Tim Schumacher <timschumi@gmx.de> */
>> +UNUSUAL_DEV(0x152d, 0x1561, 0x0000, 0x9999,
>> +		"JMicron",
>> +		"JMS561U",
>> +		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
>> +		US_FL_IGNORE_UAS),
>> +
>>    /* Reported-by: Hans de Goede <hdegoede@redhat.com> */
>>    UNUSUAL_DEV(0x2109, 0x0711, 0x0000, 0x9999,
>>    		"VIA",
>> --
>> 2.25.0
>>
>