[Fli4l_dev] kernel-Bugmeldung im log FLI 3.6.2

Friedrich Bartel FrBartel at hotmail.com
Do Okt 10 23:12:15 CEST 2013


Am 10.10.2013 17:03, schrieb Kay Martinen:
> Moin Friedrich
>
> Am 10.10.2013 12:20, schrieb Friedrich Bartel:
>> Am 10.10.2013 11:38, schrieb Kay Martinen:
>>>
>>>> 09.10.2013    00:04:11    router    Notfall    kernel: ------------[
>>>> 09.10.2013    00:04:11    router    Kritisch    kernel: Kernel BUG at
>>>> 09.10.2013    00:04:11    router    Notfall    kernel: invalid
>
> Und hierzu kein Kommentar?

Vermutlich liegt es am gesamten Rechner, weil wie Du schreibst, alles
recht klein dimensioniert ist.

Das warum weiter unten.

Warten wir, bis die Kernelprogrammierer mitlesen und antworten.
>
>>>
>>>> 09.10.2013    02:35:51    router    Warnung    kernel: eth0: Too much
>>>> work at interrupt, status 0x41
>>
>> Ist eth0 eine Realteck Karte?
>
> Kann schon sein. Ich benutze jedenfalls den ne2k-pci treiber und es sind
> noch zwei smc-ultra combo karten drin. Und da die smc eine 10Mbit ISA
> ist muss die eine WAN und die andere DMZ-Seitig sein. Bleibt die Realtek
> (Oder Clone) fürs Lan, also eth0. hw-info sagt:
>
> 0000:00:14.0 	Ethernet controller 	KTI 	ET32P2

eth0 ist LAN

Genaueres sagt die base.txt oder auf dem Rooter im verzeichnis Boot die 
rc.cfg bei NET_DRV_2
>
>> Die Netzwerkkarte hat sich entweder einen Interrupt eingefangen bevor
>> sie mit dem letzten fertig war, oder ein im Treiber eingebauter
>> Schwellwert für die Dauer im Interrupt wurde überschritten...
>
> Oder hängt es damit zusammen das zwei Stunden vorher dieser Bug Report
> im log steht? Der Router läuft weiter ohne merkbare probleme!
> Aber, kann es sein das der Bug da was zum stolpern brachte (ich les da
> was von kswapd???)

kswapd ist die Kernelfunktion, die sich um freien Speicher kümmert und
Seiten auslagert. kswapd versucht RAM freizuschaufeln, der durch
(Kernel)Prozesse belegt war.

Prozesse, die zu lange idle sind, werden ausgeswappt, um Platz für den
Filecache freizumachen. Zudem versucht sich der komplette Kernel in den
Arbeitsspeicher zu laden, damit er schneller agieren kann.

Also arbeiten hier bei zu wenig Physikalischen Speicher der Kernel und
kswapd gegeneinander, weil der Kernel immerfort Prozesse neu startet
die idle waren, vom kswapd ausgelagert wurden und wieder Speicher
benötigen.
kswapd lagert so viel wie möglich in die noch langsamere Swap-Partition
auf Platte aus, falls diese angelet wurde, bzw die groß genug ist.

Das kennt man von Windows, das die Kiste irgendwann langsamer wird und
ewig braucht, irgendeinen Prozess einer länger nicht genutzen
Applikation zu starten, weil der sich in der Auslagerungsdatei befindet
und zurück in den vollen Arbeitsspeicher muss.

free_buffer_head war im ferhlerlog auch mit dabei. Ist kein freier
Puffer mehr im RAM muss der aufgerufene Prozess solange warten bis
dafür Speicher vorhanden ist.

Z.B. das rrdtool produziert je nach Einstellung der Intervalle
entsprechend Daten, die zudem auf Platte geschrieben werden.

Es könnte hier schon zum Ausbremmsen des Prozessors und Kernels
kommen, weil kswapd und free_buffer_head sich um jedes Byte des knappen
Arbeitsspeichers bemühht.
>
> Ist dir aufgefallen das zwischen bug und too much work 2 stunden liegen
> in denen keine warnungen im log standen - außer den üblichen vom pppd.
Die beiden müssen erstmal nichts gemeinsam haben aber in Summe mit
alles laufenden Prozessen. Die Bugwarnung hat nur gesagt, dass das
System ausgelastet war und beschrieben wer alles damit zutun hatte.
>
> Korrigiere mich wenn ich irre, aber wenn ein zweiter interrupt ein
> trifft wenn die CPU ihn schon bearbeitet müsste sie eine Exception
> auslösen. Zumindest bei gleichem interrupt.
Exceptions treten bei Fehlern auf. Der Kernel kann in manchen Fällen
den Fehler beheben und das unterbrochene Programm fortsetzen. In
anderen Fällen bleibt ihm nicht anderes übrig als das Programm
(möglicherweise sich selbst) abzubrechen und eine Fehlermeldung
auszugeben.

IRQs werden von verbauter Hardware ausgelöst. Sie müssen vom passenden
Treiber verarbeitet werden.

Da der Prozessser bemüht ist allen nacheinander dienlich zu sein kommt
es irgendwann zu Wartezeiten und Fehlern.
>
>>
>> Im Prinzip ist das nur eine Überlastwarnung und ein Schutzmechanismus,
>> damit der Treiber nicht den Rechner komplett lahmlegt, wenn die Karte
>> ausgelastet ist...
>
> Was würde in dem fall als nächstes passieren? Würde der kernel den
> treiber aus dem ram werfen, ihn neu laden und weiter machen?
Siehe Exceptions.

Bockt die Netzwerkkarte blockiert der Treiber das System.
Es bremst sich das gesamte System aus, wenn bestimmte Daten von der
Swappartition in den Arbeitsseicher geholt werden müssen und kein
Arbeitsspicher da ist.

Gehen wir von einer Überlastung aus, steht die gesamte Kiste mal mehr
oder weniger kurzzeitig, bis durch das umlagern wieder genug RAM da ist
oder der Prozessor mit der Last runter kommt.
>
> Gut, das RAM ist recht voll, es sind lt. rrdtool nur ca. 1.6 MB frei -
> das aber fast immer.

Was sagt: cat /proc/meminfo
>>
>> Tausche die mal gegen eine 3Com aus und weise der Karte einen Interrupt
>> zu, also kein Interrupt sharing.
>>
>
> Der Compaq hat nur einen PCI-Slot und kein Setup Im ROM. Ich glaube
> nicht das der da was teilt.
Wäre neu, das ältere Compaq Rechner keines hatten.

Bekommt man mit der Entf oder F2, F10 oder F12-Taste zu sehen, wenn man
den Rechner einschaltet.
Es gab auch Modelle, die ein reines Software-Setup hatten und wenn das
nicht in einer Partition auf der HD ist, geht nichts über enf oder 
F-Tasten. Konfigurieren konnte man immer was.

>
> ABER, ich habe im server eine 3com die auch einmal auf merkwürdige weise
> aussetzte und es danach klaglos wieder tut.

Ich baue die Karten in den Rechnern 1x im Jahr aus und reinige die 
Kontakte, somit schließe ich Korrosionen aus. Nach langen Jahren Einsatz
defekte Hardware verabschiedet sich entweder spontan oder streut leise
Fehlermeldugen ins Logfile.

> UND, ich bin sowieso auf dem wege mir einen anderen PC für einen neuen
> FLI zusammen zu stöpseln.
>
> Ich würde halt nur gern eine erklärung für diese bug meldung im log
> finden. Also: Zu wenig RAM oder was mag es wohl sein?

Wie schon gesagt: RAM und Prozesser, Hardwarekomponenten die im 
Einzelfall oder in Summe nicht korrekt zusammenspielen oder geeignet
sind, wegen ihres Alters anfangen Macken zu bekommen.

Erstmal nichts dramatisches aber eine Warnung, das man was tun sollte,
weil es einen Flaschenhals gibt.
>
> Kay
>

Friedrich


Mehr Informationen über die Mailingliste Fli4l_dev