fatal trap 12 (SMP related)

[Joshua Oreman]

On Mon, Jun 23, 2003 at 10:55:20AM -0400 or thereabouts, Asenchi seemed to write:
> Hello,
> 
> I have installed 4.8-stable on my dual processor HP system.  I reconfigured the kernel, and everything worked fine.  Except now after a period of time (even Idle time, see below) my system has this error:
> 
> Fatal trap 12: page fault while in kernel mode
> mp_lock = 01000003; cpuid = 1; lapic.id = 00000000
> fault virtual address	= 0x30
> fault code    		= supervisor read, page not present
> instruction number  	= 0x8:0xc0205661
> stack pointer   	= 0x10:0xff80fcd0
> frame pointer   	= 0x10:0xff80fcd0
> code segment   		= base 0x0, limit 0xfffff, type 0x1b
>       			= DPL 0, pres 1, def32 1, gran 1
> processor eflags  	= interrupt enabled, resume, IOPL = 0
> current process   	= Idle
> interrupt mask   	= tty bio <- SMP: XXX
> trap number    		= 12
> panic: page fault
> mp_lock = 01000003; cpuid = 1; lapic.id = 00000000
> boot() called on cpu#1
> Uptime: 36m17s
> 
> I can see that this is a problem with the SMP config.  What I don't know is what to do with it, is it hardware, software.  I am not sure.  This is the first time I have ever been presented with this.

You need to resolve the 'instruction pointer' value and preferably
give us a coredump. Here are your options, in order of best for us
to worst for us:
1) Compile a new kernel with 'options DDB' and try to reproduce the
   panic. When the kernel panics, you'll get thrown into DDB; enter 'trace'
   (w/o quotes) and you will get a backtrace. Send this to us. Then type
   'continue' whenever the prompt appears so it'll keep panicking :-)
   -- You should use this with #2
2) First, you need to compile a debug kernel. Check your kernel config
   file for the line 'makeoptions -g' or similar. If that exists, skip this
   part. Otherwise, add that line, recompile your kernel and reboot.

   Put dumpdev="/dev/myswapdev" (with the quotes) in /etc/rc.conf,
   replacing myswapdev with your swap device (e.g. ad0s2b). Also run:
   # dumpon /dev/myswapdev
   When you get the panic next, you should see something like "dumping 256 MB"
   in the output. When you reboot, savecore(1) will be run and you'll get the
   coredump in /var/crash. Do this to get the backtrace:
   # cd /var/crash
   # cp /usr/src/sys/compile/GENERIC/kernel.debug . # <-- replace GENERIC with your kernel
   # script gdb.out gdb -k vmcore.0 kernel.debug # <-- replace 0 with the highest numbered vmcore
   (gdb) bt
   [snip]
   (gdb) quit
   
   Now send us the file gdb.out.
3) If neither of the above is feasible, then you can resolve the symbols listed
   above. This is easiest because you don't have to reproduce the panic.
   Taking the "instruction pointer" above
> instruction number  	= 0x8:0xc0205661
   you do this:
   # nm /kernel | grep c0205661
   If that doesn't produce any output (and it probably won't), then chop off the
   last digit and try again, e.g.
   # nm /kernel | grep c020566
   Continue until you get some output; send it to us.


> 
> I do prefer maybe a point in the right direction rather than the answer as I learn a lot more reading up on it.  I just haven't been able to find anything, especially not knowing what I am looking for.
> 
> Can anyone point me in the right direction?

Sure, see above.

-- Josh

> 
> -- 
> //curt
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"