On Wed, Nov 24, 2004 at 07:04:16PM -0500, John Klos wrote:
> data fault: pc=100aaac addr=0
> kernel trap 30: data access exception
> Stopped in pid 7.1 (ioflush) at netbsd:pseg_get+0x3c:   ldxa 
> [%o2 + %
> g0] 20, %o2
> db>
> db> tr
> genfs_putpages(1, 1, 0, 5dda600, 5df9590, 11) at 
> netbsd:genfs_putpages+0x810
> VOP_PUTPAGES(5de9540, 0, 0, 11, e0017de8, 80) at netbsd:VOP_PUTPAGES+0x30
> ffs_full_fsync(5de9540, 10012, 14973d0, 0, 5de9540, 1892c00) at 
> netbsd:ffs_full_
> fsync+0x244
> ffs_fsync(5df9a60, 10012, 5de9760, 0, 1127840, 6) at netbsd:ffs_fsync+0x44
> VOP_FSYNC(5de9540, 1e4df00, 0, 0, 0, 5dcaea0) at netbsd:VOP_FSYNC+0x38
> ffs_sync(1f43600, 3, 1e4df00, 5dcaea0, 22, 1e) at netbsd:ffs_sync+0x20c
> sync_fsync(5df9d00, 10012, 14973d0, 0, 61f3370, 1845aa8) at 
> netbsd:sync_fsync+0x
> 88
> VOP_FSYNC(61f3370, 1e4df00, 8, 0, 0, 5dcaea0) at netbsd:VOP_FSYNC+0x38
> sched_sync(148bc00, 1817800, 1813400, 1846800, 1846800, 18af400) at 
> netbsd:sched
> _sync+0x1cc
> proc_trampoline(0, 0, 0, 0, 0, 0) at netbsd:proc_trampoline+0x4
> 
> 
> Any ideas?

It died dereferencing a NULL pointer.  You should dump the trapframe
to verify that the register containing the pointer really is zero,
then disassemble the routine to find out where the NULL came from.
This sort of thing can be caused by all sorts of things including
CPUs that are getting old and suffering bitrot.

Eduardo