5.1, Data Corruption, Intel, Oh my! [patch] - Fatal trap 12

[Terry Lambert]

Bosko Milekic wrote:
> > db> trace
> > _mtx_lock_flags(0,0,c07aa287,11e,c0c21aaa) at _mtx_lock_flags+0x43
> > vm_fault(c102f000,c0000000,2,0,c08205c0) at vm_fault+0x2b4
> > trap_pfault(c0c21b9e,0,c00004d8,100000,c00004d8) at trap_pfault+0x152
> > trap(6c200018,10,1bc40060,1c,0) at trap+0x30d
> > calltrap() at calltrap+0x5
> > --- trap 0xc, eip = 0x5949, esp = 0xc0c21bde, dbp = 0xc0c21be4 ---
> > (null)(1bf80058,0,530e0102,80202,505a61) at 0x5949
> > db>

FWIW: This is a NULL function pointer that's trying to call a
function that hasn't been initialized, or has been explicitly
NULL'ed out.  Decoding the pointer values to find out what the
object are would probably go a long way toward knowing what's
going on.  Last time I saw one of these, it was the NFS lease
function.  He might also want to look for any function pointer
that takes 5 arguments; Linux threads is a likely suspect, in
that the thread mailboxes are at a fixed location, so he should
make sure to recompile any kernel modules when he compiles his
new kernel.

BTW: Good work on the patch, both you and Peter!

-- Terry