Date: Sat, 17 Apr 2021 10:47:56 -0700 From: Mark Millard <marklmi@yahoo.com> To: Robert Clausecker <fuz@fuz.su> Cc: freebsd-arm@freebsd.org Subject: Re: RPi 4B USB 3 support appears to still be broken in 13.0-RELEASE Message-ID: <C7C2B00E-772E-4EBE-AA0A-1EAB04F4F6A6@yahoo.com> In-Reply-To: <YHrWXkVhiPJFihdv@fuz.su> References: <YHoXAS%2B0/ptwL0IS@fuz.su> <CAOWUMWGvYBZmMo1OVfsHQ6OohBOpQy5_n%2B0T5BeKWvqowBQQiA@mail.gmail.com> <YHqqgmFRxNS7azeK@fuz.su> <6D2C75DF-796D-4CC9-9740-A8C15C6A6154@yahoo.com> <YHrWXkVhiPJFihdv@fuz.su>
next in thread | previous in thread | raw e-mail | index | archive | help
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). >=20 > Detaching the fans doesn't make a difference. I'll try and see if I = can > find a powered USB3 hub. >=20 > 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. >=20 > 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: >>=20 >>=20 >> On 2021-Apr-17, at 02:29, Robert Clausecker <fuz@fuz.su> wrote: >>=20 >>> Hi Vincent, >>>=20 >>> 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. >>=20 >> 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.) >>=20 >> The offical RPi power supplies are 5.1V 3.0A. >>=20 >> I also have heat sinks and each has a fan as well. (The >> case styles vary.) >>=20 >> 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. >>=20 >>> Yours, >>> Robert Clausecker >>>=20 >>> Am Fri, Apr 16, 2021 at 06:58:12PM -0700 schrieb Vincent Milum Jr: >>>> What's the power source for the hard drive? =46rom 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. >>>>=20 >>>> On Fri, Apr 16, 2021 at 4:00 PM Robert Clausecker <fuz@fuz.su> = wrote: >>>>=20 >>>>> Greetings! >>>>>=20 >>>>> 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: >>>>>=20 >>>>> (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 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> I had previously reported this issue as PR 249520: >>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D249520 >>>>>=20 >>>>> There's some stuff about UEFI booting in there which you can = ignore. >>>>> The same problem also appears when booting via U-Boot. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Is there any workaround or solution (except for ditching root >>>>> on ZFS which would be rather painful for my use case?) >>>>>=20 >>>>=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C7C2B00E-772E-4EBE-AA0A-1EAB04F4F6A6>