Hallo zusammen, ich habe eben bereits das zweite Mal innerhalb von 2 Wochen eine Kernel Panic auf meinem Server gehabt, die zum Komplett-Absturz des Systems führte. Nichtmal der MagicSystemKey-Request konnte mir noch helfen, ich musste wirklich auf Reset drücken. Das ist mir (außer bei schweren, graphischen X-Fehlern) in all den Jahren GNU/Linux noch nie passiert. Ich habe die ersten Zeilen eben mal per Hand abgeschrieben: --------8<-------- skput:over: c027dccc:8172 put:8172 dev: eth0 ----[ cut here ]---- kernel BUG at net/core/skbuff.c:91! invalid operand: 0000 [#1] Modules linked in: iptable_filter iptables CPU: 0 [...] -------->8-------- Und dann kommen einige Speicherinformationen. Das war wie gesagt das zweite Mal und geschah beide Male, als ich an meiner Workstation (per NFS angebunden) am Areiten war. Beim ersten Mal hatte ich Panik, dass irgendwas einen Pufferüberlauf verursacht haben könnte und habe erstmal nach Rootkits gescannt und danach 4 Stunden lang iptraf verfolgt. :-\ Ich habe mir nach dem heutigen Absturz dann mal folgende Dinge angesehen: - Wegen des "Modules linked" in der Fehlermeldung: Ich habe nur eine einzige iptables-Regel - für meinen sshdfilter: iptables -N SSHD iptables -A INPUT -p tcp -m tcp --dport 22 -j SSHD Ich habe versucht, diese Chain triggern, was auch ohne Absturz funktioniert. - Google: Man findet den Fehler einige Male, allerdings habe ich nicht viel hilfreiches gefunden, außer vielleicht [1], das ist ganz interessant... aber auch nicht hilfreich, glaube ich. Was hat sich an der Kiste geändert: Bevor der Fehler das erste Mal aufgetreten ist, lief die Kiste monatelang problemlos durch. Es hat allerdings in der Tat eine Änderung gegeben: - Ich habe eine Realtek 8139too getauscht gegen eine r8169. Eigener Schuss ins Blaue: Auf meiner Workstation läuft ein wesentlich neuerer Kernel (2.6.16). In der Kernel-Config hatte ich beim NIC-Treiber (ebenfalls r8169, ebenfalls neu) die Zusatzoption aktiviert (die der 2.6.8 an dieser Stelle noch nicht hat): <*> Realtek 8169 gigabit ethernet support [*] Use Rx and Tx Polling (NAPI) (EXPERIMENTAL) Im Hilfetext dazu steht: ---8<--- NAPI is a new driver API designed to reduce CPU and interrupt load when the driver is receiving lots of packets from the card. It is still somewhat experimental and thus not yet enabled by default. If your estimated Rx load is 10kpps or more, or if the card will be deployed on potentially unfriendly networks (e.g. in a firewall), then say Y here. --->8--- In der Tat hatte ich zumindest bei dem Absturz eben eine hohe Verbindungs-Last, da ich ein ISO aus dem Netz gesaugt und direkt per NFS abgespeichert habe (aber wenn es daran liegen sollte, was hat dann iptables damit zu tun?). Jedenfalls hab ich "Rx and Tx Polling" jetzt mal ausgeschaltet. Allerdings: Kann mein Client denn mit dieser Funktion eine Kernel-Panic beim Server verursachen? - nur weil der Server das nicht unterstützt? Hat sonst noch jemand eine Idee, was das sein könnte? Hat ggf. schonmal jemand diesen Fehler selbst gehabt? Wo und wie könnte ich noch debuggen? Mehr als ungünstig, dass mir gerade dieser Rechner abschmiert. :( Liebe Grüße, Ace [1] http://www.bughost.org/bugscrub/2004-12-02.txt -- () ASCII Ribbon Campaign - against HTML mail /\ - against Microsoft attachments http://www.efn.no/html-bad.html http://www.goldmark.org/netrants/no-word/attach.html
Attachment:
signature.asc
Description: PGP signature