From owner-freebsd-arm@freebsd.org Sat Apr 17 12:36:49 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 91DF15D4C8C for ; Sat, 17 Apr 2021 12:36:49 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (fuz.su [IPv6:2001:41d0:8:e508::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FMsym6K4Wz4fSn for ; Sat, 17 Apr 2021 12:36:48 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (localhost [127.0.0.1]) by fuz.su (8.16.1/8.16.1) with ESMTPS id 13HCakAC011106 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sat, 17 Apr 2021 14:36:46 +0200 (CEST) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.16.1/8.16.1/Submit) id 13HCakp0011105 for freebsd-arm@freebsd.org; Sat, 17 Apr 2021 14:36:46 +0200 (CEST) (envelope-from fuz) Date: Sat, 17 Apr 2021 14:36:46 +0200 From: Robert Clausecker To: freebsd-arm@freebsd.org Subject: Re: RPi 4B USB 3 support appears to still be broken in 13.0-RELEASE Message-ID: References: <6D2C75DF-796D-4CC9-9740-A8C15C6A6154@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6D2C75DF-796D-4CC9-9740-A8C15C6A6154@yahoo.com> X-Rspamd-Queue-Id: 4FMsym6K4Wz4fSn X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of fuz@fuz.su designates 2001:41d0:8:e508::1 as permitted sender) smtp.mailfrom=fuz@fuz.su X-Spamd-Result: default: False [0.70 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:41d0:8:e508::1:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2001:41d0:8:e508::1:from:127.0.2.255]; DMARC_NA(0.00)[fuz.su]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to ARM processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Apr 2021 12:36:49 -0000 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 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 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