On Sun, Sep 15, 2013 at 6:17 AM, C. Bensend <[email protected]> wrote:
>> For the two crashes that I've been able to capture some output
>> from (one from an IP KVM, one from /var/log/messages after setting
>> ddb.panic=0), I've seen:
>>
>> uvm_fault(0xffffffff81cf2b20, 0xffff800000cef000, 0, 2) -> e
>> kernel: page fault trap, code=0
>> Stopped at memmove+0x16: repe movsq (%rsi),%es:(%rdi)
>>
>> and
>>
>> reboot after panic: trap type 8, code=0, pc=ffffffff81292dff
>
> Whoops - the hosting company caught some of the panic message before
> it rebooted this morning (retyped from a screenshot):
This part:
> VOP_FSYNC() at VOP_FSYNC+0x2f
> ffs_sync_vnode() at ffs_sync_vnode+0x77
> vfs_mount_foreach_vnode() at vfs_mount_foreach_vnode+0x38
> ffs_sync() at ffs_sync+0x83
> sys_sync() at sys_sync+0xa1
> vfs_syncwait() at vfs_syncwait+0x50
> vfs_shutdown() at vfs_shutdown+0x32
> boot() at boot+0x17f
> panic() at panic+0xf6
is from the "boot crash", not the original crash. Looking at the
original crash:
> --- trap (number 8) ---
> ffs_update() at ffs_update+0x19f
That points to the math in the ino_to_fsba() macro in this like of ffs_update()
error = bread(ip->i_devvp, fsbtodb(fs, ino_to_fsba(fs, ip->i_number)),
(int)fs->fs_bsize, &bp);
It's trying to calculate the block address of the inode so that it can
update the timestamps in it and divided by zero. That means the
in-memory copy of the superblock had zeros in on other another member.
If the on-disk superblock had zeros there, I would expected fsck to
catch it, or for it to crash earlier, but maybe a forced fsck is in
order. Otherwise, something's writing through a bogus pointer in the
kernel...
Philip Guenther
