Re: kernel panic

Daniel Eischen wrote:
> I'm getting kernel panics every now and them from kernel sources
> cvsup'd a few hours ago.  Same configured kernel from Friday is
> OK.
> 
> Typed by hand:
> 
>   Fatal trap 12: page fault while in kernel mode
>   fault virtual address       = 0xd0d10080
>   fault code                  = supervisor read, page not present
>   instruction pointer         = 0x8:0xc03adceb
>   stack pointer               = 0x10:0xd1353bb0
>   frame pointer               = 0x10:0xd1353bbc
>   code segment                = base 0x0, limit 0xfffff, type 0x1b
>   processor eflags            = interrupt enabled, resume, IOPL = 0
>   current process             = 607 (bash)
>   kernel: type 12 trap, code = 0
>   Stopped at pmap_allocpte+0x13:movl 0(%eax, %esi, 4), %edx
>   db> trace
>   pmap_allocpte(c1e594b0, 8141000, 0, c037b961m c1e59400) at pmap_allocpte+0x13
>   pmap_enter(c1e54b0, 8141000, c0ad7ac0, 3, 0)at pmap_enter+0x39
>   vm_fault(c1e59400, 8141000, 2, 8, c1e2fbe0) at vm_fault+0xec7
>   trap_pfault(d1353d48, 1, 8141b7c, 8141b7c, 6) at trap_pfault+0xcc
>   trap(2f, 2f, 2f, bfbffbf0, bfbffc00) at trap+0x213
>   calltrap() at calltrap+0x5
>   --- trap 0xc, eip=0x80480d5, esp = 0xbfbffbd0, ebp = 0xbfbffbe8 ---

If this is i386, then nothing in pmap.c has changed in the
last two weeks.  There was a change to trap.c by jhb, but
it should not have caused a problem here, either, since the
change only moved a PROC_LOCK() call outside an "if" to
protect the "if".

>From the code, it looks like:

        /*
         * Get the page directory entry
         */
        ptepa = (vm_offset_t) pmap->pm_pdir[ptepindex];

...is what's breaking.  This says to me "bad pmap argument".

Are you maybe half compiled with PSE support?  Alternately, you
need to decode c1e594b0.

You can't tell from the code whether this is:

        pmap_enter(fs.map->pmap, vaddr, fs.m, prot, wired);

or:

	pmap_enter(dst_map->pmap, vaddr, dst_m, prot, FALSE);

in vm_fault() in vm/vm_fault.c.  You need to dump the memory at:

>   vm_fault(c1e59400, 8141000, 2, 8, c1e2fbe0) at vm_fault+0xec7

...c1e59400... this is a vm_map_t, and see if it references the
dst_map->pmap as ...c1e594b0... probably it does, since the
numbers are suspiciously close to each other.

If that's the case, I'd have to say that it was faulting on a
user page map that wasn't mapped into the kernel address space
at the time of the fault.

This might be related to some of the recent threads commits, if
this is triggered only by threads.

It would be instructive to have the stack backtrace for the
kernel prior to the trap event, to see what triggered the trap.

Of course, this might only be our old friend:

	options DISABLE_PSE
	options DISABLE_PG_G

...if you are running your own kernel config.

-- Terry