VIA ITX mit Linux
|
 |
VIA EPIA PD-10000 Board mit SuSE-Linux betreiben
Dieser Artikel handelt von dem Versuch, VIA EPIA-Boards (PD-10000) unter Linux zum laufen zu bringen.
Wie alle begann ...
Für LAN-Partys habe ich managebare Switche, die man mit SNMP abfragen kann. Als
Management-/Überwachungsserver habe ich zwei Barebones mit 1,8GHz-Celeron verwendet.
Die Server haben dann die Auslastung der Switch-Ports überwacht, doppelte IPs, Viren und
Angriffe erkannt und gemeldet. Da ich aber die beiden Barebones nicht jedesmal mitnehmen und
alles verkabeln wollte, war ich recht glücklich über ein altes 19Zoll-PC-Gehäuse.
Das alte Mainboard (200MHz Pentium) habe ich erst einmal ausgebaut. Danach war viel Platz vorhanden.
Also habe ich drei VIA ITX-Boards (PD-10000) und drei Micro-ATX-Netzteile besorgt (Reichelt elektronik).
Die haben gestapelt und gepreßt genau in das Gehäse gepaßt ;-)
Als erstes habe ich eine SuSE 9.2 Professional installiert (wegen der Netzwerkdienste). Lief auch
recht gut. Aber ab und zu fraß sich das Betriebssystem fest (blieb einfach stehen). Außer
Reset-Taster oder Netzschalter hat nichts mehr eine Reaktion ausgelößt. Am Anfang hab ich
ja noch gerätselt, woran das liegen kann. Immer wenn man große Kopieraktionen (Backup,
Filetransfer) gestartet hat, stand der PC nach kurzer Zeit.
Dann habe ich aus Frust (Scheiß Fehlersuche) mal im Internet gesucht. Siehe da, mehrere
Foreneinträge gefunden. Das Ergebnis in Kürze: Das VIA ITX-Board hat bei mehreren
gleichzeitigen Aktionen, die über DMA laufen Probleme :-( . Das Bios und der Chipsatz
kriegen das dann nicht mehr auf die Reihe und fressen sich fest. Also kein Linux-Problem.
Zum Glück ist das Problem aber schon einige Zeit bekannt und ein paar Leute haben VIA
wohl so lange genervt, bis sie ein BIOS-Update rausgebracht haben. Auf meinem Board lief die
Version 1.03 . Im Internet war als Bugfix Version 1.05Test (i0e0t105.bin) vom 11.10.2005 als
Download für PD-Boards verfügbar.
Also ran an die Fehlerbehebung! BIOS und Award-Flash-Programm runtergeladen (awfl823b.exe) und
schnell mal eine DOS-Bootdiskette erstellt. Das Flashen (Backup des aktuellen BIOS nicht vergessen)
ist an sich das kleinste Problem. Danach kommt das Testen und Hoffen. Leider hat sich das 9.2er
SuSE wieder festgefressen. So ein Ärger. Jetzt bleibt nur noch eine Hoffnung. Ich habe noch
eine DVD von einem 10.1er SuSE von einem ct-Sonderheft rumliegen. Die DVD ist mir schon mal
positiv aufgefallen, wegen der ganzen Netzwerkprogramme/Serverdienste die da drauf zu finden sind.
Normalerweise sind auf Heft-DVDs nur Anwenderprogramme zu finden (Buuml;rokram).
Nicht lange rumreden. Ich habe dann die wichtigen Konfigurationsdaten und Scripte auf der Datenpartition
gesichert und kurzerhand das SuSE 10.1 installiert. Probleme gab es aber mit X-Windows. Bei der
Konfiguration hat der Monitor immer gemeldet, das ihm das Signal fehlt. Ursache war eine falsche
Einstellung im BIOS. Als Monitor darf man nur VGA aktivieren. Bei VGA+LCD wird die Ausgabe auf der
LCD-Schnittstelle auf dem Mainboard aktiviert und der Monitor bleibt dunkel. Danach gab es noch ein paar
Probleme mit der Fenstergröße. Wenn der Monitor nur den zentralen Teil der Seiten von
SaX2 anzeigt und man die Buttons nicht mehr erreicht, kann man die Konfiguration auch nicht
ändern. Zum Glück habe ich die alte xorg.conf gesichert. Also reinkopieren und läuft :-)
Zum Schluß noch eine Anmerkung ...
Bei den Boards lohnt sich kein Speicher über 512MByte. Der Prozessor kann wegen fehlender Performance
den größeren Speicher nicht wirklich nutzen. Außerdem sollte man nicht unbedingt KDE
laufen lassen. Bei mir habe ich fvwm2 im Einsatz. Fünfmal schneller als KDE. Nur das Konfigureren
ist lediglich über die Datei system.fvwmrc möglich. Also kein wirkliches Klicki-Bunti-System ;-)
Im Moment läft das 10.1er SuSE mit dem 1.05Test-Bios stabil. Die Zeit wird es zeigen, ob das
DMA-Problem gelöst ist. Irgendwann wird hier auch mal ein Bericht über das LAN-Party-System
stehen.
- - - - -
Es sind jetzt schon ein paar Tage ins Land gegangen. Ich habe den PC auch schon gut mit gleichzeitigen
Aktionen (4 tar-Archive gleichzeitig angelegt) geärgert. Bis jetzt läuft er absolut stabil.
Es sieht so aus, als ob die Probleme mit dem festfressen verschwunden sind.
Es ist aber ein anderes Problem aufgetaucht (zum Glück nicht bedrohlich für das System).
Bei SuSE 9.2 kann man z.B. mit tcpdump Daten vom Netzwerk mitlesen und die Paketdaten auf der
Konsole sehen. Man kann auch den Ausgabestrom in eine Datei umleiten. Diese Datei kann man dann
auch mit tail -f von einer anderen Konsole gleichzeitig und in Echtzeit lesen. Genau das geht aber
unter SuSE 10.1 nicht mehr. Die Speicherung der Daten von tcpdump geschieht nur blockweise. Erst wenn
wieder genug Daten im Schreibpuffer für diese Datei vorhanden sind, dann werden die Daten auch
wirklich in die Datei geschrieben und über tail angezeigt. Das ist für Scripte, die den
Datenverkehr analysieren sollen natürlich absolut tötlich.
Ich habe also im Moment folgendes Problem:
Ich lege mit
mkfifo /root/logpipe
eine named Pipe an und schreibe die mitgelesenen Netzwerkdaten mit
tcpdump -e -q -n -i eth0 ip >/root/logpipe
in diese Pipe. Mit einem Perlscript lese ich aus der Pipe und suche in den Paketdaten nach
doppelten IP-Adressen, ARP-Paketen, ...
Die Scripte sollen also zur Statistik, Management und Absicherung bei LAN-Partys helfen.
Das tun die Scripte aber nur, wenn man die Daten sofort weiterverarbeitet. Wenn die
Daten erst nach 15-20sec bei den Scripten ankommen, ist sowieso schon alles zu spät.
Ich habe schon alles mögliche (forken, Perl-interne Pipes, ...) ausprobiert. Bisher leider
ohne Erfolg. Wie kann ich tcpdump (oder der Shell) mitteilen, das die Daten sofort und ungepuffert
in die Pipe geschrieben werden sollen ???
Wer mir da weiterhelfen könnte ...
- - - - -
Manchmal lohnt es sich, etwas zu warten :-)
Gestern ist das neue Linux-Magazin 02/07 ins Haus geflattert. Auf Seite 114 steht, wie man mit
Perl ohne Umweg Pakete vom Netz mitlesen kann. Das Leben kann so einfach sein. Ich hoffe, es
funktioniert auch alles so einfach. Nicht das ich dann wieder kurz vor dem Ziel ausgebremst
werde. Mal sehn wie es weitergeht.