Bug 254755 - arm64: USB keyboard is detected to late, so a single user mode isn't possible
Summary: arm64: USB keyboard is detected to late, so a single user mode isn't possible
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-arm (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-04 06:57 UTC by Gordon Bergling
Modified: 2021-04-05 10:57 UTC (History)
1 user (show)

See Also:


Attachments
dmesg output (15.21 KB, text/plain)
2021-04-04 06:57 UTC, Gordon Bergling
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gordon Bergling freebsd_committer 2021-04-04 06:57:37 UTC
Created attachment 223797 [details]
dmesg output

I currently having the problem that my RPi4B reports that the filesystem wasn't properly mounted. Background fsck didn't work.

Apr  1 11:12:49 tiny fsck[77593]: /dev/ufs/rootfs: NO WRITE ACCESS
Apr  1 11:12:49 tiny fsck[77593]: /dev/ufs/rootfs: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
Apr  1 11:12:49 tiny fsck[77593]: /dev/ufs/rootfs: CANNOT SET FS_NEEDSFSCK FLAG

The manual run of fsck only works in single user mode, which can't be entered since the USB keyboard only works very late at the boot process.

A dmesg output is attached.
Comment 1 Mark Millard 2021-04-04 09:20:48 UTC
You should be able to:

# shutdown now

to get to single user mode after the boot and login --without
a reboot breing involved.

But the drive to fsck or fsck_ffs will still be writable,
unlike for boot -s. So (presuming the drive can be referred
to as /):

# mount -r /

then finally the fsck or fsck_ffs command(s).

After things are clean you can et back to a writable
status and then back to a login prompt via:

# mount -w /
# exit
Comment 2 Mark Millard 2021-04-04 09:25:52 UTC
Other notes . . .

I expect that the messages similar to:

uma_zalloc_debug: zone "malloc-2048" with the following non-sleepable locks held:
exclusive sleep mutex SD slot mtx (sdhci) r = 0 (0xffffa00000ed3438) locked @ /tank/nfs_public/tiny/src/sys/dev/sdhci/sdhci.c:617
. . .

and the sleep after non-sleepable messsage(s) like:

lock order reversal: (sleepable after non-sleepable)
 1st 0xffff000000c20c30 LED mtx (LED mtx, sleep mutex) @ /tank/nfs_public/tiny/src/sys/dev/led/led.c:298
 2nd 0xffffa00000ed3c10 Raspberry Pi firmware gpio (Raspberry Pi firmware gpio, sx) @ /tank/nfs_public/tiny/src/sys/arm/broadcom/bcm2835/raspberrypi_gpio.c:252
lock order LED mtx -> . . .
. . .

also indicate other problems. Your dmesg may be good
for multiple reports of distinct problems.

The reference to mmccam_start_discovery makes me wonder if
teh build is a somewhat non-standard build that needs some
notes about the distinctions. (But I could well be wrong.)
Comment 3 Mark Millard 2021-04-04 22:05:52 UTC
I've tried:

FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210401-4084b1ab041-245766.img

on a microsd card and I had no trouble using the USB
keyboard (an official RPi USB keyboard) to:

. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel] in 10 seconds... 

Type '?' for a list of commands, 'help' for more detailed help.
OK boot -s
. . .
root@:/ # uname -apKU
FreeBSD  14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n245766-4084b1ab041: Thu Apr  1 10:06:57 UTC 2021     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC  arm64 aarch64 1400006 1400006

So it would appear something more specific to your context
is involved in why your USB keyboard is not available for
such use.
Comment 4 Mark Millard 2021-04-04 22:40:33 UTC
(In reply to Mark Millard from comment #3 and #2)

I'll also note that the uma_zalloc_debug notices and
sleepable after non-sleepable notices did not happen
for the boot based on a microsd card produced from:

FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210401-4084b1ab041-245766.img

This also suggests that your build is somehow
unusual. The only commits are:

* 	sh: silence sanitizer	Piotr Pawel Stefaniak	4 days	1	-1/+4
* 	luaboot: visible must be a function	Warner Losh	4 days	2	-1/+6
* 	loader: create a generic vendor sub-menu place holder	Warner Losh	4 days	2	-10/+78
* 	Fix `netstat -rs` reporting.

The last is 4084b1ab041 used for the snapshot build.
The first is 5a18515b3143 from your dmesg output. Nothing
looks likely to explain the differing notices or the
reported differing USB keyboard behavior.

This suggests sys/GENERIC-TCP (from your dmesg output)
may be contributing to the issues. The official snapshot
is based on sys/GENERIC according to its boot messsages:

FreeBSD 14.0-CURRENT #0 main-n245766-4084b1ab041: Thu Apr  1 10:06:57 UTC 2021
    root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
Comment 5 Gordon Bergling freebsd_committer 2021-04-05 07:20:51 UTC
(In reply to Mark Millard from comment #1)

Thanks for your input. I had tried getting into single user mode via 'shutdown now', but after getting the usual "The system is going down" the system just stalls and no input is possible.

I am running an MMCCAM kernel and had reported sdhci non-sleepable locks held errors in separate PR. I have started a fresh build of a GENERIC kernel and hope that this my improve the situation.

The keyboard itself is a cheap no-name one.

Let's see if a boot from a GENERIC kernel is improving the situation.
Comment 6 Gordon Bergling freebsd_committer 2021-04-05 10:57:07 UTC
(In reply to Mark Millard from comment #1)

I'll tried a GENERIC kernel, but also without much success. The single user mode via 'shutdown now' results in a deadlock or something else, since no prompt is visible and I can't type anything. I'll have a spare micro-sd-card laying around and try a fresh snapshot of 14-CURRENT.