Re: irq routing conflict - einige varianten
Gruesse!
* Christoph Klein <smxag@yahoo.de> 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
Reply to: