#debian.de - Frequently Asked Questions
Kapitel 4 - Konfiguration/Hardware

4.1 3D-Beschleunigung mit NVidia-Grafikkarten unter Debian einrichten

Eine weitere (englische) Beschreibung findet sich unter http://home.comcast.net/~andrex/Debian-nVidia/installation.html.

Für die allgemeine Konfiguration der Hardware und Installation der 3D-Software (z.B. Action-Spielen) gelten die Howtos, die Sie im Netz finden. Folgende Beschreibung ist für die Installation der NVidia-Treiber auf Debian angepasst und sollte statt der 0815-Anleitung im NVidia-FAQ genommen werden. Ich gehe davon aus, dass XFree-4.1.x einsatzbereit installiert ist und der "nv" Treiber läuft. Ähnliches gilt für die Kernel-Version, es sollte ein aktueller 2.6.x-Kernel sein (oder 2.4.x).

I. Prüfen, ob non-free in sources.list steht:

     $ grep non-free /etc/apt/sources.list
     deb http://ftp.at.debian.org/debian sarge main contrib non-free

Sollte grep keine Ausgabe liefern, so ist non-free nicht eingetragen. Editieren Sie dann die sources.list und fügen Sie non-free dem Eintrag zu Sarge wie oben gezeigt hinzu. Nach dem Speichern nicht vergessen aptitude update aufzurufen.

IIa. Für Sarge/Sid:

     aptitude install module-assistant nvidia-glx
     module-assistant auto-install nvidia-kernel
     (oder für Schreibfaule: m-a a-i nvidia)

Mit ein bisschen Glück sind alle Pakete danach installiert (dann mit Schritt VIII weitermachen). Den Hinweisen von module-assistant folgen. Wenn die Kernel-Quellen nicht vorhanden sind (da Kernel von Debian), dann erstmal "m-a prepare" ausführen.

III. Etwaige Glide-Reste entsorgen

     $ aptitude remove '.*glide.*'

IV. Anschließend die Datei /etc/X11/XF86Config-4 editieren, die Zeile mit dri auskommentieren, "nv" durch "nvidia" ersetzen. Bei Problemen in der Sektion "Screen" diese Zeile hinzufügen:

     Option  "NvAgp" "3"

Außerdem sollte man überprüfen, ob in der Sektion "Module" auch der Eintrag

     Load "glx"

vorkommt. Bei manchen Vorinstallationen fehlt er und muss per Hand nachgetragen werden. Außerdem muss der "dri"-Treiber auskommentiert werden, dieser wird nicht benötigt und kommt Nvidia-Modulen in die Quere.

     #Load "dri"

Achtung, je nach Chipsatz muss man den Kernel-AGPGART verwenden und die NvAGP-Option verändern. Genaueres steht in der Datei README.Debian (bei nvidia-glx) bzw. dort genannten FAQs. EOF -- Autor: Zomb ;

4.2 Brenner einrichten

Brenner besitzen heutzutage praktisch alle die IDE/ATAPI-Schnittstelle. Auf SCSI wird hird nicht nähher eingegangen, dies ist in den cdrecord-Docs ausreichend dokumentiert.

Aufgrund der Ideologie-Kriege zw. dem cdrecord-Autor und den Kernel-Entwicklern bzw. Benutzern gibt es mehrere Methoden, um Brenner via IDE anzusprechen. Genau genommen handelt es sich bei ATAPI um eine Transport-Methode für SCSI-Befehle über IDE. Jedoch sind einige SCSI-spezifischen Dinge bei ATAPI nicht praktisch, so zum Beispiel verwendung von kryptischen ID-Zahlen, um Geräte auszuwählen.

Vor einigen Jahren wurde die vom cdrecord-Autor proklamierte "ide-scsi"-Methode empfohlen, mit der man mit Hilfe eines Kernel-Moduls IDE-Laufwerke auf SCSI-Namen abgebildet hat. Dies war jedoch umständlich, ausserdem wurde das ide-scsi-Modul nicht ordentlich gepflegt. Mit etwas Glück kann die Methode aber noch mit heutigen Kernel-Versionen verwendet werden, siehe cdrecord-Doku für Details.

Die heute übliche Methode spricht die Laufwerke direkt an. Mit Kernel 2.4 geschieht dies mit dem Parameter: dev=ATAPI:/dev/hdX, mit Kernel 2.6 geht ebenfalls dev=/dev/hdX, wobei eine alternative Zugriffsmethode verwendet wird. Die letzte Methode ist vorzuziehen, weil DMA besser unterstützt wird als mit ATAPI:. Und wer unbedingt SCSI-ID-Nummern sehen will, kann mit Hilfe von "-scanbus dev=ATAPI:" bzw. ATA: (für den neuen Treiber) simulierte Nummern erfragen und sie mit dev=ATA(PI):x,y,z verwenden.

Zusammenfassung:

Brennen: cdrecord image.iso dev=/dev/hdc speed=12 (für Kernel 2.6) Diese Optionen kann man als Default in der Datei /etc/default/cdrecord eintragen, siehe cdrecord-Manpage für Details.

     CDR_DEVICE=cdrw
     cdrw=/dev/hdc        12       16m
     # alt, 2.4
     #cdrw=ATAPI:/dev/hdc        12       16m

Testen ggf. mit "cdrecord -v -toc".

Anhang) Software-Konfiguration:

Da gibt es einige Programme. xcdroast, gcombust und gtoaster sind ganz nett. Eine Übersicht von verfügbaren Frontends kriegt man z.B. mit:

       apt-cache search cdrecord
       apt-cache search eroast
       apt-cache search gtoast
       apt-cache search cdrdao

4.3 USB-Maus einrichten

Am einfachsten geht das unter Woody mit einem mitgelieferten Kernel (oder einem eigenen, bei dem USB- und "input"-Treiber dabei sind). Andernfalls siehe Hinweise unten.

Howto:

• als root "modconf" starten

• in der Sektion "usb" usb-uhci und/oder usb-ohci laden

• in der Sektion "misc" (oder ähnlich, je nach Kernel) den Treiber mousedev laden

• Falls Sie hotswap benutzen möchten, können Sie statt des letzten Schrittes das Paket "hotplug" installieren, das Mouse/Tastatur/Drucker/...-Treiber bei Bedarf nachlädt und entlädt.

• Anschließend die Maus ganz normal als PS/2 Maus konfigurieren, das Mouse-Device ist dabei /dev/input/mice, die Protokolle sind (für X) PS/2 (einfachste Mäuse); MouseManPS/2 (Logitech); IMPS/2, ExplorerPS/2 (Microsoft); ThinkingMousePS/2, NetScrollPS/2, NetMousePS/2, GlidePointPS/2 (diverse andere). Siehe Abschnitt zur X-Konfiguration weiter unten in dieser FAQ. Mal wieder gilt es zu beachten, dass GPM oft mit X kollidiert, d.h. kein gemeinsamer Zugriff möglich ist und "lustige" Effekte bei Maus-Bewegungen entstehen können. I.d.R. muss man gpm deinstallieren oder ihn im Repeater-Modus laufen lassen (was unter Umständen zusätzliche Funktionen einer Maus unbrauchbar macht).

Bei älteren Woody's und Potato gibt es die nötigen Device-Nodes noch nicht. Lösung (für Woody):

        aptitude install makedev
        cd /dev
        MAKEDEV usb input

EOF -- Autor: Zomb ;

4.4 UltraDMA aktivieren

ACHTUNG: VERWENDUNG VON ULTRADMA UND MULTIWORD DMA KANN ZU DATENVERLUST UND -BESCHÄDIGUNG FÜHREN. Es sind einige IDE-Geräte im Umlauf, die in diesen Modi stillschweigend Datenfehler produzieren.

Bei der Aktivierung von DMA gibt es prinzipiell zwei Dinge zu beachten: Erstens, ob DMA beim Booten automatisch aktiviert wird (von der Kernel-Konfiguration abhängig) und zweitens, ob der bestmögliche DMA-Modus ausgewählt ist.

Der erste Punkt ist weniger kritisch. Fast alle aktuellen Platten kommen mit DMA klar. Es gibt aber schwarze Schafe, die sich als (U)DMA-kompatibel ausgeben, aber in diesem Modus Datenfehler produzieren. Im Zweifelsfall sollte man die Finger von DMA lassen.

Beim zweiten Punkt sollte man sich i.d.R. auf die Auswahl verlassen, die das BIOS gemacht hat. Unter Umständen kann man diese Auswahl übergehen (hdparms -X-Parameter), aber dies ist sehr riskant. Wählt man etwas aus, was nicht vom Kontroller oder von der Platte unterstützt wird, so sind Datenfehler fast vorprogrammiert.

Als erstes brauchst du einen Kernel, der deinen Chipsatz optimal unterstützt. Für Onboard-Controller bis zur ersten Athlon/P3-Generation sollten die Treiber im 2.2er Kernel ausreichen. Für neuere braucht man Kernel 2.4 oder gepatchten 2.2, z.B. aus dem kernel-image-2.2.20-udma100-ext3 Paket (in Woody).

Zum aktivieren installiert man hdparm:

     aptitude install hdparm hwtools

Dann erstmal die Hardware/Treiber überprüfen:

     $ hdparm /dev/hda
     
     /dev/hda:
      multcount    =  0 (off)
      IO_support   =  0 (default 16-bit)
      unmaskirq    =  1 (on)
      using_dma    =  0 (off)
      keepsettings =  0 (off)
      readonly     =  0 (off)
      readahead    =  8 (on)
      geometry     = 9964/255/63, sectors = 160086528, start = 0

Wie man sieht, läuft die Platte nicht optimal. Multicount ist aus (aka HDD-Block-Mode, 16 Blocks sind okay), 16-bit IO wird verwendet (32 sind besser), und DMA ist aus. Diese Einstellungen werden jetzt mit hdparm verbessert (siehe hdparm-Manpage).

     $ hdparm -m 16 -d 1 -c 3 /dev/hda
     
     /dev/hda:
      setting 32-bit IO_support flag to 3
      setting multcount to 16
      setting using_dma to 1 (on)
      multcount    = 16 (on)
      IO_support   =  3 (32-bit w/sync)
      using_dma    =  1 (on)

Sieht schon mal besser aus. Nun überprüfen wir, ob auch der beste UDMA-Modus verwendet wird. Auf aktuellen Boards ist das kein Thema und sie können den folgenden Absatz überspringen. Meinem älteren BIOS ist aber nicht zu trauen.

     $ hdparm -i /dev/hda
     
     /dev/hda:
     
      Model=Maxtor 4D080H4, FwRev=DAH017K0, SerialNo=D40BKWHE
      Config={ Fixed }
      RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
      BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
      CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=160086528
      IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
      PIO modes: pio0 pio1 pio2 pio3 pio4
      DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5
      AdvancedPM=yes: disabled (255) WriteCache=enabled
      Drive Supports : ATA/ATAPI-6 T13 1410D revision 0 : ATA-1 ATA-2 ATA-3 ATA-4 ATA-5 ATA-6

Die aktuell ausgewählten Modi wären normalerweise mit * markiert. Nur in meinem Fall eben nicht, da älteres BIOS. Darum schlage ich jetzt in den Mainboard- und Festplatten-Specs nach, und beobachte die Kernel-Meldungen beim Booten (Oct 31 11:43:03 zombie kernel: VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1). Also wähle ich UDMA66 aus, mit dem Parameter -X68, aus dieser Tabelle.

     hdparm -X68 /dev/hda
     
     /dev/hda:
      setting xfermode to 68 (UltraDMA mode4)

VORSICHT: Einige Modi werden zwar von der Festplatte unterstützt, aber nicht vom Chipsatz (oder andersrum) - diese Modi sollten NICHT verwendet werden. Ebenso wenn das Datenkabel nicht für den schnellen Datenmodus ausgelegt ist, oder die Festplatte auf der schwarzen Liste steht, darf KEIN DMA-Modus aktiviert werden.

Auf einen Punkt gebracht:

/etc/init.d/hwtools editieren, dort den (extra vorgesehenen) Abschnitt für hdparm finden und so etwas eintragen:

     # hdparm optimization
     # Switches on interrupts during transfers and does multi sector transfers
     if command -v hdparm >/dev/null 2>&1; then
     # Maxtor-Platte, UDMA66
        /sbin/hdparm -c3 -d1 -m16 -X68 -S 200 /dev/hda &
     # alte IBM-Platte, UDMA66
        /sbin/hdparm -c3 -d1 -m16 -X68 -S 200 /dev/hdb &
     # TEAC-Cdrom, UDMA33
        /sbin/hdparm -d1 -X64 /dev/hdd
     fi

Die Werte an die eigene Platte anpassen, siehe hdparm-Manpage.

4.5 <, | und > gehen nicht nach X11-Upgrade

Sollte die "< > |"-Taste unter X nicht funktionieren, dann liegt das meistens daran, dass in der XF86Config eine falsche Tastenzahl eingestellt ist. In der Datei /etc/X11/XF86Config-4 könnte bei der "Keyboard"-Section folgendes stehen:

     Section "InputDevice"
     Identifier      "Generic Keyboard"
     	Driver          "keyboard"
     	Option          "CoreKeyboard"
     	Option          "XkbRules"      "xfree86"
     	Option          "XkbModel"      "pc105"
     	Option          "XkbLayout"     "de"
     EndSection

Die "XkbModel"-Option muss auf "pc105" (für deutsche Tastaturen mit Windowstasten) bzw. "pc102" (ohne Windowstasten) gesetzt sein, damit diese Taste funktioniert.

Bei manchen GNOME-Installationen wird ebenfalls eine falsche Einstellung beim Start vorgenommen. Sollten Sie GNOME verwenden und die obige Lösung nicht hilfreich sein, suchen Sie in der GNOME-Konfiguration nach Tastatureinstellungen.

#debian.de - Frequently Asked Questions