:
:> 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

Reply via email to