Date: Thu, 18 Mar 2021 23:04:45 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net>, tech-lists <tech-lists@zyxst.net> Cc: freebsd-arm@freebsd.org Subject: Re: RPi4 Status and xorg behavior (FreeBSD debug kernel no longer panics for USB storage devices) Message-ID: <2837D952-A6DF-4CDE-82BC-B72B2BB56C99@yahoo.com> In-Reply-To: <453A972C-D4C7-4789-BAD0-78A167019E7B@yahoo.com> References: <AAA4E495-4E9E-4C55-A07E-74D9737EC15B@yahoo.com> <20210307155515.GA4591@www.zefox.net> <67BF2EAC-04AD-4822-99B2-48A99563331F@yahoo.com> <G5ZAfvg49jl5dj40HAnjmwoEKpVSuGp8KmiBrSY_EBLXou6UGBIjU3tVxUuPGKeCvXEovg2d3tqhIGOmQCyb7c3wKsUHJ8xrSasvwXfbqwk=@protonmail.com> <4B963C56-D7E9-42FE-8B8B-B8A425ACE78F@yahoo.com> <20210308011035.GA6603@www.zefox.net> <DB3CD5BA-337E-476F-9F0C-C70401F7D800@yahoo.com> <C500EE5B-B483-4580-8C7C-9B9B013D726B@googlemail.com> <20210308173045.GB13739@www.zefox.net> <4D8FD8EE-6642-46ED-8AAE-CAECB36572F6@yahoo.com> <20210309023348.GA16279@www.zefox.net> <EC4C3040-E86A-45EC-9E4F-0E0F81ED3CBD@yahoo.com> <77D90D34-4403-44F0-A7D7-EEBCDCF745D3@yahoo.com> <453A972C-D4C7-4789-BAD0-78A167019E7B@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Mar-11, at 23:57, Mark Millard <marklmi at yahoo.com> wrote: > There is a known FreeBSD error exposed by recent debug > kernels that panic with backtraces like the following > when USB storage is present or plugged in, not just > on aarch64 or armv7/6 but in general: >=20 > panic: malloc(M_WAITOK) with sleeping prohibited > cpuid =3D 0 > time =3D 1615452946 > KDB: stack backtrace: > db_trace_self() at db_trace_self > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > vpanic() at vpanic+0x184 > panic() at panic+0x44 > malloc_dbg() at malloc_dbg+0xf8 > malloc() at malloc+0x30 > disk_alloc() at disk_alloc+0x1c > daregister() at daregister+0x3b8 > cam_periph_alloc() at cam_periph_alloc+0x528 > daasync() at daasync+0x260 > xpt_async_process_dev() at xpt_async_process_dev+0x194 > xpt_async_process() at xpt_async_process+0x3a0 > xpt_done_process() at xpt_done_process+0x314 > xpt_done_td() at xpt_done_td+0xd8 > fork_exit() at fork_exit+0x74 > fork_trampoline() at fork_trampoline+0x14 >=20 > It turns out that the snapshot: >=20 > = FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210311-15565e0a217-257277.img.xz >=20 > Is an example of having this problem. So are the > other "20210311" snapshots with debug kernels. >=20 > Recent https://artifact.ci.freebsd.org/snapshot/ > materials will also have the problem (debug kernels). >=20 > The http://ftp3.freebsd.org/pub/FreeBSD/releases/ > material do not have debug kernels and so will not > panic and should work as long as various memory > allocations do not fail. >=20 > https://reviews.freebsd.org/D29210/ is for a patch in > review for the issue. Various folks have used it to > get debug kernels going for their activities. >=20 The new: = https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0-CU= RRENT-arm64-aarch64-RPI-20210318-a771bf748f9-245511.img.xz no longer has the "malloc(M_WAITOK) with sleeping prohibited" problem in the debug kernel when a USB device is present. It does not need content replacement for USB storage on USB3 to work, for example. It has the RPi* firmware vintage allowing USB to operate at that level as well: # strings /boot/msdos/start4.elf | grep VC_BUILD_ID_ VC_BUILD_ID_USER: dom VC_BUILD_ID_TIME: 12:10:40 VC_BUILD_ID_VARIANT: start VC_BUILD_ID_TIME: Feb 25 2021 VC_BUILD_ID_BRANCH: bcm2711_2 VC_BUILD_ID_HOSTNAME: buildbot VC_BUILD_ID_PLATFORM: raspberrypi_linux VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) It also has: root@generic:~ # strings /boot/msdos/u-boot.bin | grep 'U-Boot 2' U-Boot 2020.10 (Mar 18 2021 - 04:36:05 +0000) which should just work. (I'm ignoring U-Boot's not handling a device with multiple storage LUNs. I'm also ignoring a technical-bug that has never been observed to actually lead to failure.) On possible oddity is that the /boot/msdos/ usage was possibly supposed to have been changed to /boot/efi/ usage instead (but was not). I'm unsure for this what the intent was but I've sent out a separate note about it. FYI: root@generic:~ # uname -apKU FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0 = main-n245511-a771bf748f9: Thu Mar 18 08:07:18 UTC 2021 = root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC = arm64 aarch64 1400006 1400006 =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?2837D952-A6DF-4CDE-82BC-B72B2BB56C99>