Re: irq routing conflict - einige varianten
hallo liste,
> Aber klar, kein Verdrücken ;-)
einverstanden, also gehts hier weiter :-)
> Das *ist* APIC. ACPI (beachte die Buchstabenandordnung) ist für
> Power-Management zuständig.
das war eigentlich das, was mich etwas durcheinander brachte, also ACPI
_nur_
powermanagement
> Ich bin nicht der Hardware-Experte, aber IRQ-Sharing ist reine Sache
> des BIOSes bzw. des PCI-Busses. Unabhängig von A*PI*C
hmm würde das dann bedeuten, dass, wenn das bios/pcibus die irqs nicht
shared, das betriebssystem es auch nicht machen kann ?
außer es kann mit APIC die interrupts neu verteilen und ggf. auch sharen,
wenn es die hardware unterstützt ?
> Trotzdem gehört für mich die System.map zum jeweiligen Kernel.
nun, das dachte ich mir auch des öfteren beim bf2.4 kernel, bei dem ja auch
eine dabei ist.
bei den selbstkompilierten weiß ich nicht, wo man die jeweilige datei
herbekommt bzw. zu was sie überhaupt gut ist;
der kernel und die module funktionieren ja auch so ;-)
> Die /etc/modules.conf fasst man nicht an. Das steht auch am Anfang der
> Datei. Diese wird jedesmal nach Modul-Änderung überschrieben.
jo, das hatte ich gelesen - nur aus ratlosigkeit habe ich es halt in allen
dateien probiert, welche irgendetwas mit module laden zu tun hatten.
> 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.
danke für die info, endlich fällt mal etwas licht ins dunkel, der bedeutung
der restlichen mod* dateien ;-)
> Eine /etc/modprobe.conf habe ich hier nicht, ist
> aber vielleicht eine Spezialität des 2.6.x-er Kernels.
jo, ab 2.5.x glaube ich wird die modules.conf nicht mehr verwendet,
stattdessen die modprobe.conf, hat ein leicht
abgewandeltes format (manpage), es gibt aber ein script, welches bei den
module-init-tools für 2.6 mitgeliefert wird,
generate-modprobe.conf oder ähnlich heißt es, welche die alte modules.conf
konvertiert.
statt modutils wird dann das verzeichnis modprobe.d (auch unter /etc )
verwendet....
> 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-
okay, ist nun ja abgeschaltet - also eine fehlerquelle weniger....
> > 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.
hmm ok, ich schau mal ob ich etwas handbuch-mäßiges auftreiben kann, hab die
hardware von nem
bekannten bekommen - keinerlei zubehör ;-)
> Nein, ist normal. Du hast halt prinzipiell nur eine beschränkte Anzahl
> freier IRQs, normalerweise 2/9, 5, 10, 11.
> [...]
> 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.
ok, ich versuche mal die abschalt-methode - falls das nicht zum erfolg
führt, müsste man aber versuchen IRQ sharing zu aktivieren.
wenn nun ACPI nichts mir IRQ-sharing zu tun hat, also auch dessen
aktivierung im kernel nutzlos ist - wie aktiviert man IRQ-sharing dann ?
> 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.
nun, die netzwerkkarten gehen ja, nur die isdn karten funktionieren nicht -
was aber auch an mISDN oder der pbx liegen kann,
also in /proc/interrupts sind sie zu finden; module (zwar auch mit irq
routing conflict) sind geladen.....
die pbx bringt während sie versucht zu starten nur folgende meldungen:
server:~# pbx state
** PBX4Linux ** Version 2.5 (August 2004)
debug_init: using stdout for debug log
debug_init: using stderr for warning log
debug_init: using stderr for error log
debug_init: debug_mask = 1000
cannot request MGR_NEWENTITY from mISDN. Exitting due to software bug.
wie gesagt, entweder in mISDN oder der pbx ist ein bug, oder die karten
funktionieren tatsächlich nicht (obwohl sich die module laden lassen)
falls es an mISDN/der pbx liegt, werde ich evtl. auch mal auf deren
mailinglisten vorbeischauen ;-)
> Funktionieren dann beide Netzwerk-Karten?
jo, beide gehen. ich baue dann die ISDN karten mal aus, und versuche es ohne
routing conflict die module laden zu lassen :-)
> Und: siehst du mittlerweile mit modconf deine Module deines Kernels?
leider nicht, das hängt mit der modprobe.conf von kernel 2.6 zusammen, das
"alte" modconf kommt damit nicht zurecht - is ja auch nicht soo wichtig das
modconf ;-)
mfg & vielen dank
christoph
Reply to: