Date: Tue, 12 Aug 2003 04:52:53 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Bosko Milekic <bmilekic@technokratis.com> Cc: current@freebsd.org Subject: Re: 5.1, Data Corruption, Intel, Oh my! [patch] - Fatal trap 12 Message-ID: <3F38D515.2950D743@mindspring.com> References: <20030811100549.GA33392@technokratis.com> <20030811130937.GA34564@technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F38D515.2950D743>