Crash 12: A closer look

Here's the information we found in crash 12.

 Hiya on zen...  adb -k vmunix.12 vmcore.12  physmem 1ff8  $c  _panic(0xf8174abb,0xf817e784,0xf817e798,0x283,0xa000,0xf84ccb98) + 6c  _assfail(0xf817e784,0xf817e798,0x283,0xfd0cd5a8,0x1,0xf8385088) + 3c  _pvn_vplist_dirty(0xfd0cd5a8,0x0,0x0,0xf8385088,0xf8386b40,0xfd0cd5a8) + 250  _ufs_putpage(0xfd0cd5a8,0xfd0cd5a0,0x0,0x0,0x0,0xf82f607c) + 33c  _ufs_l_putpage(0xfd0cd5a8,0x0,0x0,0x0,0x0,0x0) + 30  _syncip(  0xfd0cd5a0  ,0x0,0x0,0x4e,0x1101,0x0) + 124  _update(0xf81a7900,0x104e,0xfd0cd5a0,0xfcfaf218,0x0,0xfd0cd5a0) + 2f0  _ufs_sync(0x0,0xf8175ac8,0xf817d820,0xf81a5c48,0xf8175ac8,0xfcea1d44) + 4  _sync(0xf84ccfe0,0x120,0xf8173468,0xf8173588,0xf84cd000,0xf8175a88) + 3c  _syscall(0xf84cd000) + 3b4  0xfd0cd5a0$<inode  0xfd0cd5a0:     forw            back                  fce4bcc8        f81a7900  0xfd0cd5a8:     flag    refct   shlockc exlockc                  0       79      0       0  0xfd0cd5b0:     vfsmnt          vop             pages           vfsp                  0               f817d8b8        f8386a00        fce47c98  0xfd0cd5c0:     type            rdev            data                  2               01      0250    fd0cd5a0  0xfd0cd5d0:     devvp           flag    maj     min     ino                  fce5149c        111  026     0204    28682  0xfd0cd5e0:     fs              dquot           owner           count                  fde5c000        0  f82f607c  2  0xfd0cd5f0:     nextr           freef           freeb                  24576           0               0  0xfd0cd5fc:     delayoff        delaylen        nextrio         writes                  0               0               c000            0  0xfd0cd5fc:     mode    links   uid     gid     size                  040700  2       1889    17      162816  0xfd0cd60c:  atime 1994 Aug 10 03:22:58  mtime 1994 May 26 12:03:15                  ctime 1994 May 26 12:03:15  0xfd0cd620:     addresses  0xfd0cd624:     101a8           10300           10458           10638                  10708           10860           109b8           10b10                  10ca0           10dc0           10f18           110f0                  1e4f8           0               0  0xfd0cd660:     flags           blocks          gen                  0               336             1967826125  *time=Y   1994 Aug 10 03:23:05   masterprocp/X  _masterprocp:  _masterprocp:  f82f607c   f82f607c$<proc  0xf82f607c:     link            rlink           nxt             prev                  f8198b90        0               f82f5e48        f82f5fc8  0xf82f608c:     as              segu            stack           uarea                  fcea29f8        f84ca000        f84ccf58        f84cd000  0xf82f609c:     upri    pri     cpu     stat    time    nice                  071     01      036     03      05      024  0xf82f60a2:     slp     cursig  sig                  0       0       0  0xf82f60a8:     mask            ignore          catch                  2000            300001          2000  0xf82f60b4:     flag            uid     suid    pgrp                  80001           0       0       45  0xf82f60c0:     pid     ppid    xstat   ticks  198  1       0       20  (Output trimmed)   !ps axk vmunix.12 vmcore.12  grep 198  198 ? R   163:51 update  !  $q  Hiya on zen... 

Same inode. Same device. Same process. Same scenario where the inode had just been accessed seconds prior to the panic, most likely by the find command.