Debian 3.0 auf Epia M10000-N installieren

3.1 Neuen Kernel installieren

Für das Installieren eines passenderen Kernels gibt es zwei Möglichkeiten:

• Kompilieren und Installieren der Kernel-Version 2.4.22 aus Debian Testing
• Kompilieren eines speziell für Epia gepatchten Kernels 2.4.23

Zurück zum Inhalt

dpkg -i kernel-source-2.4.22_2.4.22-3_all.deb

cd /usr/src/
tar xvjf kernel-source-2.4.22.tar.bz2
cd kernel-source-2.4.22
make menuconfig

wget http://witch.westfalen.de/via/config.2.4.22.hexe.10

make-kpkg --revision=name.version kernel_image modules_image
cd ..
dpkg -i kernel-image-2.4.22_name.version_i386.deb

wget http://www.de.kernel.org/pub/linux/kernel/v2.4/linux-2.4.22.tar.bz2
wget http://www.de.kernel.org/pub/linux/kernel/v2.4/testing/old/patch-2.4.23-pre9.bz2
wget "http://www.alterself.com/~epia/files/epia_kernel/patch-2.4.23-pre9-epia1.gz"

tar -xvzf linux-2.4.22.tar.gz
gunzip patch-2.4.23-pre9-epia1.gz
bunzip2 patch-2.4.23-pre9.bz2

cd /usr/src/linux-2.4.22

patch -p1 --dry-run < ../patch-2.4.23-pre9
patch -p1 < ../patch-2.4.23-pre9
patch -p1 --dry-run < ../patch-2.4.23-pre9-epia1
patch -p1 < ../patch-2.4.23-pre9-epia1

cd /usr/src
rm -rf modules
tar -xvzf ../i2c.tar.gz
tar -xvzf ../lm-sensors.tar.gz

cd /usr/src
wget http://www.witch.westfalen.de/via/patch.lm-sensors-source.hexe.2
patch -p0 --dry-run < patch.lm-sensors-source.hexe.2

wget http://www.witch.westfalen.de/via/config.2.4.22.hexe.epia.1
oder 
wget http://www.witch.westfalen.de/via/config.2.4.22.hexe.epia.2
oder
wget http://www.witch.westfalen.de/via/config.2.4.22.hexe.epia.3

make menuconfig
make-kpkg --revision=hexe.epia.1 kernel-image modules-image
cd ..
dpkg -i kernel-image-2.4.23-pre9-epia1_name.epia.1_i386.deb
dpkg -i i2c-2.4.23-pre9-epia1_2.8.0-2+name.epia.1_i386.deb
dpkg -i lm-sensors-2.4.23-pre9-epia1_2.8.0-2+name.epia.1_i386.deb

wget http://www.witch.westfalen.de/via/config.2.4.22.hexe.epia.1

3.2 Xfree86

Um unter X eine bessere Bildschirmauflösung als 60 Hz zu erhalten, muß entweder das X gegen Xfree86 4.3.99 ausgewechselt werden oder als Workaround die Binärtreiber von Via von der beiliegenden CD installiert werden.

Auf der CD befindet sich im Unterverzeichnis Linux die Datei CLEXF40016.tgz Diese wird auf die Festpaltte kopiert, entpackt und anschließend die passenden Treiber für X in das Modul-Verzeichnis von X kopiert:

tar -xvzf CLEXF40016.tgz
cd CLEXF40016
cp -i RedHat/7.1/pentium/via_drv.o /usr/X11R6/lib/modules/drivers/
cp -i RedHat/7.1/pentium/libddmpeg.so /usr/X11R6/lib/

Wichtig ist, daß genau diese Treiber genommen werden, da die anderen nicht zum installierten Xfree86 passen.

Nun kann in /etc/X11 die XF86Config-4 editiert werden (also root oder mit sudo):

sudo vi /etc/X11/XF86Config-4

Der Abschnitt für die Grafikkarte sollte dann in etwa so aussehen:

Section "Device"
      Identifier      "Via VT8623 Apollo CLE266"
      Driver          "via"
      VideoRam        4000
      # Option                "TVOff"
EndSection

Im Abschnitt Screen muß dann natürlich die Grafikkarte auch eingetragen werden:

Device          "Via VT8623 Apollo CLE266"

Das direkte Editieren der XF86Config-4 ist entspricht nicht ganz dem normalen Vorgehen bei Debian. Deshalb sei hier davor gewarnt, daß ggf. mit dem nächsten dpkg-reconfigure die Einstellungen überschrieben werden. Es ist also zu empfehlen, von der richtigen Konfiguration eine Sicherheitskopie zu erstellen.

X sollte jetzt mit einer höheren Bildschirmfrequenz laufen. Nach dem Ausloggen wird man aber möglicherweise feststellen, daß man nicht mehr auf die Konsole kommt und die Tastatur nicht mehr reagiert, wenn X über einen der Display-Manager gestartet wird. Zugriff über ssh und killen der hängengebliebenen Prozesse ist aber möglich und gibt den Rechner wieder frei. Um dieses Problem zu vermeiden, bietet es sich an X mit startx zu starten. Ist das nicht möglich, weil der User kein Recht dazu hat, so kann man mit:

dpkg-reconfigure xserver-common

die Einstellungen anpassen.

X startet bei mir wegen Fehlermeldungen vom Via-Treiber sehr langsam. Das Problem habe ich noch nicht lösen können. Vermutlich kann man nach dem Besetitigen der Fehlermeldungen X wieder über einen Display-manager starten.

Hier die bei mir verbliebenen Fehlermeldungen:

(EE) via(0):  Couldn't open "/dev/video0"
(EE) via(0): Can't get through IOCTL to V4L
(EE) via(0): Can't set destroy surface flag 0 to V4L
...
(EE) via(0):  Couldn't open "/dev/video0"
(EE) via(0): Can't get through IOCTL to V4L
...
waiting for X server to shut down (EE) via(0):  Couldn't open "/dev/video0"
(EE) via(0): Can't get through IOCTL to V4L

Vielleicht findet ja einer der Leser eine Lösung und teilt sie mir mit.

Zurück zum Inhalt

3.4 USB

Die Nutzung von USB ist natürlich sehr individuell. Deshalb hier nur ein paar sehr allgemeine Hinweise.

• Im Kernel muß USB_UHCI aktiviert sein
• Bei Anbindung von Kameras u. a. die als Festplatten gemounted werden sollen, müssen SCSI, SCSI-Dummy usw. aktiviert sein.
• Für eine sehr alte Webcam und das QX3 benötogt man zusätzlich die CPIA-Treiber
• Ein Manager für PNP, z. B. usbmgr müssen installiert sein.

Ich habe zunächst mit apt-get den Usbmgr installiert und diesen anschließend ohne Purge durch hotplug ersetzt. Nachdem ich zunächst auf mein über die CPIA-Treiber aus dem Kernel angesprochenes Mikroskop zugreifen konnte, war das nach einem Reboot nicht mehr möglich, weil hotplug die CPIA-Module nicht richtig lud. Abhilfe konnte ich durch apt-get remove hotplug --purge und anschließendes Neuinstallieren von usbmgr und dessen Anpassung (Ergänzung der Vendor-Einträge) erreichen.

Für die Ergänzung von Vendor-Einträgen in /etc/usbmgr/usbmgr.conf kann man auf die Fehlermeldungen, die beim Einschalten des Gerätes erscheinen zurückgreifen. Welche Module geladen werden müssen, muß man anderweitig herausbekommen. Als Beispiel hier die beiden Einträge, die ich für den Betrieb meines QX3 und der Digi ergänzt habe:

# QX3 Mikroskop
vendor 0x813 product 0x1 module cpia , cpia_usb
# Coolpix 2500 [Nikon]
vendor 0x04b0 product 0x0108 module scsi_mod , sd_mod , usb-storage

Die Module müssen natürlich im Kernel oder als Modul vorhanden sein. Sonst können sie nicht geladen werden.

Bei Zugriff auf USB-Devices über usbdeffs muß, wenn der Kernel richtig konfiguriert wurde, folgende Zeile automatisch in /etc/mtab erscheinen:

/proc/bus/usb /proc/bus/usb usbdevfs rw 0 0

Um Kameras als SCSI-Festplatten ansprechen zu können, müssen diese zum Einen korrekt konfiguriert sein und zum anderen das Dateisystem im Kernel konfiguriert. Das Mounten sollte z. B. mit:

mount -t vfat /dev/sda1 /mnt

möglich sein. Ich selbst habe den Inhalt der Speicherkarte allerdings bis jetzt nur über ein passendes Lesegerät mit USB-Anschluß zu sehen bekommen.

Dieser Abschnitt wird zu gegebener Zeit erweitert

Zurück zum Inhalt

3.5 LM-Sensors und I2C

Der Zugriff auf die Sensoren und I2C ist mit dem Kernel 2.4.22 und den i2c- und lm-sensors-Paketen aus Debian 3.0 (Woody) nicht möglich.

Für die Installation habe ich aus der künftigen Debian-Distribution Source-Pakete geholt und Backports für Woody erstellt.

Die Backports können auf meinem Webserver heruntergeladen werden. Hier zunächst die beiden Source-Pakete, die für die Kernel-Erstellung benötigt werden:

wget http://www.witch.westfalen.de/via/i2c-source_2.8.0-2_all.deb
wget http://www.witch.westfalen.de/via/lm-sensors-source_2.8.0-2_all.deb
wget http://www.witch.westfalen.de/via/modules.epia.diff

Die beiden Pakete werden installiert und anschließend in den Kernel-Source ausgepackt und in den Kernel-Tree eingebaut:

sudo dpkg -i i2c-source_2.8.0-2_all.deb
sudo dpkg -i lm-sensors-source_2.8.0-2_all.deb
cd /usr/src/
rm -rf modules
tar -xvzf i2c.tar.gz
tar -xvzf lm-sensors.tar.gz
patch -p1 < modules.epia.diff

Anschließend geht es weiter mit der Kernel-Konfiguration und dem Erstellen von Kernel und Modulen.

Danach werden die zugehörigen Anwendungen installiert:

wget http://www.witch.westfalen.de/via/libsensors2_2.8.0-2_i386.deb
wget http://www.witch.westfalen.de/via/acpi_0.06-5_i386.deb
wget http://www.witch.westfalen.de/via/lm-sensors_2.8.0-2_i386.deb
wget http://www.witch.westfalen.de/via/sensord_2.8.0-2_i386.deb
wget http://www.witch.westfalen.de/via/sensors.conf

Installation erfolgt wieder mit sudo dpkg -i  paket.deb. Eine Konfigruation, die für alle Epia M- Mainboards passen sollte, kann anschließend installiert werden:

sudo mv /etc/sensors.conf /etc/sensors.conf.alt
sudo cp sensors.conf /etc/sensors.conf

Mit dem Aufruf von sensors können nach einem Reboot die sensor-Werte ausgelesen werden.

Meine sensors.conf habe ich nach gründlichem Studieren der von Via bereitgestellten Informationen zusammengestellt. Die Umrechnungswerte für Spannungen und Temperatur stammen von Via. Überprüft habe ich die Ergebnisse durch vergleich mit den Bios-Werten und Umrechnunung aller von I2C zur Verfügung gestellten Umrechnugnswerte. Leider gab es keine Eindeutige Angabe zur Zuordnung. Die im Netz vorgefundenen Konfigurationen anderer User ergaben aber bei fast allen Werten erhebliche Abweichungen von den Ausgaben im Bios.

Wer die Werte, die sensors mit obiger Konfiguration ausgibt, mit den Bios-Werten vergleichen will, muß berücksichtigen, daß bei Anspringen anderer Teile im Bios vor dem Blick auf die Werte ggf. zu einer erheblichen Erhöhung der CPU-Temperatur führt. Liegt die CPU-Temperatur im Bios bei Werten von weit über 30 Grad, so kann diese beim Booten um 1-2 Grand sinken, wenn man sofort nach dem Booten die Sensorwerte abfragt.

Beispielausgaben von sensors:

vt1211-isa-6000
Adapter: ISA adapter
Algorithm: ISA algorithm
+5V:       +4.88 V  (min =  +4.75 V, max =  +5.25 V)   
VCore1:    +1.38 V  (min =  +1.33 V, max =  +1.46 V)   
+3.3V:     +3.26 V  (min =  +3.12 V, max =  +3.45 V)   
+12V:     +11.78 V  (min = +11.36 V, max = +12.55 V)   
System:      0 RPM  (min = 3996 RPM, div = 2)          
CPU:      6425 RPM  (min = 3996 RPM, div = 2)          
CPU:       +58.3°C  (limit =  +65°C, hysteresis =  +60°C) 
vid:       +1.85 V

Bei dieser Abfrage war der Rechner stark beschäftigt. Bis auf die CPU-Spannung VCore1 sind alle Spannungswerte leicht abgefallen. Das läßt auf einen relativ zum Ruhezustand höheren Stromverbrauch schließen. Das Netzteil liefert jedoch offenbar auch unter Last noch ausreichend hohe Spannungen, die innerhalb der von Via angegebenen und von mir übernommenen Grenzwerte liegt. Der Gehäuse-Lüfter ist abgeklemmt und der zugehörige Sensor zeigt deshalb nichts an. Werden die Grenzwerte für Spannungen und Temperatur unter- bzw. überschritten, so wird ein Alarm angezeigt (hier nicht der Fall). Der zweite Wert bei der CPU-Temperatur gibt den Wert für die Rückkehr aus dem Alarmzustand an.

Schon wenige Sekunden nach Beendigung der starken Belastung sind die Werte alle wieder normal oder relativ normal:

+5V:       +4.98 V  (min =  +4.75 V, max =  +5.25 V)   
VCore1:    +1.37 V  (min =  +1.33 V, max =  +1.46 V)   
+3.3V:     +3.28 V  (min =  +3.12 V, max =  +3.45 V)   
+12V:     +11.90 V  (min = +11.36 V, max = +12.55 V)   
System:      0 RPM  (min = 3996 RPM, div = 2)          
CPU:      6488 RPM  (min = 3996 RPM, div = 2)          
CPU:       +36.0°C  (limit =  +65°C, hysteresis =  +60°C) 

Sensorwerte können auch direkt ausgelesen und von Programmen für Benachrichtigungen per Mail oder andere Events benutzt werden.

Der CPU-Lüfter des M10000-N sollte eigentlich regelbar sein. Allerdings führt das Füllen des zugehörigen Registers (pwm2, Reg. 2) bisher nicht zum Erfolg. Die Drehzahl bleibt nach dem Einschalten auch bei Setzen des Drehzahlwertes bei mir immer auf dem Maximum stehen, weil der Registerwert sich nicht ändern läßt. Es ist möglich, daß Änderungen der Drehzahl nur über ACPI möglich wären.

Das Ändern der uhc_config mit set config 12 funktioniert bei mir nicht. Im Register bleibt die (korrekte) "3" stehen. Mit dem Setzen der Konfigurationsbits kann man Register des vt1211 auf Temperaturanzeige Umstellen, wenn Temperatur-Sensoren angeschlossen sind. Im Falle des M-Chassis werden die entsprechenden Register jedoch für nichts oder die Spannungen genutzt.

Zurück zum Inhalt

3. 6 Sound

Mit meinen Einstellungen im Kernel hat man bisher marginale Sound-Unterstürtzung. Wav-Dateien können mit cat über das Audio-Device ausgegeben werden.

Generell zu beachten: Für Video, Sound usw. muß der User der jeweiligen Gruppe (audio, video usw.) angehören. Die Rechte an den Devices sollte man nicht statt dessen auf ändern.

Zurück zum Inhalt

4.1 APM

Mit den Kernel-Konfigurationen, die ich verwendet habe, steht für den normalen 2.4.22-Kernel nur das Ausschalten mittels des Befehls poweroff über APM zur Verfügung. Der Rehner macht dann einen normalen Shutdown und anschließend geht der Rechner aus.

Hier die Teile aus der von mir verwendeten Kernel-Konfiguration:

CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
CONFIG_APM_DO_ENABLE=y
CONFIG_APM_CPU_IDLE=y
# CONFIG_APM_DISPLAY_BLANK is not set
CONFIG_APM_RTC_IS_GMT=y
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

Wenn ACPI vorbereitet ist, ist diese Zeile zusätzlich wichtig:

CONFIG_ACPI_OFF=y

4.2 ACPI

Bei der oben genannten Konfiguration für den speziellen Epia-Kernel 2.4.23 kann auch ACPI genutzt werden. Allerdings ist die Nutzung sehr eingeschränkt. Um ACPI nutzen zu können, muß zusätzlich das Paket apcid installiert werden.

Folgende Funktionen habe ich bisher nutzen können:

• Herunterfahren und Ausschalten des Computers mit dem Ein-/Aussschalter am Computergehäuse
• Möglichkeit, den Computer über Wake-on-LAN wieder zu starten

Meine aktuellen Kernel-Einstellungen für den gepatchten Epia Kernel 2.4.23:

# ACPI Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_BUS=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_DEBUG=y
# CONFIG_ACPI_RELAXED_AML is not set

Im Bios ist folgendes unter Power Management Setup konfiguriert:

• ACPI Function: Enabled
• ACPI Suspend Type: Beliebig (z. B. S1&S3)
• HDD Power down: Beliebige Zeit, z. B. 15 Minuten
• Power Management Timer: Beliebige Zeit
• Video Off Option: Always on
• Power Off by PWRBTN: Instant Off (shutdown macht das OS)
• Run VGA Bios if S3 resume: Auto
• AC Loss Auto restart: Beliebig

Was den Monitor (Video) betrifft, bin ich mir noch nicht sicher, was da genau was macht. Mein Monitor schaltet sich (mindestens im X) automatisch in den Schlafmodus. Wichtig sind die Einstellungen für den PWRPTN (Paower Button am Gehäuse) und ACPI Function (enabled = eingeschaltet).

Wake-on-LAN kann bei Nutzung der internen Ethernet-Schnittstelle im Untermenü Peripherial Activities aktiviert werden.

Schaltet man den Computer unter Nutzung der ACPI-Funktionen ab, kann er über verschiedene Aktivitäten wieder aufgeweckt werden:

• Betätigen der Tastatur
• Betätigen der Maus (eventuell nur linke Maustaste
• Senden eines Wakeup-Paketes über das LAN

Für letzteres habe ich auf dem anderen Rechner wakeup 1.3 installiert. Im Gegensatz zum bei Viarena geposteten Python-Script kann es auch auf einem Mac mit OS X ohne Änderungen kompiliert und installiert werden. In der Konfiguration kann man für jeden Rechner ein Alias für die MAC-Adresse (Hardware-Adresse des LAN-Interfaces) anlegen. Die Mac-Adresse wird vorher bei eingeschaltetem Rechner mit arp -a ermittelt. Wenn der Rechner, der der weckende sein soll, mehrere Ethernet-Interfaces hat, muß man zusätzlich die Broadcast-Adresse mit angeben (z. B. 10.0.0.255).

Mit swsup soll es möglich sein, den Speicherinhalt auf Platte zu schreiben, wenn man den Kernel entsprechend patched. Das habe ich nicht ausprobiert. Ein Suspend to RAM mittels S3 - echo 3 > /proc/ascpi/sleep - ist nicht möglich und S1, mit dem die CPU in den Schlafmodus gehen soll, führt bei mir zum Einfrieren des Rechners und gleichzeitigem Flackern der Betriebsdiode am Rechner (ausprobieren nicht empfohlen).

Infos zum Entwicklungsstand von ACPI gibt es unter http://acpi.sourceforge.net.

Zurück zum Inhalt