* [PATCH] USB: uas: Add the no-UAS quirk for JMicron JMS561U @ 2020-01-25 6:48 Tim Schumacher 2020-01-25 16:10 ` Alan Stern 2020-01-25 17:00 ` [PATCH v2] " Tim Schumacher 0 siblings, 2 replies; 7+ messages in thread From: Tim Schumacher @ 2020-01-25 6:48 UTC (permalink / raw) To: stern; +Cc: linux-usb, timschumi, stable 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> --- 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..eaec7d4973b7 100644 --- a/drivers/usb/storage/unusual_uas.h +++ b/drivers/usb/storage/unusual_uas.h @@ -97,6 +97,13 @@ UNUSUAL_DEV(0x357d, 0x7788, 0x0000, 0x9999, USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_NO_REPORT_OPCODES | US_FL_IGNORE_UAS), +/* 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(0x4971, 0x1012, 0x0000, 0x9999, "Hitachi", -- 2.25.0 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] USB: uas: Add the no-UAS quirk for JMicron JMS561U 2020-01-25 6:48 [PATCH] USB: uas: Add the no-UAS quirk for JMicron JMS561U Tim Schumacher @ 2020-01-25 16:10 ` Alan Stern 2020-01-25 17:00 ` [PATCH v2] " Tim Schumacher 1 sibling, 0 replies; 7+ messages in thread From: Alan Stern @ 2020-01-25 16:10 UTC (permalink / raw) To: Tim Schumacher; +Cc: linux-usb, stable On Sat, 25 Jan 2020, 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> > --- > 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..eaec7d4973b7 100644 > --- a/drivers/usb/storage/unusual_uas.h > +++ b/drivers/usb/storage/unusual_uas.h > @@ -97,6 +97,13 @@ UNUSUAL_DEV(0x357d, 0x7788, 0x0000, 0x9999, > USB_SC_DEVICE, USB_PR_DEVICE, NULL, > US_FL_NO_REPORT_OPCODES | US_FL_IGNORE_UAS), > > +/* 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(0x4971, 0x1012, 0x0000, 0x9999, > "Hitachi", This entry was added in the wrong place; entries should be sorted by Vendor ID and Product ID, as described at the start of the file. Please move it to the proper location and resubmit. Alan Stern ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH v2] USB: uas: Add the no-UAS quirk for JMicron JMS561U 2020-01-25 6:48 [PATCH] USB: uas: Add the no-UAS quirk for JMicron JMS561U Tim Schumacher 2020-01-25 16:10 ` Alan Stern @ 2020-01-25 17:00 ` Tim Schumacher 2020-01-25 18:37 ` Hans de Goede 1 sibling, 1 reply; 7+ messages in thread From: Tim Schumacher @ 2020-01-25 17:00 UTC (permalink / raw) To: hdegoede; +Cc: stern, linux-usb, timschumi, stable 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> --- 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 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH v2] USB: uas: Add the no-UAS quirk for JMicron JMS561U 2020-01-25 17:00 ` [PATCH v2] " Tim Schumacher @ 2020-01-25 18:37 ` Hans de Goede 2020-01-25 19:59 ` Tim Schumacher 0 siblings, 1 reply; 7+ messages in thread From: Hans de Goede @ 2020-01-25 18:37 UTC (permalink / raw) To: Tim Schumacher; +Cc: stern, linux-usb, stable 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] USB: uas: Add the no-UAS quirk for JMicron JMS561U 2020-01-25 18:37 ` Hans de Goede @ 2020-01-25 19:59 ` Tim Schumacher 2020-01-26 15:21 ` Hans de Goede 0 siblings, 1 reply; 7+ messages in thread From: Tim Schumacher @ 2020-01-25 19:59 UTC (permalink / raw) To: Hans de Goede; +Cc: stern, linux-usb, stable 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 >> > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] USB: uas: Add the no-UAS quirk for JMicron JMS561U 2020-01-25 19:59 ` Tim Schumacher @ 2020-01-26 15:21 ` Hans de Goede 2020-01-26 20:46 ` Tim Schumacher 0 siblings, 1 reply; 7+ messages in thread From: Hans de Goede @ 2020-01-26 15:21 UTC (permalink / raw) To: Tim Schumacher; +Cc: stern, linux-usb, stable Hi, On 25-01-2020 20:59, Tim Schumacher wrote: > 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. The big difference is not so much linear throughput, as well as iops / random access patterns. UAS allows sending multiple data requests to the disk at once, which the old bulk mass storage protocol does not allow. Chances are that the times when you are seeing the hangs you are also accessing the disk in some other way while copying a large file. With the old mass storage protocol in this case the copy will pause and then your other access will happen and then the copy will resume. UAS allows both to happen "at once" and SSDs are very good at this. As you can imagine making the SSD do multiple things at once it is also something which really pushes the power-requirements up. > 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 "When the device is under load and more than 1 hardrive is acessed, the USB enclosure frequently restarts." In other words, when I cause the power consumption to go through the roof things crash. This smells very much like (yet another) power-supply problem. > [2] https://github.com/raspberrypi/linux/issues/3070 Raspberry Pi's are notorious for having issues supplying enough power to their USB ports due to the self-resetting electronic fuses they are using, which increase there resistance when the current demand peaks, which causes a voltage drop. > >> >> 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 Ok, so what we are seeing there is that the usb-sata bridge has basically completely crashed. Normally it should always recover from a crash. This really feels like a brownout (supply voltage too low) event has happened, as that is typically the only thing which will hang the bridge like this. > [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. As I've tried to explain above, UAS allows more then one command to be outstanding at once. Even if you are only copying a single file then the Linux kernel will send more requests for blocks further ahead in the file. This will make the SSD work harder to put the data in its buffer, so even if the average through put stays the same the peak energy consumption of the SSD may increase. So far I've not really heard or seen anything which indicates that there is a systematic problem with the JMS561U bridge. I'm actually pretty sure you will find similar bug reports for Windows... Have you tried using the drive in a different USB-3 port (on a different machine perhaps) and/or with a different (shorter) USB3 cable? 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 >>> >> > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] USB: uas: Add the no-UAS quirk for JMicron JMS561U 2020-01-26 15:21 ` Hans de Goede @ 2020-01-26 20:46 ` Tim Schumacher 0 siblings, 0 replies; 7+ messages in thread From: Tim Schumacher @ 2020-01-26 20:46 UTC (permalink / raw) To: Hans de Goede; +Cc: stern, linux-usb, stable On 26.01.20 16:21, Hans de Goede wrote: > Hi, > > On 25-01-2020 20:59, Tim Schumacher wrote: >> 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. > > The big difference is not so much linear throughput, as well as > iops / random access patterns. UAS allows sending multiple data > requests to the disk at once, which the old bulk mass storage > protocol does not allow. > > Chances are that the times when you are seeing the hangs you > are also accessing the disk in some other way while copying a large > file. With the old mass storage protocol in this case the copy > will pause and then your other access will happen and then the copy > will resume. UAS allows both to happen "at once" and SSDs are very good > at this. As you can imagine making the SSD do multiple things at once > it is also something which really pushes the power-requirements up. That makes sense, I haven't thought much about that. Let's put this patch on hold then until I can figure out whether it really is a power limit that I'm hitting. > >> 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 > > "When the device is under load and more than 1 hardrive is acessed, > the USB enclosure frequently restarts." > > In other words, when I cause the power consumption to go through the > roof things crash. This smells very much like (yet another) power-supply > problem. > >> [2] https://github.com/raspberrypi/linux/issues/3070 > > Raspberry Pi's are notorious for having issues supplying enough power > to their USB ports due to the self-resetting electronic fuses they > are using, which increase there resistance when the current demand > peaks, which causes a voltage drop. > > >> >>> >>> 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 > > Ok, so what we are seeing there is that the usb-sata bridge has basically > completely crashed. Normally it should always recover from a crash. > > This really feels like a brownout (supply voltage too low) event has > happened, as that is typically the only thing which will hang the > bridge like this. > >> [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. > > As I've tried to explain above, UAS allows more then one command > to be outstanding at once. Even if you are only copying a single file > then the Linux kernel will send more requests for blocks further ahead > in the file. This will make the SSD work harder to put the data in its > buffer, so even if the average through put stays the same the peak > energy consumption of the SSD may increase. > > So far I've not really heard or seen anything which indicates that > there is a systematic problem with the JMS561U bridge. I'm actually > pretty sure you will find similar bug reports for Windows... I set up my Windows installation again, so I'll check whether I get similiar issues on there. > > Have you tried using the drive in a different USB-3 port (on > a different machine perhaps) and/or with a different (shorter) USB3 > cable? I have tried this on both my PC (both front- and back-facing ports) and my Laptop, the latter failing as well, but less often. The cable is unfortunately joined to the enclosure itself, so I can't try a different one. > > Regards, > > Hans > I'll try a few things in the next days to figure out whether I can confirm that this is a power-related issue or if it happens on other platforms and computers. If I can't find anything related to those two causes, I'll probably report back with more information. 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 >>>> >>> >> > ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-01-26 20:46 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-01-25 6:48 [PATCH] USB: uas: Add the no-UAS quirk for JMicron JMS561U Tim Schumacher 2020-01-25 16:10 ` Alan Stern 2020-01-25 17:00 ` [PATCH v2] " Tim Schumacher 2020-01-25 18:37 ` Hans de Goede 2020-01-25 19:59 ` Tim Schumacher 2020-01-26 15:21 ` Hans de Goede 2020-01-26 20:46 ` Tim Schumacher
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.