[Linux] smp monitoring

[Erhnam]

Tooltjes zoals 'top' laten bv niet zien op welke cpu een process draait. Ook is er niet te zien welke cpu het drukste bezig is. Weten mensen misschien commandline tooltjes, die zoals bv bandmon dat heel erg mooi doet met je dataverkeer.. Realtime de status geven van hoe druk de cputjes bezig zijn ? Ik heb al even gezocht op google maar kon niet zo snel iets nuttigs vinden.

[odysseus]

Met top moet dat toch kunnen? Je kunt in ieder geval het processorgebruik per processor bekijken en dergelijke...zie daarvoor de manpage van top. Overigens weet ik niet of oude versies dat ook kunnen, als ik het me goed herinner stond er laatst iets over in de Debian-changelog van top over SMP-capabilities.

[Verwijderd]

Erhnam schreef op 27 oktober 2002 @ 18:24:
Tooltjes zoals 'top' laten bv niet zien op welke cpu een process draait. Ook is er niet te zien welke cpu het drukste bezig is. Weten mensen misschien commandline tooltjes, die zoals bv bandmon dat heel erg mooi doet met je dataverkeer.. Realtime de status geven van hoe druk de cputjes bezig zijn ? Ik heb al even gezocht op google maar kon niet zo snel iets nuttigs vinden.

Volgens mij *kan* Linux dat niet. Per process aangeven op welke CPU 't draait bedoel ik dus. Ik heb zelf ook een SMP-bak (BP6 met 2 celerons), en heb nog nooit kunnen zien op welke processor een process draaide.

[Erhnam]

Hiero ook een bp6 met 2 cellie.. Dan heb je zeker ook last dat je logs worden volgeschreven met vage foutmeldingen ?

[Verwijderd]

Erhnam schreef op 27 oktober 2002 @ 20:30:
Hiero ook een bp6 met 2 cellie.. Dan heb je zeker ook last dat je logs worden volgeschreven met vage foutmeldingen ?

define 'vage foutmeldingen?'

/me heeft ook nog een BP6-je rondhangen

[odysseus]

Verwijderd schreef op 27 oktober 2002 @ 20:27:
Volgens mij *kan* Linux dat niet. Per process aangeven op welke CPU 't draait bedoel ik dus. Ik heb zelf ook een SMP-bak (BP6 met 2 celerons), en heb nog nooit kunnen zien op welke processor een process draaide.

Dat kan Linux in principe wel, aangezien het die processen toch moet loadbalancen over de processoren (er zijn speciale patches die ervoor moeten zorgen dat processen niet of weinig heen en weer gaan tussen processoren). Of Linux de informatie per proces naar userland doorstuurt weet ik niet, maar de load per processor in ieder geval wel. Druk maar eens op '1' in top, dan krijg je de per-CPU load te zien (that is, voor zover ik dat kan zien op mijn single proc computer). Met 'I' (hoofdletter i) kun je switchen tussen bepaalde soorten weergave.

[Erhnam]

Verwijderd schreef op 27 oktober 2002 @ 21:24:
[...]


define 'vage foutmeldingen?'

/me heeft ook nog een BP6-je rondhangen

APIC error on CPU0: 0a(0a)
APIC error on CPU0: 0a(0a)
APIC error on CPU0: 0a(02)
APIC error on CPU1: 04(07)
APIC error on CPU1: 07(08)
APIC error on CPU1: 08(08)
APIC error on CPU0: 02(08)


Dat soort meldingen....

[Mark]

Optie disableapic meegeven aan je kernel en je meldingen zijn weg....APIC onder Linux is soms nog steeds een probleem. Op mijn BP6 krijg ik met kernel 2.4.18 ook deze meldingen in de log, op een dual P3 systeem van mij heb ik zelfs last van spontane reboots als ik APIC support aan heb. Heel snel uit dus

[Verwijderd]

die apic error word veroorzaakt door een brakke smp implementatie van het bp6 bord. Het is verder ongevaarlijk en je kunt zoals hierboven staat de apic driver uitzetten, waarna de melding verdwijnt.

Als je een process wilt binden aan een bepaalde cpu moet je de cpu affinity patch eens installen. (zit in wolk als ik me niet vergis). Met deze patch moet je een process (pid) aan een cpu kunnen binden.

[kieskes]

Heb je geen C Entry in je top?

Ik heb hier ook een bp6 draaien, en daar kan ik dus met top zien op welke cpu een proces draait onder de 'C' van CPU

[Erhnam]

Mark schreef op 28 oktober 2002 @ 01:01:
Optie disableapic meegeven aan je kernel en je meldingen zijn weg....APIC onder Linux is soms nog steeds een probleem. Op mijn BP6 krijg ik met kernel 2.4.18 ook deze meldingen in de log, op een dual P3 systeem van mij heb ik zelfs last van spontane reboots als ik APIC support aan heb. Heel snel uit dus

CONFIG_X86_IO_APIC=n
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_GOOD_APIC=y

Probeer hem nu eerst zo... Zou ik die andere ook op 'n' moeten zetten ?

[Wilke]

Erhnam schreef op 27 oktober 2002 @ 22:29:
[...]


APIC error on CPU0: 0a(0a)
APIC error on CPU0: 0a(0a)
APIC error on CPU0: 0a(02)
APIC error on CPU1: 04(07)
APIC error on CPU1: 07(08)
APIC error on CPU1: 08(08)
APIC error on CPU0: 02(08)


Dat soort meldingen....

Ja dat heb ik dus ook...precies hetzelfde...woei...weet ik ook eindelijk waar dat aan ligt

Of je kunt zien waar een proces draait: dacht ik niet, omdat het ook verplaatst kan worden kun je daar geen staat op maken. Misschien is het via /proc toch ergens te achterhalen

[Erhnam]

CONFIG_X86_IO_APIC=n
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_GOOD_APIC=y

Zo werkt het niet Ga nu proberen de andere op n kijken wat die dan doet.

[Verwijderd]

Apic op een Asus A7M266-D werkte tot bios 1004 niet. Na 1004 werkt het perfect.

[Erhnam]

Weet iemand hoe je dat disableapic activeerd ? Is dat een optie in je kernel of is dat een bootparameter ?

append = "disableapic" had ik ergens gelezen ?

[Verwijderd]

In je lilo.conf of grub.conf zetten.
Zie "man lilo" of "man grub"

[N8w8]

Processen zijn in Linux niet gebonden aan 1 CPU, vandaar dat je ook niet kan zien op welke CPU een proces draait.
En die APIC errors zijn voor zover ik weet onschuldig. Heb er zelf nooit last mee gehad terwijl ik ze wel tegenkom (heb ook n BP6). Volgens mij kan SMP niet eens zonder I/O APIC (je hebt ook nog een local APIC wat weer wat anders is).

Kan het fout hebben maar dat hoor ik dan wel

[Erhnam]

/etc/lilo.conf:

code:

image = /boot/vmlinuz-2.4.19
  root = /dev/hda1
  label = Linux
  read-only
  append = "disableapic"

Na een reboot zie ik ze nog steeds, die errors

Deze:

code:

APIC error on CPU1: 08(08)
APIC error on CPU1: 08(08)
APIC error on CPU1: 08(08)
APIC error on CPU1: 08(08)
APIC error on CPU1: 08(08)

Iemand een goede oplossing voor dit probleem.. zoals hierboven ben ik niet de enige ?

[odysseus]

Heb je wel LILO nog een keer gedraaid na het editen en voor het rebooten?

[Erhnam]

odysseus schreef op 04 november 2002 @ 15:06:
Heb je wel LILO nog een keer gedraaid na het editen en voor het rebooten?

Yep

[odysseus]

Als ik het me goed herinner (heb de optie nooit hoeven te gebruiken) dan is het niet 'disableapic', maar 'noapic'. Werkt dat wel?

[Erhnam]

code:

The `noapic' Argument
Using this option tells a SMP kernel to not use some of the advanced features of the interrupt controller on multi processor machines. Use of this option may be required when a device (such as those using ne2k-pci or 3c59xi drivers) stops generating interrupts (i.e. cat /proc/interrupts shows the same interrupt count.) See linux/Documentation/IO-APIC.txt for more information.

Kwam deze info tegen... Ga het nu even proberen met deze lilo.conf:

code:

boot = /dev/hda
message = /boot/boot_message.txt
prompt
timeout = 10
vga = normal
default = linux
image = /boot/vmlinuz-2.4.19
  root = /dev/hda1
  label = linux
  read-only
  append = "noapic"

Hopen dat die nu wel lekker werkt!

[Erhnam]

Ben er uit...Kwam dit tegen op internet na VEEL en Veel zoeken:

My system locks up with no oops messages

If you are using kernels 2.2.11 or 2.2.12, get the latest kernel.
For example 2.2.13 has a number of SMP fixes. Several people have
reported these kernels to be unstable for SMP. These same kernels
may have NFS problems that can cause lockups. Also, use a serial
console to capture your oops messages. (Wade Hampton)

If the problem remains (and the other suggestions on this list
didn't help either), then you could try the latest 2.3 kernels.
They have more verbose (and more robust) SMP/APIC code, and
automatic hard-lockup-prevention code which will produce meaningful
oopses instead of a silent hang. (Ingo Molnar)

(Osamu Aoki) You MUST also disable all BIOS related power save
features. Example of good configuration (Dual Celeron 466 Abit
BP6):

_________________________________________________________________
POWER MANAGEMENT SETUP.
ACPI: Disabled
POWER MANAGEMENT: Disabled
PM CONTROL by APM: No
_________________________________________________________________

en:

Most Linux distributions don't provide a ready-made SMP-aware
kernel, which means that you'll have to make one yourself. If you
haven't made your own kernel yet, this is a great reason to learn
how. Explaining how to make a new kernel is beyond the scope of
this document; refer to the Linux Kernel Howto for more
information. (C. Polisher)

In kernel series 2.0 up to but not including 2.1.132, uncomment the
SMP=1 line in the main Makefile (/usr/src/linux/Makefile).

In the 2.2 version, configure the kernel and answer "yes" to the
question "Symmetric multi-processing support" (Michael Elizabeth
Chastain).

AND

enable real time clock support by configuring the "RTC support"
item (in "Character Devices" menu) (from Robert G. Brown). Note
that inserting RTC support actually doesn't afaik prevent the known
problem with SMP clock drift, but enabling this feature prevents
lockup when the clock is read at boot time. A note from Richard
Jelinek says also that activating the Enhanced RTC is necessary to
get the second CPU working (identified) on some original Intel
Mainboards.

AND

(x86 kernel) do NOT enable APM (advanced power management)! APM and
SMP are not compatible, and your system will almost certainly (or
at least probably ) crash while booting if APM is enabled (Jakob
Oestergaard). Alan Cox confirms this : 2.1.x turns APM off for SMP
boxes. Basically APM is undefined in the presence of SMP systems,
and anything could occur.

AND

(x86 kernel) enable "MTRR (Memory Type Range Register) support".
Some BIOS are buggy as they do not activate cache memory for the
second processor. The MTRR support contains code that solves such
processor misconfiguration.

You must rebuild all your kernel and kernel modules when changing
to and from SMP mode. Remember to make modules and make
modules_install (from Alan Cox).

If you get module load errors, you probably did not rebuild and/or
re-install your modules. Also with some 2.2.x kernels people have
reported problems when changing the compile from SMP back to UP
(uni-processor). To fix this, save your .config file, do make
mrproper, restore your .config file, then remake your kernel (make
dep, etc.) (Wade Hampton). Do not forget to run lilo after copying
your new kernel.

Met de volgende bootparameters loopt die nu goed:

append = "apm=off acpi=off noapic"

Tevens heb ik alle meuk mbt apm en acpi in de bios uitgezet en nu loopt die als een trein