:
:> Matthew Dillon wrote:
:> >
:> > We'll get a quick fix committed but the lockmgr stuff needs a real
:> > going-over... having interrupts using the general lockmgr call is
:> > a disaster waiting to happen.
:>
:> Hmmm. After I looked a bit further, it looks like a bug in the
:> scheduler (?). Here is the stack trace:
:>
:> #9 0xc01ff64e in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 0,
:> tf_esi = 16777216, tf_ebp = -999002708, tf_isp = -999002744,
:> tf_ebx = -1071228500, tf_edx = -2, tf_ecx = 0, tf_eax = 0,
:> tf_trapno = 12, tf_err = 0, tf_eip = -1072584332, tf_cs = 8,
:...
:> at ../../i386/i386/trap.c:195
:> #17 0xc01f5aa3 in swi_ast_user ()
:>
:> the trap in swtch_com() (frame #15) is here:
:> /* switch address space */ <----- line 622
:> movl %cr3,%ebx
:> cmpl PCB_CR3(%edx),%ebx <----- trap
:> je 4f
:>
:> I don't think this line is supposed to cause a trap...
:
:When it says "switch address space" What exactly do you think it's going to
:do? What I mean is, I'm pretty certain this is a good trap =)
:
:The real problem did seem to be the NULL p dereference, as it was obvious
:that it could happen in the code.
I don't think the system is supposed to trap there.
-Matt
: FreeBSD: The Power to Serve! _ __ ___ ____ _____ |___/___/___/
Matthew Dillon
<[email protected]>
To Unsubscribe: send mail to [email protected]
with "unsubscribe freebsd-current" in the body of the message
