Hello. Is there a way, when running a non-SMP kernel, to detect or
otherwise tell (software only; the machine is 2400 miles away) if the
system has SMP capibilties? Would /proc/cpuinfo show two CPUs if the
kernel is non-SMP? Thanks!
(btw, the kernel in question is a stock RH6.2 kernel 2.2.14-5, and yes, I
know I should update it anyways and that a SMP kernel will run on a UP
system)
--
Burton Windle [email protected]
Linux: the "grim reaper of innocent orphaned children."
from /usr/src/linux-2.4.0/init/main.c:655
What is the platform ( x86, Sparc, alpha or ?)? On sparc look in the
bootprom (ls /proc/openprom) that works regardless of kernel SMP status.
On Intel I think your out of luck, at least with the commonly available
hardware/software. In theory there could be a bios-peeking structure in
/proc much like openprom that could give you hints...
Sent by: [email protected]
To: [email protected]
cc:
Subject: Detecting SMP
Hello. Is there a way, when running a non-SMP kernel, to detect or
otherwise tell (software only; the machine is 2400 miles away) if the
system has SMP capibilties? Would /proc/cpuinfo show two CPUs if the
kernel is non-SMP? Thanks!
(btw, the kernel in question is a stock RH6.2 kernel 2.2.14-5, and yes, I
know I should update it anyways and that a SMP kernel will run on a UP
system)
--
Burton Windle [email protected]
Linux: the "grim reaper of innocent orphaned children."
from /usr/src/linux-2.4.0/init/main.c:655
yes, just run the famous mptable program. If the machine is SMP then it
will have a valid Intel MP 1.4 configuration tables so the program will
show meaningful output.
Regards,
Tigran
On Tue, 20 Feb 2001, Burton Windle wrote:
> Hello. Is there a way, when running a non-SMP kernel, to detect or
> otherwise tell (software only; the machine is 2400 miles away) if the
> system has SMP capibilties? Would /proc/cpuinfo show two CPUs if the
> kernel is non-SMP? Thanks!
>
> (btw, the kernel in question is a stock RH6.2 kernel 2.2.14-5, and yes, I
> know I should update it anyways and that a SMP kernel will run on a UP
> system)
>
>
On Wed, 21 Feb 2001, Tigran Aivazian wrote:
> yes, just run the famous mptable program. If the machine is SMP then it
> will have a valid Intel MP 1.4 configuration tables so the program will
> show meaningful output.
Does that allow you to detect multiple processors... or just an SMP board?
Jeff
On Wed, 21 Feb 2001, Jeff Garzik wrote:
> On Wed, 21 Feb 2001, Tigran Aivazian wrote:
> > yes, just run the famous mptable program. If the machine is SMP then it
> > will have a valid Intel MP 1.4 configuration tables so the program will
> > show meaningful output.
>
> Does that allow you to detect multiple processors... or just an SMP board?
>
the answer is in section 4.1 of the Intel MP 1.4 spec:
"An MP-compliant system must implement the MP floating pointer
structure, ..."
So, one would normally expect this to mean an SMP board rather than
multiple processors, _HOWEVER_, I can imagine a very clever MP-aware BIOS
implementation which detects that there are many processors and prepares
MP floating config table and does _not_ prepare it otherwise. So, it all
depends on the BIOS implementation.
Actually, I never tried unplugging all-1 processors from my SMP machines
and seeing what sort of MP table is left...
Regards,
Tigran
On Wed, 21 Feb 2001, Tigran Aivazian wrote:
> yes, just run the famous mptable program.
before I am snowed under with questions about where to get this program,
here is the src and binaries that I use -- it is quite possible that there
is a newer version (I suspect Ingo Molnar might know better :)
http://www.moses.uklinux.net/mptable
Regards,
Tigran
On Wed, 21 Feb 2001, Tigran Aivazian wrote:
> So, one would normally expect this to mean an SMP board rather than
> multiple processors, _HOWEVER_, I can imagine a very clever MP-aware BIOS
> implementation which detects that there are many processors and prepares
> MP floating config table and does _not_ prepare it otherwise. So, it all
> depends on the BIOS implementation.
I've seen systems that do so and while it's not forbidden I consider it a
bad thing. It prevents us from being able to use I/O APICs.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Tue, 20 Feb 2001, Burton Windle wrote:
>Hello. Is there a way, when running a non-SMP kernel, to detect or
>otherwise tell (software only; the machine is 2400 miles away) if the
>system has SMP capibilties? Would /proc/cpuinfo show two CPUs if the
>kernel is non-SMP? Thanks!
>
>(btw, the kernel in question is a stock RH6.2 kernel 2.2.14-5, and yes, I
>know I should update it anyways and that a SMP kernel will run on a UP
>system)
Yes, there are several ways. How do you want to know how to do
it, in C, or a bash script? sysconf is one way, parsing
/proc/cpuinfo and /proc/stat is another. Beware though, if you
parse /proc/cpuinfo or stat, it is very different on different
architectures, particularly sparc.
Here is some code which should do it more or less correctly on
any arch:
ncpus=$(egrep -c ^cpu[0-9]+ /proc/stat || :)
[ "$ncpus" = "0" ] && ncpus=1
----------------------------------------------------------------------
Mike A. Harris - Linux advocate - Free Software advocate
This message is copyright 2001, all rights reserved.
Views expressed are my own, not necessarily shared by my employer.
----------------------------------------------------------------------
if (argc > 1 && strcmp(argv[1], "-advice") == 0) {
printf("Don't Panic!\n");
exit(42);
}
Maciej,
with the patch you sent (with MIS counter code) :
CPU0 CPU1
0: 50644222 50826974 IO-APIC-edge timer
1: 239631 233690 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
3: 344151 345715 IO-APIC-edge serial
4: 4 4 IO-APIC-edge serial
5: 331569 327717 IO-APIC-edge soundblaster
8: 268433 271449 IO-APIC-edge rtc
14: 919801 913328 IO-APIC-edge ide0
15: 22625 21407 IO-APIC-edge ide1
18: 149973 150537 IO-APIC-level BusLogic BT-930
19: 5557525 5554806 IO-APIC-level eth0
NMI: 101420638 101425054
LOC: 101475956 101475952
ERR: 90
MIS: 34865
and 11:09am up 11 days, 17:52, 8 users, load average: 1.44, 1.15,
0.77 uptime.
it seems like it is time to get at least the suggestions so far in the
mainstream kernel or at least in Alan's tree. (it's not clear if it has
been already included)
There are a few things that might be related though -- some slow network
performance but I am not sure if that is caused by the patch. I don't
think so but..; I also didn't hammer the whole day on sound to crash it.
typically, a flood ping, sound & backup --> crash within minutes and I
wanted to see how it performs (e.g. no crash) under normal loads. that
part succeeded.
if you like, I can start banging the machine on it's head now.
--
Grobbebol's Home | Don't give in to spammers. -o)
http://www.xs4all.nl/~bengel | Use your real e-mail address /\
Linux 2.2.16 SMP 2x466MHz / 256 MB | on Usenet. _\_v
On Mon, 26 Feb 2001, Roeland Th. Jansen wrote:
> CPU0 CPU1
> 0: 50644222 50826974 IO-APIC-edge timer
> 1: 239631 233690 IO-APIC-edge keyboard
> 2: 0 0 XT-PIC cascade
> 3: 344151 345715 IO-APIC-edge serial
> 4: 4 4 IO-APIC-edge serial
> 5: 331569 327717 IO-APIC-edge soundblaster
> 8: 268433 271449 IO-APIC-edge rtc
> 14: 919801 913328 IO-APIC-edge ide0
> 15: 22625 21407 IO-APIC-edge ide1
> 18: 149973 150537 IO-APIC-level BusLogic BT-930
> 19: 5557525 5554806 IO-APIC-level eth0
> NMI: 101420638 101425054
> LOC: 101475956 101475952
> ERR: 90
> MIS: 34865
The mismatch to IRQ count ratio looks sane.
> it seems like it is time to get at least the suggestions so far in the
> mainstream kernel or at least in Alan's tree. (it's not clear if it has
> been already included)
It is already present in 2.4.2-ac3.
> There are a few things that might be related though -- some slow network
> performance but I am not sure if that is caused by the patch. I don't
> think so but..; I also didn't hammer the whole day on sound to crash it.
There is a small performance impact at every interrupt -- the code that
checks for mismatches incurs it. It's just a few CPU instructions, thus
it should not be noticeable.
> if you like, I can start banging the machine on it's head now.
Please do. I believe the code is safe to be included in 2.4.3, but if
any problem is going to pop up, it'd better do it before than after
applying to the mainstream.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Mon, Feb 26, 2001 at 01:14:11PM +0100, Maciej W. Rozycki wrote:
> It is already present in 2.4.2-ac3.
Yep, I just noticed it. there was a backlog from here to tokyo.
> There is a small performance impact at every interrupt -- the code that
> checks for mismatches incurs it. It's just a few CPU instructions, thus
> it should not be noticeable.
well I saw a lot of collisions on the hub and a slow speed (approx
150kbytes sec) but I don't think collisions & patch is the cause
:-)
> > if you like, I can start banging the machine on it's head now.
>
> Please do. I believe the code is safe to be included in 2.4.3, but if
> any problem is going to pop up, it'd better do it before than after
> applying to the mainstream.
ok, it's box killing time. I just installed a new kernel with the ptches
and some additions and will reboot after I tried to kill the system.
will report here.
--
Grobbebol's Home | Don't give in to spammers. -o)
http://www.xs4all.nl/~bengel | Use your real e-mail address /\
Linux 2.2.16 SMP 2x466MHz / 256 MB | on Usenet. _\_v
On Mon, Feb 26, 2001 at 01:14:11PM +0100, Maciej W. Rozycki wrote:
> On Mon, 26 Feb 2001, Roeland Th. Jansen wrote:
> > if you like, I can start banging the machine on it's head now.
>
> Please do. I believe the code is safe to be included in 2.4.3, but if
> any problem is going to pop up, it'd better do it before than after
> applying to the mainstream.
banged the box quite a bit. so far no weird things like lockups.
still 2.4.1. with the MIS counter (etc) patch.
--
Grobbebol's Home | Don't give in to spammers. -o)
http://www.xs4all.nl/~bengel | Use your real e-mail address /\
Linux 2.2.16 SMP 2x466MHz / 256 MB | on Usenet. _\_v