rpi4b main-n245392-8423f5d4c12 won't boot due to microsd timeout

Fri Mar 12 07:05:08 UTC 2021

On 2021-Mar-11, at 22:19, Mark Millard <marklmi at yahoo.com> wrote:

> On 2021-Mar-11, at 21:56, Mark Millard <marklmi at yahoo.com> wrote:
> 
>> On 2021-Mar-11, at 21:49, Mark Millard <marklmi at yahoo.com> wrote:
>> 
>> 
>>> On 2021-Mar-11, at 17:59, tech-lists <tech-lists at zyxst.net> wrote:
>>> 
>>>> main-n245392-8423f5d4c12 built and installed fine. On reboot it seems
>>>> the microsd card times out. Console log is here:
>>>> https://cloud.zyxst.net/~john/FreeBSD/main-n245392-8423f5d4c12-no-debug-failboot.txt
>>>> 
>>>> Booting kernel.old works fine. This one is from
>>>> main-n244802-88db1cc9f19 (Feb 14th)
>>>> 
>>>> Nothing else has been changed configuration-wise, same msdos partition,
>>>> same config.txt. Only thing that has changed is /usr/src has been
>>>> updated, built and installed as of main-n245392-8423f5d4c12 (March
>>>> 11th).
>>>> 
>>>> Should I raise this in bugzilla?
>>> 
>>> Note: I use the official snapshot
>>> 
>>> FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210311-15565e0a217-257277.img.xz
>>> 
>>> and its:
>>> 
>>> # strings /mnt/boot/kernel/kernel | grep 15565e0a217
>>> @(#)FreeBSD 14.0-CURRENT #0 main-n245383-15565e0a217: Thu Mar 11 08:02:52 UTC 2021
>>> FreeBSD 14.0-CURRENT #0 main-n245383-15565e0a217: Thu Mar 11 08:02:52 UTC 2021
>>> 
>>> For some comparisons to what you report about your
>>> build.
>>> 
>>> 
>>> 
>>> Some oddities in your report that might need to be
>>> addressed first to make things more comparable
>>> are . . .
>>> 
>>> Your log file shows:
>>> 
>>> U-Boot 2020.07-rc3-00208-g88bd5b1793-dirty (Jun 06 2020 - 20:33:00 +0100)
>>> 
>>> But FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210311-15565e0a217-257277.img.xz
>>> has:
>>> 
>>> # strings /mnt/u-boot.bin | grep 2020
>>> 2020.10
>>> U-Boot 2020.10 (Mar 11 2021 - 04:30:22 +0000)
>>> 
>>> This makes comparison of results messier. You might
>>> want to copy the snapshot file over to your
>>> media.
>>> 
>>> 
>>> For reference the snapshot for 15565e0a217
>>> also has:
>>> 
>>> # strings /mnt/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)
>>> 
>>> The Feb 25 2021 start4.elf build is from the officially
>>> tagged 1.20210303 rpi* material from:
>>> 
>>> https://github.com/raspberrypi/firmware/tree/1.20210303/boot/
>>> ( which is what a modern sysutils/rpi-firmware has in
>>> part of /usr/local/share/rpi-firmware/ )
>>> 
>>> Note: many files other than start*.elf are involved but
>>> many do not have such nice, checkable version strings
>>> to look at.
>>> 
>>> What vintage/variant was your experiment was based on?
>>> 
>>> You might want to copy the snapshot's material over to
>>> your media if your media does not match.
>>> 
>>> 
>>> Your log file shows:
>>> 
>>>  FreeBSD/arm64 EFI loader, Revision 1.1
>>>  (Thu Sep 17 07:58:43 UTC 2020 root at releng1.nyi.freebsd.org)
>>> 
>>> But FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210311-15565e0a217-257277.img.xz
>>> has:
>>> 
>>> # strings /mnt/EFI/BOOT/bootaa64.efi | egrep '(FreeBSD/|root@)'
>>> FreeBSD/arm64 EFI loader, Revision 1.1
>>> (Thu Mar 11 07:29:18 UTC 2021 root at releng1.nyi.freebsd.org)
>>> 
>>> I do not have sizes or content to compare to see if there
>>> are actual differences. FYI:
>>> 
>>> # ls -Tld /mnt/EFI/BOOT/bootaa64.efi 
>>> -rwxr-xr-x  1 root  wheel  1258796 Mar 10 23:29:52 2021 /mnt/EFI/BOOT/bootaa64.efi
>>> 
>>> You might want to copy the snapshot's material over to
>>> your media if your media does not match.
>> 
>> The suggestion might not be the best for EFI/BOOT/bootaa64.efi :
>> 
>> Copying your build's /boot/loader.efi to EFI/BOOT/bootaa64.efi
>> would likely be better so it is testing the version from your
>> build instead.
>> 
>>> With the deliberate matching of materials, re-running the
>>> experiment and basing any report on the result with a
>>> description of the context would avoid worries about the
>>> mismatches contributing to the behaviorial issues. (I've
>>> no clue if they actually matter or not.)
>> 
>> 
> 
> FYI: There is another report about "panic: malloc(M_WAITOK)
> with sleeping prohibited" for debug kernels if any USB device
> is present during boot so the below is based on having no USB
> devices plugged in for trying to boot the snapshot.

Should have written "any USB storage device". While there might
be other kinds that also hit the bug, my testing did not have
a problems with a USB keyboard. (I did confirm the storage
device panic for the debug kernel.)

> I tried the microsd card media that I made from:
> 
> FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210311-15565e0a217-257277.img.xz
> 
> and the RPi4B 8 GiByte booted just fine, even doing
> the:
> 
> GEOM_PART: mmcsd0s2 was automatically resized.
>  Use `gpart commit mmcsd0s2` to save changes or `gpart undo mmcsd0s2` to revert them.
> mmcsd0s2 resized
> mmcsd0s2a resized
> gpart: arg0 'ufs/rootfs': Invalid argument
> super-block backups (for fsck_ffs -b #) at:
> 6402432, 7682880, 8963328, 10243776, 11524224, 12804672, 14085120, 15365568,
> 16646016, 17926464, 19206912, 20487360, 21767808, 23048256, 24328704,
> 25609152, 26889600, 28170048, 29450496, 30730944, 32011392, 33291840,
> 34572288, 35852736, 37133184, 38413632, 39694080, 40974528, 42254976,
> 43535424, 44815872, 46096320, 47376768, 48657216, 49937664, 51218112,
> 52498560, 53779008, 55059456, 56339904, 57620352, 58900800, 60181248, 61461696
> 
> So if there is a more recent problem, the bisection range
> should be fairly small. No need to go back to 2021-Feb-14.
> 
> One thing that is different here: debug kernel instead
> of your non-debug kernel build.

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