On 21-Mar-01 Matthew Jacob wrote:
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; lapic.id = 00000000
> fault virtual address   = 0x14

NULL pointer deref..

> fault code              = supervisor read, page not present
> instruction pointer     = 0x8:0xc019d7fa
> stack pointer           = 0x10:0xc8f45ea4
> frame pointer           = 0x10:0xc8f45eb0
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = resume, IOPL = 0
> current process         = 331 (bash)
> kernel: type 12 trap, code=0
> CPU0 stopping CPUs: 0x00000002... stopped.
> Stopped at      propagate_priority+0x6e:        cmpl    0x14(%esi),%ebx
> db> t
> propagate_priority(c8b4c100) at propagate_priority+0x6e

(kgdb) l *propagate_priority+0x6e
0xc019fdce is in propagate_priority (../../kern/kern_mutex.c:201).
201                     MPASS(p->p_magic == P_MAGIC);

Well, err, maybe this line, considering none of the rest of my line numbers
match up I doubt it is this one. :(  Could you pull up kgdb on your
kernel.debug and find out which line this died in?  It could either be that p
is NULL (which could be an unintialized mutex that a mtx_lock later blocked on.)
In fact, this is quite likely just using a mutex that hasn't been init'd.
Might want to add in some code to try to display the description of a mutex if
p == NULL (though it is probably invalid, too.)  Another take might be to add
assertions to the start of mtx_lock_flags() and mtx_lock_spin_flags() that
panic if mtx_lock == 0.


John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to