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 notice that there is no link to a bug report and AFAIK we have no one else reporting this issue.
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?
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?
Regards,
Hans
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