On Mon, 15 Mar 1999, Dmitrij Tejblum wrote:
> 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,
> tf_eflags = 66050, tf_esp = -999002524, tf_ss = -1071228500})
> at ../../i386/i386/trap.c:438
> #10 0xc011a974 in lockmgr (lkp=0xc02659ac, flags=1, interlkp=0x0, p=0x0)
> at ../../kern/kern_lock.c:217
> #11 0xc01d8c5b in vm_map_lookup (var_map=0xc4746e64, vaddr=3294351360,
> fault_typea=1 '\001', out_entry=0xc4746e68, object=0xc4746e5c,
> pindex=0xc4746e60, out_prot=0xc4746e4b "?\a", wired=0xc4746e44)
> at ../../vm/vm_map.c:2463
> #12 0xc01d4153 in vm_fault (map=0xc02659ac, vaddr=3294351360,
> fault_type=1 '\001', fault_flags=0) at ../../vm/vm_fault.c:197
> #13 0xc01ff9ac in trap_pfault (frame=0xc4746f18, usermode=0, eva=3294351360)
> at ../../i386/i386/trap.c:825
> #14 0xc01ff64e in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 46137344,
> tf_esi = -1071149988, tf_ebp = -999002244, tf_isp = -999002304,
> tf_ebx = 18341888, tf_edx = -1000615936, tf_ecx = -1005747008,
> tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071650796, tf_cs =
> 8,
> tf_eflags = 65606, tf_esp = -1072552121, tf_ss = -999654400})
> at ../../i386/i386/trap.c:438
> #15 0xc01fe814 in swtch_com ()
> #16 0xc01ff859 in trap (frame={tf_es = 47, tf_ds = 47, tf_edi = 20,
> tf_esi = 136019608, tf_ebp = -1077948228, tf_isp = -999002156,
> tf_ebx = 307, tf_edx = 136220264, tf_ecx = 136630944,
> tf_eax = 135716928, tf_trapno = 7, tf_err = 0, tf_eip = 134536416,
> tf_cs = 31, tf_eflags = 514, tf_esp = -1077948244, tf_ss = 47})
> 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.
>
> Dima
>
>
>
>
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
>
Brian Feldman _ __ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ ____ | _ \__ \ |) |
FreeBSD: The Power to Serve! _ __ ___ ____ _____ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
