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
