Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 17 Apr 2021 14:36:46 +0200
From:      Robert Clausecker <fuz@fuz.su>
To:        freebsd-arm@freebsd.org
Subject:   Re: RPi 4B USB 3 support appears to still be broken in 13.0-RELEASE
Message-ID:  <YHrWXkVhiPJFihdv@fuz.su>
In-Reply-To: <6D2C75DF-796D-4CC9-9740-A8C15C6A6154@yahoo.com>
References:  <YHoXAS%2B0/ptwL0IS@fuz.su> <CAOWUMWGvYBZmMo1OVfsHQ6OohBOpQy5_n%2B0T5BeKWvqowBQQiA@mail.gmail.com> <YHqqgmFRxNS7azeK@fuz.su> <6D2C75DF-796D-4CC9-9740-A8C15C6A6154@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi Mark,

Thanks for your response.

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.

Yours,
Robert Clausecker

Am Sat, Apr 17, 2021 at 05:07:28AM -0700 schrieb Mark Millard:
> 
> 
> On 2021-Apr-17, at 02:29, Robert Clausecker <fuz@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@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)
> 

-- 
()  ascii ribbon campaign - for an 8-bit clean world 
/\  - against html email  - against proprietary attachments



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YHrWXkVhiPJFihdv>