RPi 4B USB 3 support appears to still be broken in 13.0-RELEASE

Sat Apr 17 17:48:07 UTC 2021

On 2021-Apr-17, at 05:36, Robert Clausecker <fuz at fuz.su> wrote:

> Indeed I use a case with fans.  (specifically a Joy-IT milled aluminum
> case with 2 small fans).  Apart from the fans and the boot disk, no other
> peripherals are attached (using the serial console to access the system).
> 
> Detaching the fans doesn't make a difference.  I'll try and see if I can
> find a powered USB3 hub.
> 
> It is surprising that the RPi4 is supposedly not powerful enough to power
> a single M.2 SSD in an external enclosure.  What's also speaking against
> a power issue is that the drive works just fine on USB2.  Perhaps it's
> some sort of bug in the XHCI driver when too many IO requests are
> pending at once?  I'm not familiar with the specifics, but I could
> imagine ZFS being more demanding in this regard.
> 
> My offer to send you the drive over so you can reproduce this for
> yourself stands.

I have access to official RPi power supplies, as well as the
5.1V 3.5A ones that I actually use. So there is some chance
that I'd be able to show a compare/contrast of working vs. not
on the basis of that power supply distinction.

If the problem is not covered by the power supply issue, I
more likely would manage to repeat the problem but I'd be
unlikely to be able to analyze the problem, much less
provide a fix. Still, a little would be learned if this is
the type of error.

My co whereabouts is West Coast USA, however. To me,
shipping the device around the world and back for just the
above seems odd. And it might have problems with timing vs.
where I might be some of the time. I'd not want my
whereabouts constrained if I finally get to do some
sustained visiting. (I seem to be talking myself out of the
option.)

> Am Sat, Apr 17, 2021 at 05:07:28AM -0700 schrieb Mark Millard:
>> 
>> 
>> On 2021-Apr-17, at 02:29, Robert Clausecker <fuz at fuz.su> wrote:
>> 
>>> Hi Vincent,
>>> 
>>> The hard drive is an M.2 SSD in an external USB 3 enclosure.  The RPi is
>>> powered using the vendor recommended USB power brick.  It could indeed
>>> be a power issue.  I'll try to figure out if there is a way to supply
>>> power to the disk externally.
>> 
>> I use 5.1V 3.5A power supplies instead for the RPi4B's that I
>> have access to. (I use a CanaKit model of such.)
>> 
>> The offical RPi power supplies are 5.1V 3.0A.
>> 
>> I also have heat sinks and each has a fan as well. (The
>> case styles vary.)
>> 
>> Some USB hubs backpower/backfeed over the connections,
>> bypassing voltage protection. But I use a hub if I'm
>> going to have more than one USB3 SSD attached. The
>> keyboard (and sometimes also: mouse) that I use does
>> not draw much power. Adding the keyboard (and mouse)
>> does not push me to using a hub --but other models
>> of such easily could as I understand.
>> 
>>> Yours,
>>> Robert Clausecker
>>> 
>>> Am Fri, Apr 16, 2021 at 06:58:12PM -0700 schrieb Vincent Milum Jr:
>>>> What's the power source for the hard drive? From your bug tracker link, it
>>>> looks like this is a SSD of some kind, not a USB thumb drive. It is
>>>> possible that the drive is pulling too much power for the Pi's USB port to
>>>> handle. Remember that the Pi's power source is ALSO a USB port, so that
>>>> power is then shared between both the Pi as well as any devices plugged
>>>> into it. Power brownouts from pulling too much power on the Pi can present
>>>> themselves in a number of ways, including CAM errors for disks.
>>>> 
>>>> On Fri, Apr 16, 2021 at 4:00 PM Robert Clausecker <fuz at fuz.su> wrote:
>>>> 
>>>>> Greetings!
>>>>> 
>>>>> Last time I experimented with ZFS on the RPi 4B, I noticed that
>>>>> there is a strange problem when attaching the zpool via USB 3 as
>>>>> opposed to USB 2.  When doing that, mounting root fails with
>>>>> IO errors like these:
>>>>> 
>>>>> (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 03 c1 b9 65 00 00 07 00
>>>>> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
>>>>> (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
>>>>> (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 03 c1 b9 65 00 00 07 00
>>>>> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
>>>>> (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain
>>>>> 
>>>>> Attaching the boot disk through USB 2 instead works.  Likewise,
>>>>> using USB 3 with a UFS root file system works (and in fact ran fine
>>>>> in a development system for months).  I do not understand this.
>>>>> 
>>>>> I had previously reported this issue as PR 249520:
>>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249520
>>>>> 
>>>>> There's some stuff about UEFI booting in there which you can ignore.
>>>>> The same problem also appears when booting via U-Boot.
>>>>> 
>>>>> Now what surprises me is that this issue still occurs with
>>>>> FreeBSD 13.0-RELEASE.  So whatever fixes had been performed
>>>>> did not seem to address the underlying problem at all.
>>>>> 
>>>>> Is there any workaround or solution (except for ditching root
>>>>> on ZFS which would be rather painful for my use case?)
>>>>> 
>>>> 
> 

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)