Date: Fri, 25 Sep 2020 16:25:50 -0700 From: Mark Millard <marklmi@yahoo.com> To: Robert Clausecker <fuz@fuz.su> Cc: Robert Crowston <crowston@protonmail.com>, freebsd-arm@freebsd.org Subject: Re: RPI 4B on UEFI: xhci0 disconnects under high load Message-ID: <52E067BA-1B5A-4360-B961-95A4F0B32265@yahoo.com> In-Reply-To: <20200925223334.GB3984@fuz.su> References: <20200924224749.GA18463@fuz.su> <66418AE0-79C9-4402-8325-7094E4230D38@yahoo.com> <20200925075822.GB51892@fuz.su> <9EBAAD5C-120D-4F7B-9C5F-1BB045CC1E17@yahoo.com> <Y-XjGjcz6f1wZ_boqk8rDM1oywdBjC1frQn_s0NR9BSa9VQAKH8sJjFGRn1-PTIecV-oHsfOjeYQvC9CVCiHy6uNg7YTZqTvaF3YG06LW2M=@protonmail.com> <FA5E1DB8-AE43-4934-B0AD-4D8200E132B3@yahoo.com> <20200925223334.GB3984@fuz.su>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Sep-25, at 15:33, Robert Clausecker <fuz at fuz.su> wrote: > Hi Mark, Hello. > On Fri, Sep 25, 2020 at 10:08:41AM -0700, Mark Millard wrote: >>=20 >>=20 >> On 2020-Sep-25, at 03:39, Robert Crowston <crowston at = protonmail.com> wrote: >>=20 >>> Could the failure of the ACPI patch to work be related to the >> pre-September 2020 dtbs reporting 4 GB available for pci DMA >> (as you reported today in another thread)? >>>=20 >>=20 >> I'm unclear if you are specifically referring to: >>=20 >> A) this thread's "disconnects under high load" failures? >> B) the huge file duplication and diff/cmp test failures? >> C) both? >> D) even more? >>=20 >> For (A) I'd not conclude much until results are in for >> FreeBSD that is head -r365918 or later. It might be a >> fixed problem. >=20 > I've rebuild a kernel based on github revision e77e27fa: >=20 > pwm(8): fix potential duty overflow, use unsigneds for period and = duty >=20 > Not sure what the revision number of that one is. That is svn: head -r366144 from less than 24 hours ago. > The only > patch I applied is D25219 as the others don't cleanly apply. > The xhci disconnection error did not occur again. Good, I was hoping that the xHCI fix would cover your context. So far things are suggesting such. > I'll check > if this also fixes the problem that I wasn't able to boot from > a disk attached to a USB 3.0 boot, but right now I don't have > physical access to the machine, so it'll have to wait. >=20 > Note that this was without the RAM size limiter on. Maybe I > didn't generate enough load for this to be an issue. I've had a large chunk of a poudriere bulk build appear to work before corrupted files from earlier stages were detected as problems in later stages of the overall build. In the huge-file duplication and diff/cmp tests, huge subranges of the duplicate normally match the original. It is unreliable but not not always trivially identifiable for having problems or where. There is no available test to certify that things are all okay after using the RPi4B with > 3072 MiByte. Unless you are trying to gather evidence about that problem and are happy with corrupting things, I'd strongly suggest sticking to 3072 MiByte for rpi4-uefi-devel explorations. In part that cross checks my result of never having hit evidence of such a problem from uisng the 3072 MiByte selection. So it is useful testing. >> For (B), I've been reporting examples of the issue since >> 2020-Jun-21 using rpi4-uefi-devel v1.16 and head -r360311 . >> But my most recent reports are based on the modern dtb that >> has 3 GiByte for the size of the range (uefi v1.20 and its >> bundled RPI4B materials or newer raspberry pi materials) >> and head -r365932. So both old and new got the same type >> of failures. (I've not tested materials from prior to >> 2020-Jun-21 with > 3072 MiByte in this way: that is when >> I discovered the test.) >>=20 >> Does that answer your question? >=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?52E067BA-1B5A-4360-B961-95A4F0B32265>