Bug 227352

Summary:	12-CURRENT (armv6) hangs on shutdown, often leaves file system not sync'd
Product:	Base System	Reporter:	Bob Frazier <bobf>
Component:	arm	Assignee:	freebsd-arm (Nobody) <freebsd-arm>
Status:	Closed DUPLICATE
Severity:	Affects Many People	CC:	cyclaero, decui, ian
Priority:	---
Version:	CURRENT
Hardware:	arm
OS:	Any

Description Bob Frazier 2018-04-07 20:12:46 UTC

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

Comment 1 cyclaero 2018-04-08 14:19:10 UTC

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.

Comment 2 cyclaero 2018-04-09 18:36:37 UTC

(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.

Comment 3 Ian Lepore freebsd_committer

2018-04-22 16:31:58 UTC


*** This bug has been marked as a duplicate of bug 227404 ***

Comment 4 Bob Frazier 2018-04-24 17:03:06 UTC

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.

Comment 5 Ian Lepore freebsd_committer

2018-04-24 17:04:55 UTC

(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).