RPi4 Status and xorg behavior (FreeBSD debug kernel no longer panics for USB storage devices)

[Mark Millard]

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:
> 
> panic: malloc(M_WAITOK) with sleeping prohibited
> cpuid = 0
> time = 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
> 
> It turns out that the snapshot:
> 
> FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210311-15565e0a217-257277.img.xz
> 
> Is an example of having this problem. So are the
> other "20210311" snapshots with debug kernels.
> 
> Recent https://artifact.ci.freebsd.org/snapshot/
> materials will also have the problem (debug kernels).
> 
> 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.
> 
> 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.
> 

The new:

https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-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 at 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 at 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 at releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC  arm64 aarch64 1400006 1400006


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)