Re: smp related
On Wed, 8 Dec 2004 23:10:47 -0800 (PST), Petersan Jean-Pierre wrote I have this old dual processor motherboard which comprise of two PIII - 1Ghz processor. I just finish installing FreeBSD 5.1 on there. After I loged in, I noticed the OS detected only one of the two processors. I would like to know how I can get the system to function as a multi-processor server. Well, FreeBSD 5.1 is a relatively old release. You should try 5.3, or even better, 4.10. The latter has better support for SMP then 5.3 has. Cheers, Jorn. Petersan Jean-Pierre __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail ___ [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]
Re: smp related
On Thu, Dec 09, 2004 at 10:08:59AM +0100, Jorn Argelo wrote: On Wed, 8 Dec 2004 23:10:47 -0800 (PST), Petersan Jean-Pierre wrote I have this old dual processor motherboard which comprise of two PIII - 1Ghz processor. I just finish installing FreeBSD 5.1 on there. After I loged in, I noticed the OS detected only one of the two processors. I would like to know how I can get the system to function as a multi-processor server. Well, FreeBSD 5.1 is a relatively old release. You should try 5.3, or even better, 4.10. The latter has better support for SMP then 5.3 has. Absolutely; and once you've updated, you can add support for SMP by modifying your kernel configuration and recompiling the kernel. See the extensive documentation about this in the freebsd handbook. Kris pgp1rmsRMMMTU.pgp Description: PGP signature
smp related
I have this old dual processor motherboard which comprise of two PIII - 1Ghz processor. I just finish installing FreeBSD 5.1 on there. After I loged in, I noticed the OS detected only one of the two processors. I would like to know how I can get the system to function as a multi-processor server. Petersan Jean-Pierre __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
fatal trap 12 (SMP related)
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 = 0103; cpuid = 1; lapic.id = 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 0xf, 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 = 0103; cpuid = 1; lapic.id = 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. 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? -- //curt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fatal trap 12 (SMP related)
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 = 0103; cpuid = 1; lapic.id = 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 0xf, 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 = 0103; cpuid = 1; lapic.id = 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]
Re: fatal trap 12 (SMP related)
- Original Message - Fatal trap 12: page fault while in kernel mode That might be bad ram, you could try to set a lower bus timing (e.g. 133-100). One of my home systems had programs failing like that on a regular basis, when I tried a lower busspeed the problem went away. (should buy some new ram for that box :) gr, Axel Scheepers ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
