Date: Tue, 19 May 2020 17:42:37 -0700 From: Mark Millard <marklmi@yahoo.com> To: mack@macktronics.com, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: rpi4 headless experience Message-ID: <DBC7D277-D2B9-4B30-A1BE-7362F7AC54EB@yahoo.com> References: <DBC7D277-D2B9-4B30-A1BE-7362F7AC54EB.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Mack mack at macktronics.com wrote on Tue May 19 22:12:47 UTC 2020 : > Thanks for you report info, especially the fact that you are having it see > all your memory. Perhaps this is an issue with different revisions of the > rpi4 ? I have a pre-Nov 2019 rpi4-4GB. The 2 RPi4B's that I have access to are 4 GiByte models and predate Nov-2019 for when they arrived. Presuming an installation based on sysutils/u-boot-rpi4 head -r528547 or later for reliable booting, the detection has always indicated the 4 GiByte size. (The unreliable booting also did as I remember: the problems were in other aspects. But I avoid depending on unreliable contexts for judgments.) u-boot-rpi4 -r528547 is from 2020-Mar-16. If I had to guess, you really tested a 1 GiByte RPi4. I do not remember anyone previously reporting such an incorrect memory size. (Not that there appear to be many having used FreeBSD on a RPI4B at this point.) One of the RPi4B is currently running head -r360311 : hw.physmem: 4127358976 hw.usermem: 4053913600 hw.realmem: 4148047872 RPi4B development is in the early stages, with not much time spent on it as far as I can tell. It may be that uefi/ACPI support may be how more ends up working at some point. (Unclear path for progress: other things are taking the time of those with the skill set for the development but there is an independent uefi/ACPI effort going on that may someday help.) Things like USB not working and the processor clock rate being well below normal for an RPi4B are expected at this stage. > And I can confirm that reboot doesn't work, on my system, it does this: Known at this stage. Same here. > root at generic > :~ # reboot > May 14 12:28:56 generic reboot[1642]: rebooted by root > May 14 12:28:56 generic syslogd: exiting on signal 15 > Waiting (max 60 seconds) for system process `vnlru' to stop... done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining... 2 0 0 done > Waiting (max 60 seconds) for system thread `bufdaemon' to stop... done > Waiting (max 60 seconds) for system thread `bufspacedaemon-0' to stop... > done > All buffers synced. > lock order reversal: > 1st 0xfffffd00012809f0 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1631 > 2nd 0xfffffd00012f5438 devfs (devfs) @ > /usr/src/sys/fs/msdosfs/msdosfs_vfsops.c:945 > stack backtrace: > #0 0xffff00000047f440 at witness_debugger+0x64 > #1 0xffff0000003e7794 at lockmgr_lock_flags+0x1d8 > #2 0xffff0000004fa3c0 at _vn_lock+0x54 > #3 0xffff0000002e5508 at msdosfs_sync+0x1a8 > #4 0xffff0000002e512c at msdosfs_unmount+0x30 > #5 0xffff0000004de514 at dounmount+0x430 > #6 0xffff0000004e9034 at vfs_unmountall+0x8c > #7 0xffff0000004c4844 at bufshutdown+0x280 > #8 0xffff000000415ea4 at kern_reboot+0x238 > #9 0xffff000000415c00 at sys_reboot+0x338 > #10 0xffff000000775a00 at do_el0_sync+0x3f8 > #11 0xffff000000759224 at handle_el0_sync+0x90 > Uptime: 1h49m6s The lock order reversal is normal and not limited to arm families: all platforms used with typical debug kernels report such. Non-debug kernels do not report the reversal because the checks are turned off. === 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?DBC7D277-D2B9-4B30-A1BE-7362F7AC54EB>