From owner-freebsd-arm@freebsd.org Fri Sep 25 07:58:24 2020 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 EDBD63EE79F for ; Fri, 25 Sep 2020 07:58:24 +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 4ByPRh16vMz4nR5 for ; Fri, 25 Sep 2020 07:58:23 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (localhost [127.0.0.1]) by fuz.su (8.15.2/8.15.2) with ESMTPS id 08P7wMVm052511 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 25 Sep 2020 09:58:22 +0200 (CEST) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.15.2/8.15.2/Submit) id 08P7wMmt052510; Fri, 25 Sep 2020 09:58:22 +0200 (CEST) (envelope-from fuz) Date: Fri, 25 Sep 2020 09:58:22 +0200 From: Robert Clausecker To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: RPI 4B on UEFI: xhci0 disconnects under high load Message-ID: <20200925075822.GB51892@fuz.su> References: <20200924224749.GA18463@fuz.su> <66418AE0-79C9-4402-8325-7094E4230D38@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66418AE0-79C9-4402-8325-7094E4230D38@yahoo.com> X-Rspamd-Queue-Id: 4ByPRh16vMz4nR5 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 [-2.25 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:c]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[fuz.su]; NEURAL_HAM_LONG(-0.99)[-0.990]; NEURAL_SPAM_SHORT(0.03)[0.033]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[yahoo.com]; 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.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 07:58:25 -0000 Hi Mark, Thanks for your quick response! It appears that I had missed that this changeset was required. Let me update to the most recent revision and try again. Yes, I have been using the github mirror. Are there any other patches I should consider applying? Yours, Robert Clausecker On Thu, Sep 24, 2020 at 06:19:36PM -0700, Mark Millard wrote: > > > On 2020-Sep-24, at 15:47, Robert Clausecker wrote: > > > Good evening! > > > > I have set up a FreeBSD system on a Raspberry Pi 4B as described > > in bug #249520 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249520). > > After setting up the USB drive on a USB 2.0 port, the system boots. > > However, when the system is under high I/O load (I tested this by > > compiling a Go toolchain), the USB controller eventually hangs and > > causes the system to effectively crash: > > > > --- > > xhci_interrupt: host system error > > xhci0: Resetting controller > > Looks like prior history to the above would be > appropriate. (The later messages likely are > consequences of the above.) > > Also: ed6978a9a70 in github is from: > > QUOTE > Author: ian > Date: Mon Sep 14 17:33:28 2020 > New Revision: 365729 > URL: > https://svnweb.freebsd.org/changeset/base/365729 > > Log: > Add product ID strings for a couple Microchip usb hubs. Also, update the > vendor ID string to say just "Microchip Technology" -- the buyout of > Standard Microsystems happened in 2012 and the SMC/SMSC names are pretty > much retired at this point. > END QUOTE > > > but there is a more recent check-in required to > avoid at least one way of getting "Resetting controller" > for -mcpu=cortex-a72 : > > QUOTE > Author: hselasky > Date: Sat Sep 19 22:37:45 2020 > New Revision: 365918 > URL: > https://svnweb.freebsd.org/changeset/base/365918 > > Log: > Fix for use of the XHCI driver on Cortex-A72 by adding a missing cache > flush operation before writing to the XHCI_ERSTBA_LO/HI register(s). > END QUOTE > > [I do suggest that you report which git repository that you > are referencing since there are multiple ones right now that > have differing hashes. I guessed github from "(master)", > figuring that the cgit-beta.freebsd.org one would have > "(main)".] > > > uhub1: at usbus0, port 1, addr 1 (disconnected) > > ugen0.2: at usbus0 (disconnected) > > uhub2: at uhub1, port 1, addr 1 (disconnected) > > ugen0.3: at usbus0 (disconnected) > > axe0: at uhub2, port 2, addr 2 (disconnected) > > ukphy0: detached > > miibus0: detached > > axe0: detached > > ugen0.4: at usbus0 (disconnected) > > umass0: at uhub2, port 4, addr 3 (disconnected) > > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 85 d9 0d 00 00 80 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 at umass-sim0 bus 0 scbus0 target 0 lun 0 > > da0: s/n ABCDEFA74566 detached > > Solaris: WARNING: Pool 'tau' has encountered an uncorrectable I/O failure and has been suspended. > > > > Solaris: WARNING: Pool 'tau' has encountered an uncorrectable I/O failure and has been suspended. > > --- > > The above messages I think are just consequences of earlier > problems. > > > This is despite having applied D25219 and the D26493--D26496 series > > of patches which were supposed to address this sort of issue. The same > > issue does not seem to appear with an older kernel to which the > > D26493--D26496 series of patches was not applied and which was not > > compiled with -mcpu=cortex-a72. The older kernel identifies itself as > > > > FreeBSD 13.0-CURRENT #2 ed6978a9a70-c271559(master)-dirty > > > > It's the one I described in my earlier mails to this list. So it seems > > that in this case, pulling in patches meant to fix a bug seem to have > > introduced in this first place. Any idea what could have happened? > > I strongly suggest using a FreeBSD vintage that includes > the corrected XHCI driver. > > === > 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