Bug 254755
| Summary: | arm64: USB keyboard is detected to late, so a single user mode isn't possible | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Gordon Bergling <gbe> | ||||
| Component: | arm | Assignee: | freebsd-arm (Nobody) <freebsd-arm> | ||||
| Status: | Closed Overcome By Events | ||||||
| Severity: | Affects Many People | CC: | marklmi26-fbsd | ||||
| Priority: | --- | ||||||
| Version: | CURRENT | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
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 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.) 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. (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 (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. (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. |
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.