Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot

On 2021-Dec-19, at 11:28, bob prohaska <fbsd at www.zefox.net> wrote:

> On Sun, Dec 19, 2021 at 12:55:12AM -0800, Mark Millard wrote:
>> 
>> http://www.zefox.net/~fbsd/slow_usb_notes shows:
>> 
>> umass0 on uhub1
>> umass0: <JMicron SABRENT, class 0/0, rev 2.10/12.14, addr 4> on usbus1
>> umass0:  SCSI over Bulk-Only; quirks = 0x8100
>> umass0:0:0: Attached to scbus0
>> . . .
>> a0 at umass-sim0 bus 0 scbus0 target 0 lun 0
>> da0: <SABRENT  1214> Fixed Direct Access SPC-4 SCSI device
>> da0: Serial Number 000000000000A
>> da0: 40.000MB/s transfers
>> da0: 953869MB (1953525168 512 byte sectors)
>> da0: quirks=0x2<NO_6_BYTE>
>> 
>> https://jamesachambers.com/fixing-storage-adapters-for-raspberry-pi-via-firmware-updates/
>> 
>> has material about SABRENT adapters:
>> 
>> QUOTE
>> Sabrent and Orico both have the worst track records for working storage adapters for the Pi. I don???t recommend them at all but they can sometimes be fixed.
>> END QUOTE
>> 
>> (Not that all models are bad.)
>> 
>> I've not found anything to identify the specific product
>> that you are using. He lists some specific ones as
>> problematical but possibly fixable:
>> 
>> 	??? EC-SSHD*
>> 	??? EC-UASP*
>> 	??? EC-UK30*
>> 	??? EC-UM3W*
>> 	??? EC-DFLT*
>> 	??? EC-NVME*
>> 	??? EC-TFNE*
>> 	??? EC-TFNB*
>> 
>> (The above are JMicro based.) Can you identify your adapter
>> type?
>> 
> 
> The enclosure is simply marked SABRENT EC_UASP, 
> The usb-sata bridge is marked   JMS576
>                                2026 QH8A3A A
>                                E76H20013

THat is one of the ones listed on

https://jamesachambers.com/fixing-storage-adapters-for-raspberry-pi-via-firmware-updates/

as potentially fixable (with quirks possibly involved). See:

https://www.sabrent.com/download/jmicron-sabrent-update-tool/

for SABRENT's Firmware-Update Tool. Looks like Windows7+ is
a required context for doing the firmware update.

I've not checked if FreeBSD has any quirks in place.

The quirks material on the https://jamesachambers.com/. . . page is not
for FreeBSD, but RaspiOS (and similar).

> The "product brief" is at
> https://www.jmicron.com/file/download/1015/JMS576_Product+Brief.pdf
> but it's more advertising than technical. It claims Windows and Mac
> support, the omission of linux/bsd isn't surprising. 
> 
> I've tried power-cycling the disk, it doesn't seem to have any
> effect on discovery using usb reset.
> 
> There is one slightly odd thing: Once the disk is found, it does
> not stay found. Left sitting at the u-boot prompt after discovery
> a subsequent usb reset frequently fails to find the disk and it's
> durably lost. A total system reset seems required to find it.
> 
> One other observation... I tried smartctl on both Pi3 and P4. On
> the Pi3 it failed:
> 
> root@pelorus:/usr/ports/sysutils/smartmontools # smartctl -a /dev/da0
> smartctl 7.2 2021-09-14 r5236 [FreeBSD 13.0-STABLE arm64] (local build)
> Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
> 
> Read NVMe Identify Controller failed: scsi error unsupported field in scsi command
> 
> On the Pi4 it worked:
> 
> root@nemesis:/usr/local/poudriere # smartctl -a /dev/da0
> smartctl 7.2 2021-09-14 r5236 [FreeBSD 14.0-CURRENT arm64] (local build)
> Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
> 
> === START OF INFORMATION SECTION ===
> Model Family:     Seagate Barracuda 2.5 5400
> Device Model:     ST1000LM048-2E7172
> Serial Number:    ZDEM543B
> ....[voluminous output snipped]
> 
> Might the difference in behavior be significant? 
> 

Unsure. But . . .

The power (current) requirements to get this drive spinning is double
what a USB2 port has for a maximum in the USB2 standard: The drive is
problematical unless power is being drawn from 2 USB2 ports for
the one drive. EC-UASP does not seem to support such
dual-USB2-port use. (The RPi*'s are not designed to provide extra
power on a USB2 port as far as I know.)

That things do not work well for USB2 port use is not surprising.

The startup current requirement is nearly as large as the total
current for USB on the RPi*'s. (The RPi*'s support less of a total
than the sum of the individual ports maximums: only 1200mA total.)

SSD's are a better match to RPi* power than spinning rust is, unless
the spinning rust has its own power supply and is already powered
before the RPi* is powered. There are types of cases that have such
independent power instead of being bus-powered. Bus-powered spinning
rust is a problem for single-port USB2 (and possibly even single-port
USB3).

===
Mark Millard
marklmi at yahoo.com