: :> 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 <dil...@backplane.com> To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message