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 > _______________________________________________ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"