kern/52045: panic: ffs_sync: rofs mod, fs=/ after fsck

[ozaki-r%netbsd.org@localhost]

>Number:         52045
>Category:       kern
>Synopsis:       panic: ffs_sync: rofs mod, fs=/ after fsck
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 07 08:05:00 +0000 2017
>Originator:     Ryota Ozaki
>Release:        -current
>Organization:
>Environment:
NetBSD kvm 7.99.64 NetBSD 7.99.64 (KVM) #808: Fri Mar  3 14:10:00 JST 2017  ozaki-r@rangeley:(hidden) amd64
NetBSD kvm 7.99.65 NetBSD 7.99.65 (KVM) #824: Tue Mar  7 11:09:30 JST 2017  ozaki-r@rangeley:(hidden) amd64
>Description:
A kernel of -current failed to boot up with the panic:

  panic: ffs_sync: rofs mod, fs=/
  fatal breakpoint trap in supervisor mode
  trap type 1 code 0 rip ffffffff80215455 cs 8 rflags 246 cr2 7f7ff6cf38cc ilevel 0 rsp fffffe80036dbd80
  curlwp 0xfffffe803fa1b2e0 pid 0.76 lowest kstack 0xfffffe80036d82c0
  Stopped in pid 0.76 (system) at netbsd:breakpoint+0x5:  leave
  db{1}> bt    
  breakpoint() at netbsd:breakpoint+0x5
  vpanic() at netbsd:vpanic+0x140
  panic() at netbsd:panic+0x3c
  ffs_sync() at netbsd:ffs_sync+0x26b
  VFS_SYNC() at netbsd:VFS_SYNC+0x1c
  sched_sync() at netbsd:sched_sync+0x27b
  db{1}>

The panic happens after fsck ("Starting root file system check:") runs
and does something. If fsck does nothing, the panic doesn't happen.

The panic doesn't happen with a kernel of -current at 2/28-ish and
happen with one at 3/3-ish. IOW 7.99.63 is ok, but 7.99.64 isn't.

You can find other examples of the panic at http://mail-index.netbsd.org/current-users/2017/03/05/msg031260.html .

>How-To-Repeat:
- Make the filesystem unclean
  - By reseting the machine, entering the DDB and rebooting from it, or whatever
- Boot up the machine
- See what happens

You may need several trials to cause the panic.
>Fix:
n/a