Crash 12: A closer look

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.