using FreeBSD-12.0-CURRENT-arm-armv6-RPI-B-20180329-r331740.img with serial console enabled observed shutdown in serial console, and it hung at this point: Syncing disks, vnodes remaining... 0 timed out after powering off [obviously hung] and fsck'ing the SD card, the following problem was noted: CANNOT READ BLK: 7693632 In a previous shutdown attempt, it did something similar, and I corrected the problems with fsck by booting to single-user mode, mostly unreferenced file pointers. With the image in the state described above, I booted into single user, did 'fsck -y /' and had to repeat it because of a lot of unreferenced file pointers. I did 'sync' followed by another 'poweroff' [from the serial console] and observed the following: "Syncing disks, vnodes remaining... 0 4 timed out" booted single user again, did 'fsck -y /' twice (as required, since the first time didn't correct all of the problems), then did 'sync' followed by 'poweroff' and got the following: "Syncing disks, vnodes remaining... 0 0 0 0 0 0 0 0 done" and then the system hung. booted single user again, ran fsck - no problems with the file system. uname output: FreeBSD pi1c 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r331740: Thu Mar 29 23:19:27 UTC 2018 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm.armv6/sys/RPI-B arm dmesg output (first part) KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #0 r331740: Thu Mar 29 23:19:27 UTC 2018 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm.armv6/sys/RPI-B arm FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0) WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. CPU: ARM ARM1176 r0p7 (ECO: 0x00000000) CPU Features: Thumb, Security, VMSAv7 Optional instructions: UMULL, SMULL, MLA, SIMD(ext) 16KB/32B 4-way instruction cache 16KB/32B 4-way WB data cache real memory = 469757952 (447 MB) avail memory = 444567552 (423 MB) I'll add more to this as I find it or on request
I have the same issue with the March, 29 12.0-CURRENT ARMv7 snapshot (r331740) on a BeagleBone Black. When calling sync right before shutting down, at least the file system is not left in an undefined state, although, I need to unplug the device in order to get it down.
(In reply to cyclaero from comment #1) I update the BeeagleBone Black the latest snapshot 12.0-CURRENT r332309 and theis one shows the same issue. For the time being I copied only the /boot/kernel from an old snapshot r330606 and with this one the system does not hang when shutting down.
*** This bug has been marked as a duplicate of bug 227404 ***
re-tested with latest -CURRENT FreeBSD pi1c 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r332894: Tue Apr 24 07:43:22 PDT 2018 bobf@hack.SFT.local:/e-drive/obj.current/e-drive/src.current/arm.armv6/sys/RPI-B arm did not observe the hang. however, I _did_ see this in the console: Apr 24 16:55:56 pi1c 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... 1 1 1 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 0xd2c34974 ufs (ufs) @ /e-drive/src.current/sys/kern/vfs_mount.c:1335 2nd 0xd2c2fbc4 syncer (syncer) @ /e-drive/src.current/sys/kern/vfs_subr.c:2732 stack backtrace: lock order reversal: 1st 0xd2c34724 ufs (ufs) @ /e-drive/src.current/sys/kern/vfs_mount.c:1335 2nd 0xd2c34034 devfs (devfs) @ /e-drive/src.current/sys/fs/msdosfs/msdosfs_vfsops.c:934 stack backtrace: Uptime: 1m49s The operating system has halted. Please press any key to reboot.
(In reply to Bob Frazier from comment #4) Those LORs at shutdown are well-known and harmless (as is a similar vfs_mount LOR at startup).