Kernelbau dauert 30 Minuten

ArneE · Beitrag von **ArneE** » 01.07.2004 20:18:47

Hallo,

vor ein paar Tagen haben wir einen neuen 2HE-Server (P4 2.0 GHz, 768MB RAM) gekauft.
Debian Woody war auch zügig installiert und der Rechner bootete in einer angemessenen Geschwindigkeit. Als ich dann jedoch den 2.4.26 bauen wollte, kam ich doch arg ins Staunen. make dep hat 15 Minuten (!!) gebraucht und das eigentliche Kernelbauen ungefähr 35 Minuten. Das System ist ein blankes Woody r0 ohne irgendeine zusätzlich installierte Software.

Die HDD arbeitet zügig:
srv5:/usr/sbin# ./hdparm -i /dev/hda
> UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5

srv5:/usr/sbin# ./hdparm -tT /dev/hda
> /dev/hda:
Timing buffer-cache reads: 1296 MB in 2.00 seconds = 648.00 MB/sec
> Timing buffered disk reads: 164 MB in 3.00 seconds = 54.67 MB/sec

memtest86 habe ich auch schon ca. 25 Stunden laufen lassen. Es wurde kein Fehler entdeckt. Beim Booten zeigt der Monitor auch „Intel Pentium 4 2.0 GHz“ an.

Der Bootprozess verläuft dem Prozessor entsprechend zügig. Sobald aber gcc ins Spiel kommt, ist das System so langsam, dass man die Meldungen auf dem Monitor fast von Hand mitschreiben könnte.

Hat jemand auch nur eine eventuell mögliche Idee, woran die extrem lange Dauer des Kernelbaus liegen könnte?

Beitrag von **feltel** » 01.07.2004 21:20:32

Ist Swapspace verfügbar?

ArneE · Beitrag von **ArneE** » 01.07.2004 22:37:37

Es existiert eine eingebundene Swap-Partition von ca. 1GB.

pdreker · Beitrag von **pdreker** » 02.07.2004 01:16:49

Was für ein Board ist da drin (plus evtl. Ausgabe von lspci)? Gibt es vielleicht ein aktuelleres BIOS? Manche von diesen Dingern (PC sagt man glaube ich

) haben einen BIOS Bug, der dafür sorgt, dass etwas vom Hauptspeicher nicht gecached wird (meistens am oberen Ende des Speichers). Da der Kernel aber dieses "obere Ende des Speichers für seine (teilweise hochkritischen) internen Datenstrukturen verwendet, wird das System extrem (!!) langsam, wenn man bestimmte Sachen macht. Es gab auch schon Fälle, wo das schon bei Booten eintrat, und ein 2,4GHz Xeon über eine Stunde zum booten gebraucht hat...

Schau 'mal was in /proc/mtrr steht, und ob da evtl. was von dem eingebauten Speicher nicht gecached wird...

Patrick

ArneE · Beitrag von **ArneE** » 02.07.2004 07:56:58

Hallo Patrick,

Folgendes board ist im Rechner:
MSI 845GE Max-L mit dem Chipsatz: Intel i845GE

Amibios 3.31 ist aufgespielt und mittlerweile gibt's 3.9 - jedoch sind im Changelog keine Dinge aufgeführt, die hier die Fehlerquelle sein könnten.

Was mich ein bisschen wundert:
/var/log/kern.log:

srv5 kernel: ICH4: not 100% native mode: will probe irqs later

lspci:

srv5:~# lspci
00:00.0 Host bridge: Intel Corp.: Unknown device 2560 (rev 03)
00:02.0 VGA compatible controller: Intel Corp.: Unknown device 2562 (rev 03)
00:1d.0 USB Controller: Intel Corp.: Unknown device 24c2 (rev 02)
00:1d.1 USB Controller: Intel Corp.: Unknown device 24c4 (rev 02)
00:1d.2 USB Controller: Intel Corp.: Unknown device 24c7 (rev 02)
00:1d.7 USB Controller: Intel Corp.: Unknown device 24cd (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82820 820 (Camino 2) Chipset PCI (rev 82)
00:1f.0 ISA bridge: Intel Corp.: Unknown device 24c0 (rev 02)
00:1f.1 IDE interface: Intel Corp.: Unknown device 24cb (rev 02)
00:1f.3 SMBus: Intel Corp.: Unknown device 24c3 (rev 02)
01:08.0 Ethernet controller: Intel Corp.: Unknown device 103a (rev 82)
srv5:~#

/proc/mtrr gibt es nicht.

virtual · Beitrag von **virtual** » 10.07.2004 11:28:20

Scheint wohl ein IRQ-Problem zu sein.

Laut deiner Devicelist kennt der Rechner das halbe System nicht, möglicherweise auch teile auf dem ISA (kann auch ohne Steckplätze vorhanden sein, für langsames Gerät wie Drucker, Sound, Keyboard etc.)

Solange die Geräte weder richtig angesprochen oder vollständig disabled sind,
kann es vorkommen das sie IRQ´s auslösen welche vom System angenommen werden
ohne dass die Routinen die Funktion bedienen.

Im schlimmsten Fall wird sogar ein IRQ ausgelöst, auf dem sich auch ein korrekt eingebundenes Gerät befindet was noch mehr bremst, z.B. Daten vom Netzwerk holen obwohl der Receive-Buffer leer ist.

Zur Lösung fällt mir nur ein daß du möglichst aktuelle Versionen von Kernel/Modulen/Hotplug ranschaffen solltest und evtl. bekannte Fehler nachpatchen musst.

Joghurt · Beitrag von **Joghurt** » 10.07.2004 12:10:05

ArneE hat geschrieben:Amibios 3.31 ist aufgespielt und mittlerweile gibt's 3.9 - jedoch sind im Changelog keine Dinge aufgeführt, die hier die Fehlerquelle sein könnten.

Versuch's doch trotzdem mal mit der neuesten Version; ich glaube irgendwie nicht, dass sie ins ChangeLog ein "fixed stupid Bug that made Linux incredibly slow, shame on us" schreiben

el_cattivo · Beitrag von **el_cattivo** » 10.07.2004 12:35:53

Und schalte alles was du nicht brauchst (USB, COm, LPT...) im BIOS schon von vorne rein ab...

ernohl · Beitrag von **ernohl** » 10.07.2004 12:54:13

ArneE hat geschrieben:
srv5:~# lspci
00:00.0 Host bridge: Intel Corp.: Unknown device 2560 (rev 03)
00:02.0 VGA compatible controller: Intel Corp.: Unknown device 2562 (rev 03)
00:1d.0 USB Controller: Intel Corp.: Unknown device 24c2 (rev 02)
00:1d.1 USB Controller: Intel Corp.: Unknown device 24c4 (rev 02)
00:1d.2 USB Controller: Intel Corp.: Unknown device 24c7 (rev 02)
00:1d.7 USB Controller: Intel Corp.: Unknown device 24cd (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82820 820 (Camino 2) Chipset PCI (rev 82)
00:1f.0 ISA bridge: Intel Corp.: Unknown device 24c0 (rev 02)
00:1f.1 IDE interface: Intel Corp.: Unknown device 24cb (rev 02)
00:1f.3 SMBus: Intel Corp.: Unknown device 24c3 (rev 02)
01:08.0 Ethernet controller: Intel Corp.: Unknown device 103a (rev 82)
srv5:~#

http://www.debianforum.de/forum/viewtop ... 65f16defd9