Gruesse!
* Christoph Klein <[EMAIL PROTECTED]> schrieb am [13.09.04 15:46]:
> > Wie hast du den Kernel kompiliert? Debian-konform mit make-kpkg oder
> > per Hand (mit make ...)?
>
> ich habe ihn �ber make kompiliert und dann die arch/i386/boot/bzImage als
> Kernelimage genommen, jeweils dann ins /boot Verzeichnis kopiert, mit lilo
> korrekt verkn�pft und lilo dann auch ausgef�hrt.
> Die Module gewohnterweise mit make modules und danach make modules_install.
> Die Debian Variante mit make-kpkg scheint mir irgendwie unn�tig kompliziert
> zu sein ;-)
Glaube mir, ist sie nicht. Wenn du dich irgendwann mal etwas damit
besch�ftigen solltest wirst du mir recht geben. Gerade jetzt in deinem
Fall, wo du mit unterschiedlichen Konfigurationen experimentieren mu�t.
> hmm... also ich habe hier am Windows-PC mit neuem Asus SK8V im Ger�temanager
> IRQs bis 21, das w�re eine ersehnte Erkl�rung daf�r, danke :-)
>
> Soweit ich das nun verstanden habe, bedeutet ACPI unter anderem, dass es
> beispielsweise
> egal ist, welche IRQs das Bios den Ger�ten zuordnet, das Betriebssystem kann
> dieses dann
> selbst ggf. anders erledigen, unabh�ngig vom Bios.
> Inwiefern steht APIC damit im Zusammenhang ?
Das *ist* APIC. ACPI (beachte die Buchstabenandordnung) ist f�r
Power-Management zust�ndig.
> Abgesehen von APIC - funktioniert IRQ _sharing_ selbst andererseits nur,
> wenn ACPI vom Kernel unterst�tzt wird ?
Ich bin nicht der Hardware-Experte, aber IRQ-Sharing ist reine Sache
des BIOSes bzw. des PCI-Busses. Unabh�ngig von A*PI*C
[Kernel-Config...]
> > Ist ok, dein BIOS ist IMHO nicht ACPI-f�hig.
>
> hmm... bedeutet das, dass auch kein IRQ sharing m�glich ist ?
Nein, A*CP*I ist Power-Management.
> > > # Bus options (PCI, PCMCIA, EISA, MCA, ISA)
> > > #
> > > CONFIG_PCI=y
[PCI-Einstellungen...]
Bei Einstellungen, die unklar sind, meinte ich da� du da besser die
Vorgaben ("If you don't know what this is, then say yes/no") nimmst.
[Logfile...]
>
> > > Sep 12 15:49:17 server kernel: Cannot find map file.
Trotzdem geh�rt f�r mich die System.map zum jeweiligen Kernel.
> nun, so ein �hnliches Problem hatte ich ja mit der realtek-karte ( 8139too
> wurde nicht geladen, dmfe schon,
> de4x5 probiert (karte ausgebaut)), aber dann fand ich heraus, dass es neben
> der /etc/modules.conf und der
> /etc/modprobe.conf eine weitere datei gibt - /etc/modules. Darin stand dmfe
> und de4x5, das habe ich soweit
> hinreichend ge�ndert/angepasst, dann war das Problem gel�st.
>
> Testweise lie� ich die Datei /etc/modules mal komplett leer, um zu testen,
> ob der Kernel dann dmfe automatisch l�dt - tat er nicht.
Die /etc/modules.conf fasst man nicht an. Das steht auch am Anfang der
Datei. Diese wird jedesmal nach Modul-�nderung �berschrieben.
Debian-like ist: Module, die beim Starten gebraucht werden, werden in
die /etc/modules eingetragen. Optionen zu den Modulen in die jeweiligen
Files unter /etc/modutils. Der Befehl update-modules generiert dann die
/etc/modules.conf. Eine /etc/modprobe.conf habe ich hier nicht, ist
aber vielleicht eine Spezialit�t des 2.6.x-er Kernels.
> > > Sep 12 15:49:17 server kernel: ACPI disabled because your bios is from
> 98
> > > and too old
> > > Sep 12 15:49:17 server kernel: You can enable it with acpi=force
> >
> > Ist klar, oder?
>
> jo, welche Anforderungen stellt denn das ACPI des Kernels an das Bios ?
> bzw. gibt es eine Art Richtwert, ab welcher Mainboardgeneration
> (penium1/p2/p3/p4/k5/k6/athlon(k7)/k8) es funktioniert ?
Keine wirkliche Ahnung.
> hmm - dh die Meldung:
> > Sep 12 15:49:17 server kernel: Found and enabled local APIC!
> bedeutet nur, dass der Kernel APIC aktiviert hat, aber nicht, dass es auch
> funktioniert in Form der Interaktion mit der APIC Hardware?
Deshalb IMHO *local* APIC des Kernels. Da das dann eine einseitige
Richtung ist k�nnte ich mir vorstellen, das es da zu Problemen kommen
kann-
[neues Logile...]
> also die APIC Sache ist nun weg, doch beide IRQ routing conflicts existieren
> noch.
>
> Sep 13 14:54:00 server kernel: BIOS-e820: 000000000bfe0000 -
> 000000000bff8000 (ACPI data)
> Sep 13 14:54:00 server kernel: BIOS-e820: 000000000bff8000 -
> 000000000c000000 (ACPI NVS)
>
> K�nnte das bedeuten, dass ACPI auch seitens des Bios doch verf�gbar ist ?
> :-)
> wenn ja, beeinflusst das die M�glichkeit IRQ sharing zu aktivieren ?
Keine wirkliche Ahnung. Schau ins Mainboard-Handbuch oder Datenblatt.
IRQ-Sharing hat mit A*CP*I nichts zu tun.
> Einige Dinge sind dabei auch seltsam:
>
> Sep 13 14:54:00 server kernel: serio: i8042 AUX port at 0x60,0x64 irq 12
Deine PS/2-Tastatur/PS/2-Maus bzw. der PS/2-Port. Standard ist IRQ 12.
> es scheint hier noch etwas auf irq12 zu sein. in der bios-tabelle wird es
> aber nicht angezeigt - in /proc/interrupts auch nicht:
>
> CPU0
> 0: 1325051 XT-PIC timer
> 2: 0 XT-PIC cascade
> 9: 34 XT-PIC HFC PCI
> 10: 1 XT-PIC HFC PCI
> 11: 531 XT-PIC eth0
> 12: 1709 XT-PIC eth1
> 14: 5043 XT-PIC ide0
> 15: 13 XT-PIC ide1
> NMI: 0
> ERR: 2
>
Nein, ist normal. Du hast halt prinzipiell nur eine beschr�nkte Anzahl
freier IRQs, normalerweise 2/9, 5, 10, 11.
3/4 sind normalerweise die seriellen Schnittstellen (COM1/2)
7 der Druckerport (LPT)
12 der PS/2 Port (Maus-Tastur)
14/15 die IDE-Ports (also IDE0, IDE1)
Bei entsprechend vielen Karten bzw. OnBoard-Hardware gehen dir
irgendwann die Freien IRQs aus. Dann setzt je nach Board/BIOS und der
Komponente entweder IPQ-sharing ein oder die Komponente funktioniert
nicht.
Abhelfen kann man, indem man evtl. nicht ben�tigte IRQs freimacht. Z.B.
wenn man kein Modem/serielle Maus benutzt COM1/COM2 abschalten. Oder
den LPT-Port, wenn kein Drucker dran ist. Keine PS/2 Maus/Tastur? Dann
PS/2 abschalten. Keine Festplatte/CDRom am zweiten IDE-Controller (IRQ
15). Dann abschalten. Das Abschalten geschieht im BIOS.
> unverst�ndlich ist auch die ausgabe von lsmod:
>
> Module Size Used by
> hfcpci 26784 0
> mISDN_dsp 194176 0
> l3udss1 32992 0
> mISDN_l2 37280 0
> mISDN_l1 9344 0
> mISDN_core 67200 5 hfcpci,mISDN_dsp,l3udss1,mISDN_l2,mISDN_l1
> ppp_async 9152 1
> crc_ccitt 2016 1 ppp_async
> ppp_generic 24684 5 ppp_async
> slhc 6272 1 ppp_generic
> 8139too 19392 0
> dmfe 17500 0
>
>
> dmfe und 8139too sind nicht "benutzt" - also used by "0", sie funktionieren
> aber zweifellos ....
> liegt das vermutlich am lsmod, das zu alt ist, oder kann das andere gr�nde
> haben ?
Ist normal, der useb-by-Z�hler gibt nur an, wie oft ein Modul von
anderen benutzt wird.
Zu den irq-routing Meldungen: Meiner Meinung nach sind das keine
Fehler- sondern Info/Warn-Meldungen. Wenn die Komponente am Ende mit
den Werten wie sie /proc/interrupts ausgibt l�uft, ist aller ok.
Nur bei Nichtfunktionieren w�rde ich diese Warnungen beachten.
Wie gesagt, im BIOS evtl. IRQs freimachen durch Abschalten und z.B. die
ISDN-Karten ausbauen.
Funktionieren dann beide Netzwerk-Karten?
Und: siehst du mittlerweile mit modconf deine Module deines Kernels?
> jo, vielen Dank f�r deine Hilfe :-)
Da ja nur wir beide in diesem Thread schreiben und das ganze eigentlich
nichts mit Debian zu tun hat w�rde ich vorschlagen, weitere Mails per
PM zu schreiben.
> mfg christoph
Gru�
Gerhard
