A question about UAS

A question about UAS

[Aaron Dewes]

Hello!

Sorry if this suggestion/question sounds stupid, I don't have experience
with the kernel code and this mailing list.

I'm a contributor to Umbrel (getumbrel.com), and we provide a software
that allows to run a bitcoin node easily, and we've run into many people
having UAS issues, and we were manually adding quirks in this case. Now
I'm wondering if it is possible to disable UAS for all devices in the
kernel cmdline. This is my first question, but I also have another
suggestion. We've developed the following bash script to check for UAS
issues and automatically add quirks:

------

get_uas_string () {
   UDEVADM_DATA=$(sudo -u umbrel udevadm test /block/${block_device} 2> /dev/null) # Umbrel is the  main user on umbrel, and udevadm doesn't report the vendor id if running as root, which this script is
   ID_VENDOR=$(echo "${UDEVADM_DATA}" | grep "ID_VENDOR_ID" | sed 's/ID_VENDOR_ID=//')
   ID_MODEL=$(echo "${UDEVADM_DATA}" | grep "ID_MODEL_ID" | sed 's/ID_MODEL_ID=//')
   echo "${ID_VENDOR}:${ID_MODEL}:u"
}

if [[ $(dmesg) == *"uas_eh_abort_handler"* ]]; then
   echo "External storage might have UAS issues"
   UAS_STRING=$(get_uas_string)
   if [[ $(cat /boot/cmdline.txt) == *"${UAS_STRING}"* ]]; then
     sed "s/usb-storage.quirks=/usb-storage.quirks=$(get_uas_string),/g" -i /boot/cmdline.txt
     echo "Rebooting"
     sudo reboot
   fi
fi

-----

I was wondering if a check like this could be added to the kernel, so
every time uas_eh_abort_handler gets logged, which AFAIK only happens if
UAS has issues, a counter could be increased, so that, if it happens to
often, UAS gets disabled for that drive.

Are there any reasons not do do this because false positives could
happen? If yes, please let me know.

Aaron

Re: A question about UAS

[Greg KH]

On Sat, Mar 06, 2021 at 05:34:32PM +0100, Aaron Dewes wrote:
> Hello!
> 
> Sorry if this suggestion/question sounds stupid, I don't have experience
> with the kernel code and this mailing list.
> 
> I'm a contributor to Umbrel (getumbrel.com), and we provide a software
> that allows to run a bitcoin node easily, and we've run into many people
> having UAS issues

What specific UAS issues?  And why not just fix those instead?

> , and we were manually adding quirks in this case. Now
> I'm wondering if it is possible to disable UAS for all devices in the
> kernel cmdline.

Sure, just blacklist the uas kernel module, that prevents it from being
loaded and hopefully the device will degrade to the
old-school-and-dirt-slow usb-storage protocol.

Have you tried that?

> This is my first question, but I also have another
> suggestion. We've developed the following bash script to check for UAS
> issues and automatically add quirks:
> 
> ------
> 
> get_uas_string () {
>   UDEVADM_DATA=$(sudo -u umbrel udevadm test /block/${block_device} 2> /dev/null) # Umbrel is the  main user on umbrel, and udevadm doesn't report the vendor id if running as root, which this script is
>   ID_VENDOR=$(echo "${UDEVADM_DATA}" | grep "ID_VENDOR_ID" | sed 's/ID_VENDOR_ID=//')
>   ID_MODEL=$(echo "${UDEVADM_DATA}" | grep "ID_MODEL_ID" | sed 's/ID_MODEL_ID=//')
>   echo "${ID_VENDOR}:${ID_MODEL}:u"
> }
> 
> if [[ $(dmesg) == *"uas_eh_abort_handler"* ]]; then
>   echo "External storage might have UAS issues"
>   UAS_STRING=$(get_uas_string)
>   if [[ $(cat /boot/cmdline.txt) == *"${UAS_STRING}"* ]]; then
>     sed "s/usb-storage.quirks=/usb-storage.quirks=$(get_uas_string),/g" -i /boot/cmdline.txt
>     echo "Rebooting"
>     sudo reboot
>   fi
> fi
> 
> -----
> 
> I was wondering if a check like this could be added to the kernel, so
> every time uas_eh_abort_handler gets logged, which AFAIK only happens if
> UAS has issues, a counter could be increased, so that, if it happens to
> often, UAS gets disabled for that drive.

How do you "know" the next time you boot you really have the same drive
or not?  That type of logic is best done in userspace, the kernel is
just reporting the issues, it's up to userspace to determine if it wants
to not mount the drive or not.

But back to your root problem, what is wrong with UAS?  I've been using
it for a build system for Android for years just fine.  And that
stresses the CPU and drive really hard.

thanks,

greg k-h

Re: A question about UAS

[Alan Stern]

On Sat, Mar 06, 2021 at 06:02:47PM +0100, Greg KH wrote:
> On Sat, Mar 06, 2021 at 05:34:32PM +0100, Aaron Dewes wrote:
> > Hello!
> > 
> > Sorry if this suggestion/question sounds stupid, I don't have experience
> > with the kernel code and this mailing list.
> > 
> > I'm a contributor to Umbrel (getumbrel.com), and we provide a software
> > that allows to run a bitcoin node easily, and we've run into many people
> > having UAS issues
> 
> What specific UAS issues?  And why not just fix those instead?

Indeed.  It's always better to fix a problem than to cover it up.

> > , and we were manually adding quirks in this case. Now
> > I'm wondering if it is possible to disable UAS for all devices in the
> > kernel cmdline.
> 
> Sure, just blacklist the uas kernel module, that prevents it from being
> loaded and hopefully the device will degrade to the
> old-school-and-dirt-slow usb-storage protocol.

In fact it won't.  The usb-storage driver will see that the device can 
be managed by the uas driver, so it won't bind.  Then nothing will 
manage the device.

You actually have to turn off CONFIG_USB_UAS when the kernel is built.

Alan Stern

Re: A question about UAS

[Aaron Dewes]

> On Sat, Mar 06, 2021 at 05:34:32PM +0100, Aaron Dewes wrote:
>> Hello!
>>
>> Sorry if this suggestion/question sounds stupid, I don't have experience
>> with the kernel code and this mailing list.
>>
>> I'm a contributor to Umbrel (getumbrel.com), and we provide a software
>> that allows to run a bitcoin node easily, and we've run into many people
>> having UAS issues
> What specific UAS issues?  And why not just fix those instead?

Sorry, I should've been more specific. When I said UAS issues, I meant
that we've had many users who used drives that were incompatible with
UAS, and that script is our way to detect that and fix it, because the
kernel apparently often doesn't detect that, and I think that way would
be a way to actually automatically detect such issues.

Currently, drivers/usb/storage/unusual_devs.h disables UAS for a few
devices, but autodetecting would be better in my opinion.

>
>> , and we were manually adding quirks in this case. Now
>> I'm wondering if it is possible to disable UAS for all devices in the
>> kernel cmdline.
> Sure, just blacklist the uas kernel module, that prevents it from being
> loaded and hopefully the device will degrade to the
> old-school-and-dirt-slow usb-storage protocol.
>
> Have you tried that?
No, but I'll do that.
>
>> This is my first question, but I also have another
>> suggestion. We've developed the following bash script to check for UAS
>> issues and automatically add quirks:
>>
>> ------
>>
>> get_uas_string () {
>>    UDEVADM_DATA=$(sudo -u umbrel udevadm test /block/${block_device} 2> /dev/null) # Umbrel is the  main user on umbrel, and udevadm doesn't report the vendor id if running as root, which this script is
>>    ID_VENDOR=$(echo "${UDEVADM_DATA}" | grep "ID_VENDOR_ID" | sed 's/ID_VENDOR_ID=//')
>>    ID_MODEL=$(echo "${UDEVADM_DATA}" | grep "ID_MODEL_ID" | sed 's/ID_MODEL_ID=//')
>>    echo "${ID_VENDOR}:${ID_MODEL}:u"
>> }
>>
>> if [[ $(dmesg) == *"uas_eh_abort_handler"* ]]; then
>>    echo "External storage might have UAS issues"
>>    UAS_STRING=$(get_uas_string)
>>    if [[ $(cat /boot/cmdline.txt) == *"${UAS_STRING}"* ]]; then
>>      sed "s/usb-storage.quirks=/usb-storage.quirks=$(get_uas_string),/g" -i /boot/cmdline.txt
>>      echo "Rebooting"
>>      sudo reboot
>>    fi
>> fi
>>
>> -----
>>
>> I was wondering if a check like this could be added to the kernel, so
>> every time uas_eh_abort_handler gets logged, which AFAIK only happens if
>> UAS has issues, a counter could be increased, so that, if it happens to
>> often, UAS gets disabled for that drive.
> How do you "know" the next time you boot you really have the same drive
> or not?  That type of logic is best done in userspace, the kernel is
> just reporting the issues, it's up to userspace to determine if it wants
> to not mount the drive or not.
Okay, I wasn't sure about that.
> But back to your root problem, what is wrong with UAS?  I've been using
> it for a build system for Android for years just fine.  And that
> stresses the CPU and drive really hard.
>
> thanks,
>
> greg k-h

Thanks for your reply,

Aaron Dewes

Re: A question about UAS

[Alan Stern]

On Sat, Mar 06, 2021 at 06:27:06PM +0100, Aaron Dewes wrote:
> 
> > On Sat, Mar 06, 2021 at 05:34:32PM +0100, Aaron Dewes wrote:
> > > Hello!
> > > 
> > > Sorry if this suggestion/question sounds stupid, I don't have experience
> > > with the kernel code and this mailing list.
> > > 
> > > I'm a contributor to Umbrel (getumbrel.com), and we provide a software
> > > that allows to run a bitcoin node easily, and we've run into many people
> > > having UAS issues
> > What specific UAS issues?  And why not just fix those instead?
> 
> Sorry, I should've been more specific. When I said UAS issues, I meant
> that we've had many users who used drives that were incompatible with
> UAS, and that script is our way to detect that and fix it, because the
> kernel apparently often doesn't detect that, and I think that way would
> be a way to actually automatically detect such issues.

The kernel _does_ autodetect drives that don't claim to support uas.  
Are you saying that your users have drives which claim to support uas 
but don't actually support it?  If that's so, can you tell us what 
drives they are so we can put this information into the kernel?

And can you tell us what errors the users encounter?

Also, how can you be sure that the drives don't support uas at all, as 
opposed to supporting uas in general but not a few specific commands?

> Currently, drivers/usb/storage/unusual_devs.h disables UAS for a few
> devices, but autodetecting would be better in my opinion.

Autodetecting the way you want wouldn't really work very well.  It would 
require the user to plug in the drive and initiate some actiity on it 
which would generate a flurry of errors, so that the kernel could see 
that it should try usb-storage instead.  Then the user would have to 
unplug the drive and plug it in a second time so that usb-storage could 
manage it.

Alan Stern

Re: A question about UAS

[Aaron Dewes]

> On Sat, Mar 06, 2021 at 06:27:06PM +0100, Aaron Dewes wrote:
>>> On Sat, Mar 06, 2021 at 05:34:32PM +0100, Aaron Dewes wrote:
>>>> Hello!
>>>>
>>>> Sorry if this suggestion/question sounds stupid, I don't have experience
>>>> with the kernel code and this mailing list.
>>>>
>>>> I'm a contributor to Umbrel (getumbrel.com), and we provide a software
>>>> that allows to run a bitcoin node easily, and we've run into many people
>>>> having UAS issues
>>> What specific UAS issues?  And why not just fix those instead?
>> Sorry, I should've been more specific. When I said UAS issues, I meant
>> that we've had many users who used drives that were incompatible with
>> UAS, and that script is our way to detect that and fix it, because the
>> kernel apparently often doesn't detect that, and I think that way would
>> be a way to actually automatically detect such issues.
> The kernel _does_ autodetect drives that don't claim to support uas.
> Are you saying that your users have drives which claim to support uas
> but don't actually support it?  If that's so, can you tell us what
> drives they are so we can put this information into the kernel?

This is what we added to cmdline, but the list was too large, so we had
to remove a few for our latest release:

usb-storage.quirks=152d:1561:u,152d:1576:u,152d:0578:u,125f:a76a:u,04e8:61b6:u,174c:55aa:u,04e8:61f5:u,04e8:4001:u,1058:082a:u,2109:0711:u,152d:0562:u,7825:a2a4:u,04e8:4001:u

I don't remember all the drives, these were mostly reports from users
who had issues.

A few ones I could look up in our commit history:

- JMicron JMS578 and JMS579

- Samsung M3 Portable

- ADATA ED600

- PA023U3

- A SATA-to-USB adapter sold by "BerryBase", a German RPi-related shop

This is on kernel 5.4, so some might have already been added.

To me, it seems like most, if not all devices with the vendor id "152d"
have UAS issues.

> And can you tell us what errors the users encounter?
Either a complete crash & unmount of the connection or really slow
writing speed.
> Also, how can you be sure that the drives don't support uas at all, as
> opposed to supporting uas in general but not a few specific commands?
I'm not sure about that.
>> Currently, drivers/usb/storage/unusual_devs.h disables UAS for a few
>> devices, but autodetecting would be better in my opinion.
> Autodetecting the way you want wouldn't really work very well.  It would
> require the user to plug in the drive and initiate some actiity on it
> which would generate a flurry of errors, so that the kernel could see
> that it should try usb-storage instead.  Then the user would have to
> unplug the drive and plug it in a second time so that usb-storage could
> manage it.
>
> Alan Stern
Oh, I see, then that's not good.

Thank you for your reply!

Aaron Dewes

Re: A question about UAS

[Greg KH]

On Sat, Mar 06, 2021 at 07:39:09PM +0100, Aaron Dewes wrote:
> 
> > On Sat, Mar 06, 2021 at 06:27:06PM +0100, Aaron Dewes wrote:
> > > > On Sat, Mar 06, 2021 at 05:34:32PM +0100, Aaron Dewes wrote:
> > > > > Hello!
> > > > > 
> > > > > Sorry if this suggestion/question sounds stupid, I don't have experience
> > > > > with the kernel code and this mailing list.
> > > > > 
> > > > > I'm a contributor to Umbrel (getumbrel.com), and we provide a software
> > > > > that allows to run a bitcoin node easily, and we've run into many people
> > > > > having UAS issues
> > > > What specific UAS issues?  And why not just fix those instead?
> > > Sorry, I should've been more specific. When I said UAS issues, I meant
> > > that we've had many users who used drives that were incompatible with
> > > UAS, and that script is our way to detect that and fix it, because the
> > > kernel apparently often doesn't detect that, and I think that way would
> > > be a way to actually automatically detect such issues.
> > The kernel _does_ autodetect drives that don't claim to support uas.
> > Are you saying that your users have drives which claim to support uas
> > but don't actually support it?  If that's so, can you tell us what
> > drives they are so we can put this information into the kernel?
> 
> This is what we added to cmdline, but the list was too large, so we had
> to remove a few for our latest release:
> 
> usb-storage.quirks=152d:1561:u,152d:1576:u,152d:0578:u,125f:a76a:u,04e8:61b6:u,174c:55aa:u,04e8:61f5:u,04e8:4001:u,1058:082a:u,2109:0711:u,152d:0562:u,7825:a2a4:u,04e8:4001:u
> 
> I don't remember all the drives, these were mostly reports from users
> who had issues.
> 
> A few ones I could look up in our commit history:
> 
> - JMicron JMS578 and JMS579
> 
> - Samsung M3 Portable
> 
> - ADATA ED600
> 
> - PA023U3
> 
> - A SATA-to-USB adapter sold by "BerryBase", a German RPi-related shop
> 
> This is on kernel 5.4, so some might have already been added.
> 
> To me, it seems like most, if not all devices with the vendor id "152d"
> have UAS issues.

Care to make up a patch for this so that we can properly blacklist them
in the kernel?

thanks,

greg k-h

Re: A question about UAS

[Oliver Neukum]

Am Samstag, den 06.03.2021, 17:34 +0100 schrieb Aaron Dewes:

> I was wondering if a check like this could be added to the kernel, so
> every time uas_eh_abort_handler gets logged, which AFAIK only happens if
> UAS has issues, a counter could be increased, so that, if it happens to
> often, UAS gets disabled for that drive.
> 
> Are there any reasons not do do this because false positives could
> happen? If yes, please let me know.

Hi,

this is a normal part of SCSI error handling. We cannot just switch off
a driver for handling errors. That said, you are free to collect
statistics for SCSI devices and let user space do something with it,
but this does not belong into the kernel.

	Regards
		Oliver