Re: irq routing conflict - einige varianten
Christoph Klein wrote: nur 16. Davon führen aus Sicht des PIC 11 Leitungen zum Router und zum ISA-Bus (parallel). IRQ2 und IRQ9 ist ein und derselbe IRQ. also PIC und IRQ-Router sind unterschiedliche Dinge: hardware - router - PIC - CPU oder ? Ja. PCI - Router --- PIC --- CPU | | ISA --` festeIRQs ---´ nunja, wie, wenn die hardware mit dem router verbunden ist; die CPU als zentrale komponente daran angeschlossen ist - aber das hat sich ja inwischen geklärt - vom router führt für jeden routebaren IRQ eine Leitung zum PIC, also dessen IRQ Eingängen, welcher dann die IRQ-Verwaltung für die CPU übernimmt. Jepp. Und die CPU bearbeitet den IRQ schliesslich. http://de.wikipedia.org/wiki/Interruptcontroller Na ja... router hat prinzipiell die möglichkeit, den IRQ zuzuweisen, auch wenn das bios keine einstellungsmöglichkeiten bietet, programmierbar ist der router doch trotzdem Sicher, in einigen Fällen macht der kernel das sogar. muss dazu - der kernel APIC unterstützen Nö. - der kernel das mainboard apic unterstützen - nur das mainboard... - oder keiner apic unterstützen (... also es schon im normalen pci treiber enthalten ist...) ? arch/i386/pci/irq.c und quirks.c Bei IOAPIC sind alle 24 Interrupts fest verdrahtet, ohne Router. Der alte PIC wird bei aktivierung der IO-APIC abgeschaltet. hmm 24 Interrupts ? gibt es da einen dritten PIC (+8) Nöö, dieses gepfusche hat ein Ende genommen :) bzw. wer übernimmt dann die IRQ Verwaltung für die CPU wenn der alte pic abgeschalten ist ? Der neue IO-APIC. Dazu werden die IRQ-Leitungen umgeleitet zum IOAPIC. oder bedeutet IOAPIC (=APIC ?), dass ein anderer PIC verbaut ist, der statt mit 8 dann mit 24 Interrupts zurechtkommt ? Ja, ein Advanced-PIC == IO-APIC eben. (sorry für die vielen fragen ... bin der ansicht, dass eine problemlösung nur sinnvoll oder sogar möglich ist, wenn man das problem auch wirklich versteht :-)) Ja, ist schon ok. Im Netz sind ja auch kaum Informationen zu finden die man auf Anhieb versteht... wäre es möglich, damit auch den IRQ router zu manipulieren ? Mit setpci soll es gehen... hmm ok - kann man da was kaputtmachen ? *g* Ja, ich habe schonmal beim fluchen weil es nicht wollte versehentlich einen Kaffee über eine Tastatur ergossen... ;) -- Mit freundlichen Gruessen Bjoern Schmidt -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: irq routing conflict - einige varianten
Hallo Liste, Der Router verbindet dann die PIRQ1-4 mit den IRQ-Eingängen am PIC. Es gibt Chipsätze die können mehr als 4 Leitungen auf die Steckplätze verteilen, z.B. der SiS735. [...] Sie nimmt immer INTA#, es sei denn sie braucht mehrere INTs. INTA# ist von Steckplatz zu Steckplatz mit einem anderen PIRQ verbunden. Bei Slot1 und Slot5 sind jeweils INTA# mit PIRQ1 verbunden. Wenn in beiden eine Karte drinsteckt führt das unvermeidbar zum IRQ-Sharing. Das Bild erklärt im übrigen ziemlich gut warum das Vertauschen von Karten Sinn macht, oder? jo, tut es - jetzt wird mir sehr viel klar - vielen dank für die darstellung :-) Welche IRQ Nummer je PIRQ zugewiesen werden kann steht in den []-Klammern in der Ausgabe von dump_pirq. Theoretisch kann jedem PIRQ die gleiche IRQ Nummer zugewiesen werden - IRQ-Sharing. genau da müsste man ja eigentlich ansetzen können, also den Router etwas modden damit er die einstellungen nimmt, die der linux kernel haben will...? Die Begrenzte Anzahl ist in der PC Architektur begründet. Theoretisch sind 224 IRQ Nummern möglich, da aber nur zwei PICs eingebaut sind, sind es halt nur 16. Davon führen aus Sicht des PIC 11 Leitungen zum Router und zum ISA-Bus (parallel). IRQ2 und IRQ9 ist ein und derselbe IRQ. also PIC und IRQ-Router sind unterschiedliche Dinge: hardware - router - PIC - CPU oder ? eine weitere Frage wäre, wie die CPU mit dem IRQ Router verbunden ist, also wie die Interaktion zwischen beiden funktioniert. Welche Interaktion meinst Du? nunja, wie, wenn die hardware mit dem router verbunden ist; die CPU als zentrale komponente daran angeschlossen ist - aber das hat sich ja inwischen geklärt - vom router führt für jeden routebaren IRQ eine Leitung zum PIC, also dessen IRQ Eingängen, welcher dann die IRQ-Verwaltung für die CPU übernimmt. http://de.wikipedia.org/wiki/Interruptcontroller hmm - also ist hardwaremäßig der pci steckplatz nicht fest verschaltet, der router hat prinzipiell die möglichkeit, den IRQ zuzuweisen, auch wenn das bios keine einstellungsmöglichkeiten bietet, programmierbar ist der router doch trotzdem Sicher, in einigen Fällen macht der kernel das sogar. muss dazu - der kernel APIC unterstützen - der kernel das mainboard apic unterstützen - nur das mainboard... - oder keiner apic unterstützen (... also es schon im normalen pci treiber enthalten ist...) ? Bei IOAPIC sind alle 24 Interrupts fest verdrahtet, ohne Router. Der alte PIC wird bei aktivierung der IO-APIC abgeschaltet. hmm 24 Interrupts ? gibt es da einen dritten PIC (+8) bzw. wer übernimmt dann die IRQ Verwaltung für die CPU wenn der alte pic abgeschalten ist ? oder bedeutet IOAPIC (=APIC ?), dass ein anderer PIC verbaut ist, der statt mit 8 dann mit 24 Interrupts zurechtkommt ? (sorry für die vielen fragen ... bin der ansicht, dass eine problemlösung nur sinnvoll oder sogar möglich ist, wenn man das problem auch wirklich versteht :-)) wäre es möglich, damit auch den IRQ router zu manipulieren ? Mit setpci soll es gehen... hmm ok - kann man da was kaputtmachen ? *g* [dump_pirq] - schaue ich mir später an. jo, vielen dank für deine Hilfe :-) Mit freundlichen Gruessen Bjoern Schmidt mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: irq routing conflict - einige varianten
Hallo Liste, Der Router verbindet dann die PIRQ1-4 mit den IRQ-Eingängen am PIC. Es gibt Chipsätze die können mehr als 4 Leitungen auf die Steckplätze verteilen, z.B. der SiS735. [...] Sie nimmt immer INTA#, es sei denn sie braucht mehrere INTs. INTA# ist von Steckplatz zu Steckplatz mit einem anderen PIRQ verbunden. Bei Slot1 und Slot5 sind jeweils INTA# mit PIRQ1 verbunden. Wenn in beiden eine Karte drinsteckt führt das unvermeidbar zum IRQ-Sharing. Das Bild erklärt im übrigen ziemlich gut warum das Vertauschen von Karten Sinn macht, oder? jo, tut es - jetzt wird mir sehr viel klar - vielen dank für die darstellung :-) Welche IRQ Nummer je PIRQ zugewiesen werden kann steht in den []-Klammern in der Ausgabe von dump_pirq. Theoretisch kann jedem PIRQ die gleiche IRQ Nummer zugewiesen werden - IRQ-Sharing. genau da müsste man ja eigentlich ansetzen können, also den Router etwas modden damit er die einstellungen nimmt, die der linux kernel haben will...? Die Begrenzte Anzahl ist in der PC Architektur begründet. Theoretisch sind 224 IRQ Nummern möglich, da aber nur zwei PICs eingebaut sind, sind es halt nur 16. Davon führen aus Sicht des PIC 11 Leitungen zum Router und zum ISA-Bus (parallel). IRQ2 und IRQ9 ist ein und derselbe IRQ. also PIC und IRQ-Router sind unterschiedliche Dinge: hardware - router - PIC - CPU oder ? eine weitere Frage wäre, wie die CPU mit dem IRQ Router verbunden ist, also wie die Interaktion zwischen beiden funktioniert. Welche Interaktion meinst Du? nunja, wie, wenn die hardware mit dem router verbunden ist; die CPU als zentrale komponente daran angeschlossen ist - aber das hat sich ja inwischen geklärt - vom router führt für jeden routebaren IRQ eine Leitung zum PIC, also dessen IRQ Eingängen, welcher dann die IRQ-Verwaltung für die CPU übernimmt. http://de.wikipedia.org/wiki/Interruptcontroller hmm - also ist hardwaremäßig der pci steckplatz nicht fest verschaltet, der router hat prinzipiell die möglichkeit, den IRQ zuzuweisen, auch wenn das bios keine einstellungsmöglichkeiten bietet, programmierbar ist der router doch trotzdem Sicher, in einigen Fällen macht der kernel das sogar. muss dazu - der kernel APIC unterstützen - der kernel das mainboard apic unterstützen - nur das mainboard... - oder keiner apic unterstützen (... also es schon im normalen pci treiber enthalten ist...) ? Bei IOAPIC sind alle 24 Interrupts fest verdrahtet, ohne Router. Der alte PIC wird bei aktivierung der IO-APIC abgeschaltet. hmm 24 Interrupts ? gibt es da einen dritten PIC (+8) bzw. wer übernimmt dann die IRQ Verwaltung für die CPU wenn der alte pic abgeschalten ist ? oder bedeutet IOAPIC (=APIC ?), dass ein anderer PIC verbaut ist, der statt mit 8 dann mit 24 Interrupts zurechtkommt ? (sorry für die vielen fragen ... bin der ansicht, dass eine problemlösung nur sinnvoll oder sogar möglich ist, wenn man das problem auch wirklich versteht :-)) wäre es möglich, damit auch den IRQ router zu manipulieren ? Mit setpci soll es gehen... hmm ok - kann man da was kaputtmachen ? *g* [dump_pirq] - schaue ich mir später an. jo, vielen dank für deine Hilfe :-) Mit freundlichen Gruessen Bjoern Schmidt mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: irq routing conflict - einige varianten
Hallo Liste, Nun, passive Karten (weitverbreitet sind die AVM Fritz, deine HFCs wahrscheinlich auch) lassen einen großen Teil der Arbeit die CPU erledigen, was bei schwachen Rechnern bzw. starke Nutzung der CPU schon mal in die Hose gehen kann. Aktive Karten haben erweiterte Chips und damit Logik auf der Karte selbst, entlasten also die CPU, axo, thx für die info - also rein prinzipiell dürfte das eigentlich kein problem für die pentium2 cpu sein mit mehreren passiven karten zurechtzukommen, eine pentium1 cpu kam ja schon gut mit nur einer passiven karte aus nur wenn die karte korrekt initialisiert wird (mit optionalem routing-conflict), geht die pbx oder es kommt ein routing conflict und der alte mISDN-treiber wird verwendet, dann geht die pbx auch - bringt aber ein echo. Echo ist irgendeine Reaktion von pbx? ich vermute das echo hängt mit dem mISDN Treiber zusammen, also mit echo meine ich hier während eines telefonats über die anlage hört man sein eigenes, akustisches echo. es gab auf der mailingliste von pbx4linux bereits einen thread mit lösungsvorschlag, jedoch ist der für den alten Treiber gedacht und funktioniert zudem auch nicht... http://ischtar.koeln.ccc.de/pipermail/pbx4linux/2004-June/000258.html ...deswegen auch der versuch mit dem neuen mISDN treiber. Außer der Hersteller würde (meist für DOS/Windows) ein Konfig-Tool für die Karten anbieten: das wäre dann ein Hinweis, das *doch* Einstellungen möglich bzw. auch *nötig* sind. ich habe mal geschaut: http://www.colognechip.com/isdn/controllers/frame-software.htm da gibts nur treiber, aber hier verwende ich sowieso mISDN, da pbx4linux nur damit funktioniert (DSP). Nein, lass sie auf PCI/PnP. Ich meinte eher: manche BIOSe haben die Möglichkeit, im BIOS den PCI-Slots manuell die IRQs zuzuordnen. Heißt dann irgendwie wie: SLOT-A: auto/IRQx. Wenn du sowas hast, da meinte ich auf auto zurückzustellen. Oder halt per Funktionstaste das ganze BIOS auf Default zu stellen. ok, ich werde das mal machen, jeweils mit neuer und alter Bios Version. Doch, sollten sie. Die Debian-Kernel sind i.d.R. mit allen vorhandenen Treibern und Funktionen kompililiert. nunja, mISDN wird erst durch einen patch im kernel verfügbar, also es ist ein seperates paket für den kernel. http://home.foni.net/~jolly/download/ Ja, weil *beide* Karten sollten eigentlich (auch gleichzeitig) über Hisax-Module ladbar sein. Im ungünstigen Fall würde halt auch eine der beiden Karten nicht initialisiert werden, dann wären wir IMHO aber um eine Erkenntniss reicher (Kernel-unabhängiges Problem). ok, kommt auch noch auf die to-test liste *g* werde heute abend mal einen neuen 2.6.x debian und 2.4.x zusätzlich zum 2.4.18-bf2.4 ausprobieren. Ich weiß, wollte aber ein bißchen Heiterkeit in diesen Thread bringen. Aber da kann dir wahrscheinlich nur jemand helfen, der auch gleichzeitig vor Ort ist. *g* np, falls wirklich garnichts funktioniert, es keine möglichkeit gibt das zum laufen zu bekommen, hole ich mir noch weitere 15 Interrupts - sprich einen weiteren betagteren PC über ebay o.ä. und dann wird einer als telefonanlage und einer als lan-router im einsatz sein ;-) Der Kernel-PCI Treiber liest aus einem Register der PCI-Karte aus welchen Pin (INTn#) die Karte verwendet und mit welchem Pin (PIRQn) des Interrupt Routers dieser verbunden ist ok, damit ich das auch verstehe *g* man kann sich das so vorstellen, dass es gibt verschiedene informations-Leitungen vom gerät in richtung router gibt, welche eine karte verwenden kann ? router_ | _ | | _ | | ||| pci#1 | ||| pci#2 | ||| pci#3 |===|=||= pci#4 | ===|=|= pci#5 |__| also es bspw. so aussieht, wenn die karte in einem der steckplätze sich befindet, sie eine begrente auswahl hat, welche Leitung sie zum router verwendet ? Dann schaut er nach zu welchem IRQn des PIC der PIRQn geroutet wird (das kann man manchmal im BIOS einstellen). dh sobald eine leitung zwischen karte und router ausgehandelt ist, weißt der router dem steckplatz mit der dann zugehörigen leitung einen Interrupt zu (im Bios eingestellt), wobei ein IRQ router 8 interrupts vergeben kann an geräte ? würde das bedeuten, dass prinzipiell hier die begrenzte anzahl der interrupts nicht am router selbst liegt (man könnte ihn mittels weiteren pins für leitungen erweitern), sondern an unzureichend flexibel verschalteten leitungen zu den steckplätzen ? wie kann es dann sein, dass manche geräte immer nur einen bestimmten IRQ haben ? also wenn beispielsweise die uhr auf IRQ0 immer ist, kann das ja durchaus bedeuten, dass diese eine seperate leitung zum IRQ router hat, aber es würde nicht bedeuten, dass der router prinzipiell den IRQ nicht frei zuweisen kann, oder ? eine weitere Frage wäre, wie die CPU mit dem IRQ Router verbunden ist, also wie die Interaktion zwischen
Re: irq routing conflict - einige varianten
Christoph Klein wrote: Der Kernel-PCI Treiber liest aus einem Register der PCI-Karte aus welchen Pin (INTn#) die Karte verwendet und mit welchem Pin (PIRQn) des Interrupt Routers dieser verbunden ist ok, damit ich das auch verstehe *g* man kann sich das so vorstellen, dass es verschiedene informations-Leitungen vom gerät in richtung router gibt, welche eine karte verwenden kann ? Kann man so sagen. router_ | _ | | _ | | ||| pci#1 | ||| pci#2 | ||| pci#3 |===|=||= pci#4 | ===|=|= pci#5 |__| Router PIRQ1 PIRQ2 PIRQ3 PIRQ4 | | | | | | | | | | | | | | | | Slot1 INTA# INTB# INTC# INTD# \ \ \ / \ \ \ / .--\--\--\-' | \ \ \ |\ \ \ | \ \ \ | | | | Slot2 INTA# INTB# INTC# INTD# \ \ \ / \ \ \ / .--\--\--\-' | \ \ \ |\ \ \ | \ \ \ | | | | Slot3 INTA# INTB# INTC# INTD# \ \ \ / \ \ \ / .--\--\--\-' | \ \ \ |\ \ \ | \ \ \ | | | | Slot4 INTA# INTB# INTC# INTD# \ \ \ / \ \ \ / .--\--\--\-' | \ \ \ |\ \ \ | \ \ \ | | | | Slot5 INTA# INTB# INTC# INTD# \ \ \ / [...] | | | | SlotN INTA# INTB# INTC# INTD# Der Router verbindet dann die PIRQ1-4 mit den IRQ-Eingängen am PIC. Es gibt Chipsätze die können mehr als 4 Leitungen auf die Steckplätze verteilen, z.B. der SiS735. also es bspw. so aussieht, wenn die karte in einem der steckplätze sich befindet, sie eine begrente auswahl hat, welche Leitung sie zum router verwendet ? Sie nimmt immer INTA#, es sei denn sie braucht mehrere INTs. INTA# ist von Steckplatz zu Steckplatz mit einem anderen PIRQ verbunden. Bei Slot1 und Slot5 sind jeweils INTA# mit PIRQ1 verbunden. Wenn in beiden eine Karte drinsteckt führt das unvermeidbar zum IRQ-Sharing. Das Bild erklärt im übrigen ziemlich gut warum das Vertauschen von Karten Sinn macht, oder? Dann schaut er nach zu welchem IRQn des PIC der PIRQn geroutet wird (das kann man manchmal im BIOS einstellen). dh sobald eine leitung zwischen karte und router ausgehandelt ist, weißt der router dem steckplatz mit der dann Die Verbindung von Karte zum Router ist gemäß dem Bild fest verdrahtet, variiert aber von Board zu Board. Geroutet wird von PIRQ zu den PIC Eingängen. zugehörigen leitung einen Interrupt zu (im Bios eingestellt), wobei ein IRQ router 8 interrupts vergeben kann an geräte ? Welche IRQ Nummer je PIRQ zugewiesen werden kann steht in den []-Klammern in der Ausgabe von dump_pirq. Theoretisch kann jedem PIRQ die gleiche IRQ Nummer zugewiesen werden - IRQ-Sharing. würde das bedeuten, dass prinzipiell hier die begrenzte anzahl der interrupts nicht am router selbst liegt (man könnte ihn mittels weiteren pins für leitungen erweitern), sondern an unzureichend flexibel verschalteten leitungen zu den steckplätzen ? Die Begrenzte Anzahl ist in der PC Architektur begründet. Theoretisch sind 224 IRQ Nummern möglich, da aber nur zwei PICs eingebaut sind, sind es halt nur 16. Davon führen aus Sicht des PIC 11 Leitungen zum Router und zum ISA-Bus (parallel). IRQ2 und IRQ9 ist ein und derselbe IRQ. wie kann es dann sein, dass manche geräte immer nur einen bestimmten IRQ haben ? Die IRQ 0, 1, 2, 8, 13 sind fest verdrahtet, es ist kein Router angeschlossen. also wenn beispielsweise die uhr auf IRQ0 immer ist, kann das ja durchaus bedeuten, dass diese Die Uhr ist auf 8. 0 ist der Timer. eine seperate leitung zum IRQ router hat, aber es würde nicht bedeuten, dass der router prinzipiell den IRQ nicht frei zuweisen kann, oder ? eine weitere Frage wäre, wie die CPU mit dem IRQ Router verbunden ist, also wie die Interaktion zwischen beiden funktioniert. Welche Interaktion meinst Du? hmm - also ist hardwaremäßig der pci steckplatz nicht fest verschaltet, der router hat prinzipiell die möglichkeit, den IRQ zuzuweisen, auch wenn das bios keine einstellungsmöglichkeiten bietet, programmierbar ist der router doch trotzdem Sicher, in einigen Fällen macht der kernel das sogar. und APIC bedeutet dann, dass das OS wieder etwas am IRQ Router machen kann, also die IRQs neu verteilen ? Bei IOAPIC sind alle 24 Interrupts fest verdrahtet, ohne Router. Der alte PIC wird bei aktivierung
Re: irq routing conflict - einige varianten
Gruesse! * Christoph Klein [EMAIL PROTECTED] schrieb am [19.09.04 19:28]: Immer noch mein Vorschlag: NICs ausbauen, ISDN-Karten zum Funktionieren bringen, NICs wieder einbauen. IMHO hast du erst dann ein wirkliches Problem, wenn z.B. die NIC/ISDN-Karten Kombination seperat funktioniert aber im Zusammenspiel nicht. Kannst du dazu eine definitive Aussage machen? Nun, ich habe nun einiges ausprobiert. Das Ausbauen der Netzwerkkarten hat nicht geholfen, die pbx startete nicht. Zu meinem Verständnis: für pbx brauchst du 2 ISDN-Karten? Bzw: Funktionieren überhaupt zwei passive Karten gleichzeitig? Z.B. die AVM-Fritz-Treiber unterstützen für CAPI nur eine passive Karte, bei aktiven IMHO bis zu vier. Und noch mal ganz zurück an den Anfang. Warum kannst du nicht bei 2.6.7 bleiben wenn es da doch funktioniert? jo, das dachte ich mir jetzt auch, und habe wieder 2.6.7 draufgemacht. Zur Abwechslung gibts hier sogar auch mal ne andere Fehlermeldung Das sind Meldungen aus der syslog bzw. kern.log ? Und zwar von 2.6.7. Und die Meldungen weiter unten zum Starten der ISDN-Karten sind aus dmesg des gleichen Kernels? Dann sind das Folgefehler vom Nicht-Initialisieren einer Karte. Irgendwelche Basteleien am Source sind unnötig, zeigen aber den momentanen Grad der Frustration ;-) Sep 19 18:12:51 server kernel: Debug: sleeping function called from invalid context at arch/i386/lib/usercopy.c:623 Sep 19 18:12:51 server kernel: in_atomic():1, irqs_disabled():1 Sep 19 18:12:51 server kernel: [c0116cd6] __might_sleep+0xaa/0xb4 Sep 19 18:12:51 server kernel: [c01c7dc6] copy_from_user+0x1e/0x68 [...] Meine Vermutung zu der ganzen Sache ist folgende: der alte mISDN treiber kommt besser mit den ominösen irq-routing conflict meldungen zurecht, also startet; produziert aber ein echo. der neue scheint hier etwas genauer zu sein, also lässt die pbx nicht starten, nach umstecken der ISDN karten, hat die pbx sogar einmal gestartet, nur eine ISDNkarte lief nicht, war im programm rot markiert und die obigen fehlermeldungen erschienen nur noch halb so oft. Kann es sein das: eine Karte defekt ist? Oder eine Karte nicht richtig im Slot sitzt? (Hatte auch einen PC in Arbeit, den man nur scharf anschauen mußte damit irgendetwas nicht mehr funktionierte da die PCI-Slots ausgelutscht waren). Um sicher zu gehen: Bitte noch mal nachstecken. Wenn pbx mit einer Karte möglich ist, dann bitte auch mal jeweils nur *eine* ISDN-Karte testen. Bzw. nur mit einer die Log beim Laden der Module beobachten. Beim Laden der mISDN module erscheint das: Hier also die erste Karte: Sep 19 18:36:09 server kernel: HFC card cb663000 dch cb663090 bch1 cb66321c bch2 cb6633b4 Sep 19 18:36:09 server kernel: PCI: Found IRQ 11 for device :00:0a.0 Der Kernel-PCI-Treiber ordnet diesem Steckplatz den IRQ 11 zu (Björn: ist das richtig so?) Sep 19 18:36:09 server kernel: IRQ routing conflict for :00:0a.0, have irq 10, want irq 11 Vom BIOS oder Karte wurde aber IRQ 10 eingestellt. Richtig? (1.Karte BIOS-IRQ-Meldungen auf 10 ?) Sep 19 18:36:09 server kernel: HFC-PCI: defined at mem 0xcc80ae00 fifo 0xc9c28000(0x9c28000) IRQ 10 HZ 1000 Sep 19 18:36:09 server kernel: inithfcpci: entered Sep 19 18:36:09 server kernel: HFC PCI: IRQ 10 count 34 Daher läuft die Karte schlußendlich auch auf IRQ 10, also bios-gemäß. Erzeugt auch Interrupts (34). Hier die zweite Karte: Sep 19 18:36:09 server kernel: HFC card c9d0c000 dch c9d0c090 bch1 c9d0c21c bch2 c9d0c3b4 Sep 19 18:36:09 server kernel: PCI: Found IRQ 12 for device :00:0b.0 Der Kernel-PCI-Treiber findet IRQ 12 für diesen Slot (kollidiert evtl. mit PS/2-Maus oder Tastatur) Sep 19 18:36:09 server kernel: IRQ routing conflict for :00:0b.0, have irq 11, want irq 12 Vom BIOS wurde die 2.Karte aber auf IRQ 11 gesetzt. Richtig? Sep 19 18:36:09 server kernel: HFC-PCI: defined at mem 0xcc8ced00 fifo 0xc9c18000(0x9c18000) IRQ 11 HZ 1000 Sep 19 18:36:09 server kernel: spin_lock_adr=c9d0c06c now(cc90b7b2) Sep 19 18:36:09 server kernel: busy_lock_adr=c9d0c070 now(cc90b7b2) Sep 19 18:36:09 server kernel: reset_hfcpci: entered Sep 19 18:36:09 server kernel: HFC_PCI: resetting HFC ChipId(ff) Sep 19 18:36:09 server kernel: HFC-PCI status(ff) before reset Sep 19 18:36:09 server kernel: HFC-PCI status(ff) after reset Sep 19 18:36:09 server kernel: HFC-PCI status(ff) after 5us Sep 19 18:36:09 server kernel: init_card: entered Sep 19 18:36:09 server kernel: inithfcpci: entered Sep 19 18:36:09 server kernel: HFC PCI: IRQ 11 count 0 Sep 19 18:36:09 server kernel: HFC PCI: IRQ(11) getting no interrupts during init 1 Jetzt wird versucht die Karte bios-gemäß auf IRQ11 zu initialisieren, was aber (mehrmals) fehlschlägt (no interrupts count) und auch obige Fehlermeldung aus usercopy.c auslöst. Also entweder kollidiert die 2.Karte mit einer anderen Hardware (unwahrscheinlich), ist defekt oder nicht richtig eingestellt. Bei Karten bitte mal
Re: irq routing conflict - einige varianten
Hallo Liste, Zu meinem Verständnis: für pbx brauchst du 2 ISDN-Karten? genau, eine im TE modus für den anschluss ans erste ntba, welches den externen s0-bus zur verfügung stellt. nr. 2 läuft im NT-Modus, also stellt dann einen internen s0-bus zur verfügung ans zweite, interne ntba, somit lässt sich allerlei interessantes realisieren, VoIP/H.323/email to fax/fax 2 email/anrufbeantworter auf email etc man kann eigentlich telefoninternet weitgehend kombinieren achja, normal über isdn telefonieren geht auch noch *g* Bzw: Funktionieren überhaupt zwei passive Karten gleichzeitig? Z.B. die AVM-Fritz-Treiber unterstützen für CAPI nur eine passive Karte, bei aktiven IMHO bis zu vier. nun, was ist der unterschied zwischen aktiven und passiven isdnkarten ? ich hatte mich an der dokumentation auf der pbx4linux-website orientiert, dort waren die karten als möglich beschrieben - es hat mit ihnen ja auch schon so funktioniert (nur mit audio-echos und altem mISDN halt ...) Das sind Meldungen aus der syslog bzw. kern.log ? Und zwar von 2.6.7. genau, aus der kern.log bei 2.6.7 - sie sind aber auch an der console selbst sichtbar. Und die Meldungen weiter unten zum Starten der ISDN-Karten sind aus dmesg des gleichen Kernels? Dann sind das Folgefehler vom Nicht-Initialisieren einer Karte. hmm - dh manchmal wird eine karte trotz routing-conflict intitialisiert und funktioniert, und manchmal (je nach karten/steckplatz konfiguration) kommt zwar die gleiche routing-conflict meldung, aber es kommen folgefehler und die karte geht nicht - paradox. Kann es sein das: eine Karte defekt ist? hmm, besten bzw. schlechtestenfalls hat eine beim umstecken den geist aufgegeben, ich werde es mal durch vertauschen der isdnkarten testen. Oder eine Karte nicht richtig im Slot sitzt? Um sicher zu gehen: Bitte noch mal nachstecken. eher unwahrscheinlich, aber ich werde das auch nochmals prüfen. Wenn pbx mit einer Karte möglich ist, dann bitte auch mal jeweils nur *eine* ISDN-Karte testen. Bzw. nur mit einer die Log beim Laden der Module beobachten. naja, das ist so - wenn ich die netzwerkkarten ausbaue und bestimmte steckplätze verwende (glaube 2 und 4) dann hatte ich eine karte ohne routing confict hinbekommen - dann funktionierte sie auch bei der pbx. Hier also die erste Karte: Sep 19 18:36:09 server kernel: HFC card cb663000 dch cb663090 bch1 cb66321c bch2 cb6633b4 Sep 19 18:36:09 server kernel: PCI: Found IRQ 11 for device :00:0a.0 Der Kernel-PCI-Treiber ordnet diesem Steckplatz den IRQ 11 zu (Björn: ist das richtig so?) angenommen das wäre so - warum tut der kernel-pci-treiber das ? Sep 19 18:36:09 server kernel: IRQ routing conflict for :00:0a.0, have irq 10, want irq 11 Vom BIOS oder Karte wurde aber IRQ 10 eingestellt. Richtig? (1.Karte BIOS-IRQ-Meldungen auf 10 ?) genau, sie ist auf IRQ 10 wie im bios - und hat mit dem alten mISDN treiber unter 2.6.7 auch funktioniert, trotz routing conflict. Sep 19 18:36:09 server kernel: HFC-PCI: defined at mem 0xcc80ae00 fifo 0xc9c28000(0x9c28000) IRQ 10 HZ 1000 Sep 19 18:36:09 server kernel: inithfcpci: entered Sep 19 18:36:09 server kernel: HFC PCI: IRQ 10 count 34 Daher läuft die Karte schlußendlich auch auf IRQ 10, also bios-gemäß. Erzeugt auch Interrupts (34). völlig richtig, nur die pbx lässt sich nicht starten. nur wenn die karte korrekt initialisiert wird (mit optionalem routing-conflict), geht die pbx oder es kommt ein routing conflict und der alte mISDN-treiber wird verwendet, dann geht die pbx auch - bringt aber ein echo. Sep 19 18:36:09 server kernel: HFC card c9d0c000 dch c9d0c090 bch1 c9d0c21c bch2 c9d0c3b4 Sep 19 18:36:09 server kernel: PCI: Found IRQ 12 for device :00:0b.0 Der Kernel-PCI-Treiber findet IRQ 12 für diesen Slot (kollidiert evtl. mit PS/2-Maus oder Tastatur) Sep 19 18:36:09 server kernel: IRQ routing conflict for :00:0b.0, have irq 11, want irq 12 Vom BIOS wurde die 2.Karte aber auf IRQ 11 gesetzt. Richtig? jo, genau wie bei der anderen ISDN-Karte, es kommt ein routing conflict, die karten wollen aus unverständlichen gründen auf einen anderen IRQ, können aber nicht. bei den netzwerkkarten und altem mISDN treiber ist das egal, aber der neue mISDN treiber scheint diesbezüglich empfindlich zu sein - was auch durchaus berechtigt ist. Sep 19 18:36:09 server kernel: init_card: entered Sep 19 18:36:09 server kernel: inithfcpci: entered Sep 19 18:36:09 server kernel: HFC PCI: IRQ 11 count 0 Sep 19 18:36:09 server kernel: HFC PCI: IRQ(11) getting no interrupts during init 1 Jetzt wird versucht die Karte bios-gemäß auf IRQ11 zu initialisieren, was aber (mehrmals) fehlschlägt (no interrupts count) und auch obige Fehlermeldung aus usercopy.c auslöst. klingt logisch, zudem das obige hier auch nur einmal auftritt, also eine karte trotz routing conflict erfolgreich initialisiert wurde - und dann bei der pbx doch wieder funktioniert. Also entweder kollidiert die
Re: irq routing conflict - einige varianten
Gruesse! * Christoph Klein [EMAIL PROTECTED] schrieb am [20.09.04 16:54]: Bzw: Funktionieren überhaupt zwei passive Karten gleichzeitig? Z.B. die AVM-Fritz-Treiber unterstützen für CAPI nur eine passive Karte, bei aktiven IMHO bis zu vier. nun, was ist der unterschied zwischen aktiven und passiven isdnkarten ? ich hatte mich an der dokumentation auf der pbx4linux-website orientiert, dort waren die karten als möglich beschrieben - es hat mit ihnen ja auch schon so funktioniert (nur mit audio-echos und altem mISDN halt ...) Nun, passive Karten (weitverbreitet sind die AVM Fritz, deine HFCs wahrscheinlich auch) lassen einen großen Teil der Arbeit die CPU erledigen, was bei schwachen Rechnern bzw. starke Nutzung der CPU schon mal in die Hose gehen kann. Aktive Karten haben erweiterte Chips und damit Logik auf der Karte selbst, entlasten also die CPU, sind i.d.R. auch dementsprechend teuer. Ist vergleichbar wie ein GDI-Drucker unter Windows wenn dir das was sagt. Das war aber nur eine Idee. Und wenn pbx 2 Karten braucht, dann wird das auch mit 2 funktionieren. Dann sind das Folgefehler vom Nicht-Initialisieren einer Karte. hmm - dh manchmal wird eine karte trotz routing-conflict intitialisiert und funktioniert, und manchmal (je nach karten/steckplatz konfiguration) kommt zwar die gleiche routing-conflict meldung, aber es kommen folgefehler und die karte geht nicht - paradox. Und da muß halt irgendetwas die 2. Karte bzw. den Steckplatz davon abhalten, trotz Warnung eben den vom Kernel monierten Konflikt nebauso wie bei der ersten aufzulösen. Das irgendetaws ist halt unser Problem. Wenn pbx mit einer Karte möglich ist, dann bitte auch mal jeweils nur *eine* ISDN-Karte testen. Bzw. nur mit einer die Log beim Laden der Module beobachten. naja, das ist so - wenn ich die netzwerkkarten ausbaue und bestimmte steckplätze verwende (glaube 2 und 4) dann hatte ich eine karte ohne routing confict hinbekommen - dann funktionierte sie auch bei der pbx. Bei vier PCI-Slots wären das 4 hoch 4 Kombinationsmöglichkeiten ;-) Der Kernel-PCI-Treiber ordnet diesem Steckplatz den IRQ 11 zu (Björn: ist das richtig so?) angenommen das wäre so - warum tut der kernel-pci-treiber das ? Ja, da drehen wir uns wieder im Kreis: buggy BIOS, APIC, ACPI, ... Daher läuft die Karte schlußendlich auch auf IRQ 10, also bios-gemäß. Erzeugt auch Interrupts (34). völlig richtig, nur die pbx lässt sich nicht starten. nur wenn die karte korrekt initialisiert wird (mit optionalem routing-conflict), geht die pbx oder es kommt ein routing conflict und der alte mISDN-treiber wird verwendet, dann geht die pbx auch - bringt aber ein echo. Echo ist irgendeine Reaktion von pbx? Also entweder kollidiert die 2.Karte mit einer anderen Hardware (unwahrscheinlich), ist defekt oder nicht richtig eingestellt. richtig eingestellt ? - kann man da noch irgendwo was dran drehen außer im Bios ? Tschuldigung, was ein blödes Wort. Ich meinte schon BIOS/slot-seitig. Außer der Hersteller würde (meist für DOS/Windows) ein Konfig-Tool für die Karten anbieten: das wäre dann ein Hinweis, das *doch* Einstellungen möglich bzw. auch *nötig* sind. Vielleicht gerade wenn man mehrere baugleiche Karten verwenden will. b) BIOS *komplett* auf Default zurückstellen (es gibt da meistens eine Funktionstaste, die das erledigt), zumindest alle Änderungen im Bereich PCI/PnP was die IRQ-Verteilung der Slots betrifft, also am besten alles auf auto. hmm - also im bios fand ich nur die optionen entweder pci/pnp für die IRQs einzustellen oder sie (glaube ich) isa steckplätzen zuzuteilen. was würde denn passieren, wenn ich ALLE IRQs auf die leeren ISA-steckplätze zuteile, also die karten keinen interrupt vom Bios haben - können sie dann unter linux auf den IRQ, auf den sie wollen ? -oder geht garnichts mehr ? Nein, lass sie auf PCI/PnP. Ich meinte eher: manche BIOSe haben die Möglichkeit, im BIOS den PCI-Slots manuell die IRQs zuzuordnen. Heißt dann irgendwie wie: SLOT-A: auto/IRQx. Wenn du sowas hast, da meinte ich auf auto zurückzustellen. Oder halt per Funktionstaste das ganze BIOS auf Default zu stellen. d) einen fertigen Debian-Kernel 2.6.7/8 downloaden installieren, booten. ok, das teste ich noch - wobei die kernel kein mISDN haben, oder ? Doch, sollten sie. Die Debian-Kernel sind i.d.R. mit allen vorhandenen Treibern und Funktionen kompililiert. e) Wenn die NICs/HFCs auch vom 2.4.x-Kernel unterstützt werden (zumindest im 2.4.26 werden diverse HFC über Hisax unterstützt) auch einen 2.4.x Kernel installieren, booten Module laden. auch eine möglichkeit - also ohne mISDN. Ja, weil *beide* Karten sollten eigentlich (auch gleichzeitig) über Hisax-Module ladbar sein. Im ungünstigen Fall würde halt auch eine der beiden Karten nicht initialisiert werden, dann wären wir IMHO aber um eine Erkenntniss reicher (Kernel-unabhängiges Problem). falls jmd. von euch
Re: irq routing conflict - einige varianten
Gerhard Brauer wrote: Sep 19 18:36:09 server kernel: HFC card cb663000 dch cb663090 bch1 cb66321c bch2 cb6633b4 Sep 19 18:36:09 server kernel: PCI: Found IRQ 11 for device :00:0a.0 Der Kernel-PCI-Treiber ordnet diesem Steckplatz den IRQ 11 zu (Björn: ist das richtig so?) Der Kernel-PCI Treiber liest aus einem Register der PCI-Karte aus welchen Pin (INTn#) die Karte verwendet und mit welchem Pin (PIRQn) des Interrupt Routers dieser verbunden ist. Dann schaut er nach zu welchem IRQn des PIC der PIRQn geroutet wird (das kann man manchmal im BIOS einstellen). Der Interrupt Router -durch BIOS programmiert- weist also diesem Steckplatz den IRQ11 zu. Christoph, kannst Du mir bitte den Output von scanpci -v oder von dump_pirq zumailen? scanpci ist in den xutils... Kompilier Deinen kernel nochmal neu, diesmal mit CONFIG_PCI_MSI=y (bei den BUS Optionen). Damit wird die Fehlermeldung (IRQ conflict) verschwinden, wenn der kernel booten kann... -- Mit freundlichen Gruessen Bjoern Schmidt -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: irq routing conflict - einige varianten
Gerhard Brauer wrote: Vom BIOS oder Karte wurde aber IRQ 10 eingestellt. Richtig? (1.Karte BIOS-IRQ-Meldungen auf 10 ?) Diese Karte hat IRQ10, eine weitere Karte die den gleichen PIRQn benutzt hat aber IRQ11. Warum das hier so angezeigt wird weiss ich noch nicht. -- Mit freundlichen Gruessen Bjoern Schmidt -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: irq routing conflict - einige varianten
Hallo Liste, Nee, Aufkleber sind nicht sinnvoll. ...wie beruhigend :D ;-) Die Nummer die ich meine ist meistens wie die Leiterbahnen in die Grundplatte eingeätzt und sieht dementsprechend aus. Sie hat immer das Format PCBx.x, bzw. PCB x.x jo, du hast recht - habe ganz unten links im eck auch eingeätzt die nr. 1.3 gefunden. meinst du, dass man keine version 1.4 aufspielen sollte, weil diese alle für die QF* ausführungen, nicht die QC* sind ? Nein, Du hast es noch nicht verstanden. Die PrintedCircuitBoard-Nummer PCB steht für die Version der Hardware, nicht für die des BIOS! Es gibt keine BIOS-Version 1.4 die Du aufspielen kannst, die BIOS Versionsnummern beginnen alle mit Q. aha, danke - das mit der PCB wusste ich nicht. lohnt sich dann überhaupt ein biosupdate ? angenommen es wird wirklich nur das an den bios-images verändert, was beim download auch erwähnt wird - dann bräuchte man doch keines oder ? Ansonsten probiere ich es mal mit QC617 Falls das nichts bringt, muss evtl. ein anderes mainboard her Mit freundlichen Gruessen Bjoern Schmidt mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: irq routing conflict - einige varianten
Christoph Klein wrote: aha, danke - das mit der PCB wusste ich nicht. lohnt sich dann überhaupt ein biosupdate ? angenommen es wird wirklich nur das an den bios-images verändert, Was da steht ist für den normalblöden User. Die vollständigen Änderungen stehen nie dabei. Beim QC617 steht ja nichtmal was dabei. was beim download auch erwähnt wird - dann bräuchte man doch keines oder ? Spekulation. Ich würds versuchen. Wenn nix bringt kannste ja ein downgrade machen. Da das BIOS die Programmierung des PIC vornimmt, kann es schon sein dass ein Update das Problem beheben kann. Ansonsten probiere ich es mal mit QC617 Ja, mach ma... ;) Falls das nichts bringt, muss evtl. ein anderes mainboard her ... Hast Du mittlererweile die PCI-Karten ein wenig permutiert? -- Mit freundlichen Gruessen Bjoern Schmidt -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: irq routing conflict - einige varianten
Hallo Liste, Hm, das verstehe ich jetzt nicht. Treiber bzw. Module für nicht vorhandene Hanrdware sollte in einen selbstgebauten Kernel eh nicht sein. Wenn du Hardware deaktivierst für Hardware die du brauchst, hast du ein Problem. Wenn du aber kein Problem hast, brauchst du die Hardware nicht... hmm, naja, mein gedanke ist, im kernel soviel hardwareunterstützung wie möglich zu deaktivieren, um fehlerquellen auszuschließen. Immer noch mein Vorschlag: NICs ausbauen, ISDN-Karten zum Funktionieren bringen, NICs wieder einbauen. IMHO hast du erst dann ein wirkliches Problem, wenn z.B. die NIC/ISDN-Karten Kombination seperat funktioniert aber im Zusammenspiel nicht. Kannst du dazu eine definitive Aussage machen? Nun, ich habe nun einiges ausprobiert. Das Ausbauen der Netzwerkkarten hat nicht geholfen, die pbx startete nicht. Und noch mal ganz zurück an den Anfang. Warum kannst du nicht bei 2.6.7 bleiben wenn es da doch funktioniert? jo, das dachte ich mir jetzt auch, und habe wieder 2.6.7 draufgemacht. Zur Abwechslung gibts hier sogar auch mal ne andere Fehlermeldung Sep 19 18:12:51 server kernel: Debug: sleeping function called from invalid context at arch/i386/lib/usercopy.c:623 Sep 19 18:12:51 server kernel: in_atomic():1, irqs_disabled():1 Sep 19 18:12:51 server kernel: [c0116cd6] __might_sleep+0xaa/0xb4 Sep 19 18:12:51 server kernel: [c01c7dc6] copy_from_user+0x1e/0x68 Sep 19 18:12:51 server kernel: [cc90fd51] mISDN_write+0x1a1/0x814 [mISDN_core] Sep 19 18:12:51 server kernel: [c016152e] select_bits_free+0xa/0x10 Sep 19 18:12:51 server kernel: [c01619b5] sys_select+0x481/0x490 Sep 19 18:12:51 server kernel: [c014f67c] vfs_write+0xa0/0xd0 Sep 19 18:12:51 server kernel: [c014f729] sys_write+0x31/0x4c Sep 19 18:12:51 server kernel: [c0103e8f] syscall_call+0x7/0xb auch wenn ich keine wirkliche ahnung davon habe, habe ich diese ominöse might_sleep(); Funktion in usercopy.c einfach mal auskommentiertes hatte aber folgende wirkung: Sep 19 18:53:14 server kernel: Debug: sleeping function called from invalid context at arch/i386/lib/usercopy.c:597 Sep 19 18:53:14 server kernel: in_atomic():1, irqs_disabled():1 Sep 19 18:53:14 server kernel: [c0116cd6] __might_sleep+0xaa/0xb4 Sep 19 18:53:14 server kernel: [c01c7d75] copy_to_user+0x19/0x4c Sep 19 18:53:14 server kernel: [cc916a3c] mISDN_read+0x1b8/0x320 [mISDN_core] Sep 19 18:53:14 server kernel: [c014f4fc] vfs_read+0xa0/0xd0 Sep 19 18:53:14 server kernel: [c014f6dd] sys_read+0x31/0x4c Sep 19 18:53:14 server kernel: [c0103e8f] syscall_call+0x7/0xb also nun gefällt im eine andere zeile nicht. hier kommt man also nicht weiter - ich habe den ausgangszustand wiederhergestellt. Meine Vermutung zu der ganzen Sache ist folgende: der alte mISDN treiber kommt besser mit den ominösen irq-routing conflict meldungen zurecht, also startet; produziert aber ein echo. der neue scheint hier etwas genauer zu sein, also lässt die pbx nicht starten, nach umstecken der ISDN karten, hat die pbx sogar einmal gestartet, nur eine ISDNkarte lief nicht, war im programm rot markiert und die obigen fehlermeldungen erschienen nur noch halb so oft. Beim Laden der mISDN module erscheint das: Sep 19 18:36:09 server kernel: Modular ISDN Stack core $Revision: 1.23 $ Sep 19 18:36:09 server kernel: mISDNd: kernel daemon started Sep 19 18:36:09 server kernel: mISDNd: test event done Sep 19 18:36:09 server kernel: ISDN L1 driver version 1.11 Sep 19 18:36:09 server kernel: ISDN L2 driver version 1.19 Sep 19 18:36:09 server kernel: mISDN: DSS1 Rev. 1.26 Sep 19 18:36:09 server kernel: mISDN_dsp: Audio DSP Rev. 1.9 (debug=0x0) Sep 19 18:36:09 server kernel: HFC card cb663000 dch cb663090 bch1 cb66321c bch2 cb6633b4 Sep 19 18:36:09 server kernel: mISDN: HFC-PCI driver Rev. 1.38 Sep 19 18:36:09 server kernel: PCI: Found IRQ 11 for device :00:0a.0 Sep 19 18:36:09 server kernel: IRQ routing conflict for :00:0a.0, have irq 10, want irq 11 Sep 19 18:36:09 server kernel: mISDN: HFC-PCI card manufacturer: CCD/Billion/Asuscom card name: 2BD0 Sep 19 18:36:09 server kernel: HFC-PCI: defined at mem 0xcc80ae00 fifo 0xc9c28000(0x9c28000) IRQ 10 HZ 1000 Sep 19 18:36:09 server kernel: spin_lock_adr=cb66306c now(cc90b7b2) Sep 19 18:36:09 server kernel: busy_lock_adr=cb663070 now(cc90b7b2) Sep 19 18:36:09 server kernel: reset_hfcpci: entered Sep 19 18:36:09 server kernel: HFC_PCI: resetting HFC ChipId(30) Sep 19 18:36:09 server kernel: HFC-PCI status(4) before reset Sep 19 18:36:09 server kernel: HFC-PCI status(2) after reset Sep 19 18:36:09 server kernel: HFC-PCI status(4) after 5us Sep 19 18:36:09 server kernel: init_card: entered Sep 19 18:36:09 server kernel: inithfcpci: entered Sep 19 18:36:09 server kernel: HFC PCI: IRQ 10 count 34 Sep 19 18:36:09 server kernel: HFC card c9d0c000 dch c9d0c090 bch1 c9d0c21c bch2 c9d0c3b4 Sep 19 18:36:09 server kernel: mISDN: HFC-PCI driver Rev. 1.38 Sep 19 18:36:09 server kernel: PCI: Found IRQ 12 for device :00:0b.0 Sep 19
Re: irq routing conflict - einige varianten
Hallo Liste, IS funktioniert auch ohne ACPI, klar. gut, dann kann ich ACPI also abgeschaltet lassen Auf jedem gängigen PCI basierten System sind Shared Interrupts das normalste der Welt und lassen sich praktisch gar nicht vermeiden hmm ... dh der routing conflict beruht darauf, dass IRQs geshared werden und der Treiber eines der IRQ-sharenden Geräte nicht damit zurecht kommt ? oder welche Möglichkeit gibt es noch, dass ein routing conflict erscheint, wenn doch IRQ sharing eigentlich problemlos funktionieren müsste ? Ob ein Treiber shared interrupts NICHT unterstützt kannst Du schnell herausfinden, nämlich indem Du in seiner Quelldatei nach SA_SHIRQ grepst und es nicht findest. ich habe mit mal die 8139too.c , hfc_pci.c dmfe.c angeschaut - in allen kommt SA_SHIRQ vor, dh die Treiber unterstützen IRQ sharing. Ist es auch möglich, dass die Meldung routing conflict selbst ein Bug ist, also es eigentlich keinen routing conflict gibt ? aber warum war dann eine Karte mal auf IRQ 0 gewesen ? Da du bei dem PC ja auch eine etwas betagtere Hardware einsetzt (ich werkele hier z.B. auch noch mit meinem K62/350 rum, glücklich und zufrieden!) wäre es auch noch mal eine Überlegung, über ein BIOS-Update nachzudenken. Evtl. behebt ein Update eine mangelhafte BIOS-Implementation im Bereich PCI-Bus. ok, das ist auch eine idee - ich werde mal schauen ob ich irgendwo ein update finde :-) Oder es gibt bei mISDN ein Tool wie z.B. capiinfo bzw isdnctrl bei Hisax zum Überprüfung des Status. hmm eigentlich müsste capiinfo ja auch bei mISDN funktionieren - capi setzt ja auf dem hardwaretreiber für die isdnkarten auf soweit ich weiß, also müsste capiinfo = capi2.0 = mISDN eigentlich gehen ich habe mal mit apt-file search capiinfo ausfindig gemacht und versucht zu installieren: apt-get: Starting ISDN services: no ISDN cards configured! Please configure 'hisax' module with modconf [...] Starting ISDN active cards :ERROR: cannot load module kernelcapi das kann nun entweder heißen, dass das debian-package nicht für mISDN konzipiert ist, also auf hisax in verbindung mit 2.4 oder dass der versuch kernelcapi als modul deswegen fehlschlägt, weil ich es fest einkompiliert habe, also kein modul da ist. ich werde es nochmals als modul kompilieren. Bei Nicht-Funktionieren würde ich einen eigenen Thread zu mISDN aufmachen. Wenn es funktioniert, würde ich eine oder beide NICs wieder einbauen und dann schauen, ob es immer noch geht. ok, ich teste das mal alles durch, biosupdate, kartentauschen etc ;-) mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: irq routing conflict - einige varianten
Gruesse! * Christoph Klein [EMAIL PROTECTED] schrieb am [18.09.04 15:41]: hmm ... dh der routing conflict beruht darauf, dass IRQs geshared werden und der Treiber eines der IRQ-sharenden Geräte nicht damit zurecht kommt ? oder welche Möglichkeit gibt es noch, dass ein routing conflict erscheint, wenn doch IRQ sharing eigentlich problemlos funktionieren müsste ? Der Konflikt und das Sharing müssen ja nicht ursächlich zusammenhängen. Es *kann* doch einfach so sein: Zum Zeitpunkt, wo das BIOS die Hardware initialisiert, ist wesentlich weniger Hardware aktiv als zum Zeitpunkt, an dem das Betriebsystem die Hardware übernimmt. Oder auf den Karten-Chips sind irgendwelche Voreinstellungen/Wünsche (setze mich bitte auf IRQ xyz, bei ISA-Karten gab es das mal). Das OS als Oberguru seiner Hardware ändert das jetzt und die Karte beschwert sich. Linux in seiner gnadenlosen Offenheit macht diese Beschwerde jetzt auch noch öffentlich ;-) Da du bei dem PC ja auch eine etwas betagtere Hardware einsetzt (ich werkele hier z.B. auch noch mit meinem K62/350 rum, glücklich und zufrieden!) wäre es auch noch mal eine Überlegung, über ein BIOS-Update nachzudenken. Evtl. behebt ein Update eine mangelhafte BIOS-Implementation im Bereich PCI-Bus. ok, das ist auch eine idee - ich werde mal schauen ob ich irgendwo ein update finde :-) Da du den Hersteller/Bezeichnung deines Boards ja nicht kennst kannst du: a) Rechner aufmachen, irgendeine größere Bezeichnung auf dem Mutterbrett mal über Google suchen lassen. oder b) versuchen den Hersteller/Bezeichnung aus dem Speicher auszulesen. Dazu als root: dd if=/proc/kcore of=/tmp/mem bs=1024 count=1000 strings /tmp/mem | less Im less pager kannst du dann z.B. nach BIOS oder MANUFACT suchen lassen, oder einfach durchblättern bis zu was findest. Was du dann siehst bzw. suchst sind alle Textstrings auch des BIOSes, und da ist i.d.R. auch der Hesteller und die Bezeichnung zu finden. count=1000 sollte eigentlich langen, wenn du nichts findest was nach BIOS aussieht count mal erhöhen z.B. 2000 Oder es gibt bei mISDN ein Tool wie z.B. capiinfo bzw isdnctrl bei Hisax zum Überprüfung des Status. hmm eigentlich müsste capiinfo ja auch bei mISDN funktionieren - capi setzt ja auf dem hardwaretreiber für die isdnkarten auf soweit ich weiß, also müsste capiinfo = capi2.0 = mISDN eigentlich gehen ich habe mal mit apt-file search capiinfo ausfindig gemacht und versucht zu installieren: apt-get: Starting ISDN services: no ISDN cards configured! Please configure 'hisax' module with modconf [...] Starting ISDN active cards :ERROR: cannot load module kernelcapi das kann nun entweder heißen, dass das debian-package nicht für mISDN konzipiert ist, also auf hisax in verbindung mit 2.4 oder dass der versuch kernelcapi als modul deswegen fehlschlägt, weil ich es fest einkompiliert habe, also kein modul da ist. ich werde es nochmals als modul kompilieren. Müßte (*wenn* es mit mISDN geht) auch mit fest einkompilierter CAPI-Unterstützung gehen. Die erste Meldung (ISDN-Services) kannst du ignorieren, das kommt vom isdnlog bzw. hisax. Vielleicht hast du ja auch mISDN bzw. capi-seitig noch nicht alles aktiviert im Kernel. Es muß doch zu mISDN in /usr/share/doc doch eine Readme geben, wo die Konfiguration beschrieben ist? ok, ich teste das mal alles durch, biosupdate, kartentauschen etc ;-) Viel Spaß ;-) mfg christoph Gruß Gerhard
Re: irq routing conflict - einige varianten
Was war das doch gleich für ein Board? Mach mal bitte ein dmidecode... -- Mit freundlichen Gruessen Bjoern Schmidt -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: irq routing conflict - einige varianten
Gruesse! * Björn Schmidt [EMAIL PROTECTED] schrieb am [18.09.04 17:53]: Was war das doch gleich für ein Board? Mach mal bitte ein dmidecode... Hach, was es nicht alles gibt... ;-) Mit freundlichen Gruessen Bjoern Schmidt Gruss Gerhard
Re: irq routing conflict - einige varianten
Hallo Liste, Es *kann* doch einfach so sein: Zum Zeitpunkt, wo das BIOS die Hardware initialisiert, ist wesentlich weniger Hardware aktiv als zum Zeitpunkt, an dem das Betriebsystem die Hardware übernimmt. das wäre noch eine Möglichkeit ... ich deaktiviere in einem neuen Kernel mal soviel hardware wie möglich. Oder auf den Karten-Chips sind irgendwelche Voreinstellungen/Wünsche (setze mich bitte auf IRQ xyz, bei ISA-Karten gab es das mal). Das OS als Oberguru seiner Hardware ändert das jetzt und die Karte beschwert sich. Linux in seiner gnadenlosen Offenheit macht diese Beschwerde jetzt auch noch öffentlich ;-) hmm jo, wobei man auf den karten selbst nichts ändern kann, womöglich ist es doch das bios; ich probier heute nacht mal ein update (währenddessen kommt nur ein rechner ins Inet :-( )... ok, das ist auch eine idee - ich werde mal schauen ob ich irgendwo ein update finde :-) Da du den Hersteller/Bezeichnung deines Boards ja nicht kennst kannst ok, ich hab mal einiges ausprobiert und auch herausgefunden. das Mainboard ist ein FIC VB-601-V: http://www.fic.com.tw/product/motherboard/1stmainboard_detail.aspx?type=lega cymodel_id=15 die bios-update seite dafür ist leider etwas widersinnig - version 1.3 ist bspw. neuer als 2 der versionen 1.4, momentan ist das bios mit 1.3 bespielt, ich flashe mal die nach dem datum neuste 1.4er version. Vielleicht hast du ja auch mISDN bzw. capi-seitig noch nicht alles aktiviert im Kernel. Es muß doch zu mISDN in /usr/share/doc doch eine Readme geben, wo die Konfiguration beschrieben ist? hmm ich bin eigentlich (zumindest bei mISDN, bei VoIP gabs probleme, debian-lib zu alt ...) im rahmen des tutorials der pbx ( http://isdn.jolly.de ) vorgegangen, bei 2.6.7 hat es so funktioniert - bei 2.6.8 nicht ich gehe das tut nochmals schritt für schritt durch, falls das problem nicht mit den IRQs zusammenhängen sollte, mache ich evtl. einen seperaten thread dafür auf Was war das doch gleich für ein Board? Mach mal bitte ein dmidecode... hmm dmidecode ? ich habe über apt-file im paket ipmi-controlein dmidecode gefunden, installiert und aufgerufen. hier ist die ausgabe: server:~# dmidecode SMBIOS present. DMI 2.0 present. 32 structures occupying 2123 bytes. DMI table at 0x000F568E. Handle 0x DMI type 0, 19 bytes. BIOS Information Block Vendor American Megatrends, Inc. Version 0627 Release 11/18/98 BIOS base 0xF ROM size 192K Capabilities: Flags: 0x7FC9DE90 Handle 0x0001 DMI type 1, 25 bytes. System Information Block Vendor System Manufacturer Product System Name Version System Version Serial Number SYS-9876543210 Handle 0x0002 DMI type 2, 8 bytes. Board Information Block Vendor FIRST INTERNALTIONAL COMPUTER Product VB-601-V Version VER:1.3 Serial Number 1234567890 Handle 0x0003 DMI type 3, 13 bytes. Chassis Information Block Vendor System Manufacturer Product System Version Version System Version Serial Number SYS-00 Asset Tag ASS-9876543210 Handle 0x0004 DMI type 4, 32 bytes. Handle 0x0005 DMI type 5, 24 bytes. Handle 0x0006 DMI type 6, 12 bytes. Memory Bank Socket: DIMM 1 Banks: 0 1 Type: Installed Size: 64Mbyte Enabled Size: 64Mbyte Handle 0x0007 DMI type 6, 12 bytes. Memory Bank Socket: DIMM 2 Banks: 2 3 Type: Installed Size: 128Mbyte (Double sided) Enabled Size: 128Mbyte (Double sided) Handle 0x0008 DMI type 6, 12 bytes. Memory Bank Socket: DIMM 3 Banks: 2 3 Type: UNKNOWN Installed Size: Not Installed Enabled Size: Not Installed Handle 0x0009 DMI type 6, 12 bytes. Memory Bank Socket: DIMM 4 Banks: 2 3 Type: UNKNOWN Installed Size: Not Installed Enabled Size: Not Installed Handle 0x000A DMI type 7, 19 bytes. Cache Socket: L1 Cache L1 Internal Cache: write-back L1 Cache Size: 32K L1 Cache Maximum: 32K L1 Cache Type: Synchronous Handle 0x000B DMI type 7, 19 bytes. Cache Socket: L2 Cache L2 Internal Cache: write-back L2 Cache Size: 512K L2 Cache Maximum: 512K L2 Cache Type: Synchronous Handle 0x000C DMI type 8, 9 bytes. Handle 0x000D DMI
Re: irq routing conflict - einige varianten
Christoph Klein wrote: ok, ich hab mal einiges ausprobiert und auch herausgefunden. das Mainboard ist ein FIC VB-601-V: http://www.fic.com.tw/product/motherboard/1stmainboard_detail.aspx?type=lega cymodel_id=15 die bios-update seite dafür ist leider etwas widersinnig - version 1.3 ist bspw. neuer als 2 der versionen 1.4, momentan ist das bios mit 1.3 bespielt, ich flashe mal die nach dem datum neuste 1.4er version. PCB Ver. ist nicht die BIOS-Version, sondern die Version des Platinenlayouts. Du scheinst laut dmi Version 1.3 zu haben, aber ohne Garantie! Schau lieber aufs MB, da steht das auch drauf. -- Mit freundlichen Gruessen Bjoern Schmidt -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: irq routing conflict - einige varianten
Björn Schmidt wrote: momentan ist das bios mit 1.3 bespielt, ich flashe mal die nach dem datum neuste 1.4er version. Nimm nicht die 1.4er! NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT. Bitte. -- Mit freundlichen Gruessen Bjoern Schmidt -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: irq routing conflict - einige varianten
Hallo Liste, Nimm nicht die 1.4er! NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT. hmm ok, habe es noch nicht getan *g* da du glücklicherweise so intensiv davor warnst, vermute ich, dass das möglicherweise eine art Bios-GAU gegeben hätte... Bitte. dann mal danke für die warnung ;-) PCB Ver. ist nicht die BIOS-Version, sondern die Version des Platinenlayouts. Du scheinst laut dmi Version 1.3 zu haben, aber ohne Garantie! Schau lieber aufs MB, da steht das auch drauf. ok, hab ich, folgendes erscheint mir evtl. sinnvoll: - aufkleber: QC614S2s - aufkleber: 1909 - aufkleber: VB-601-V meinst du, dass man keine version 1.4 aufspielen sollte, weil diese alle für die QF* ausführungen, nicht die QC* sind ? mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: irq routing conflict - einige varianten
Christoph Klein wrote: ok, hab ich, folgendes erscheint mir evtl. sinnvoll: - aufkleber: QC614S2s - aufkleber: 1909 - aufkleber: VB-601-V Nee, Aufkleber sind nicht sinnvoll. Die Nummer die ich meine ist meistens wie die Leiterbahnen in die Grundplatte eingeätzt und sieht dementsprechend aus. Sie hat immer das Format PCBx.x, bzw. PCB x.x meinst du, dass man keine version 1.4 aufspielen sollte, weil diese alle für die QF* ausführungen, nicht die QC* sind ? Nein, Du hast es noch nicht verstanden. Die PrintedCircuitBoard-Nummer PCB steht für die Version der Hardware, nicht für die des BIOS! Es gibt keine BIOS-Version 1.4 die Du aufspielen kannst, die BIOS Versionsnummern beginnen alle mit Q. BIOS QB* für Hardware PCB1.1 BIOS QC* für Hardware PCB1.3 BIOS QF* für Hardware PCB1.4 Da die Hardware unterschiedlich ist (PCB1.3 != PCB1.4), gibt es auch unterschiedliche BIOS-Images. Das ist nicht zwangsläufig immer so, es hängt halt von den HW-Unterschieden ab. Dein Board aber braucht das zur PCB Nummer passende BIOS, ansonsten _kann_ es passieren dass Du es unbrauchbar machst... -- Mit freundlichen Gruessen Bjoern Schmidt -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: irq routing conflict - einige varianten
Gruesse! * Christoph Klein [EMAIL PROTECTED] schrieb am [18.09.04 20:24]: Es *kann* doch einfach so sein: Zum Zeitpunkt, wo das BIOS die Hardware initialisiert, ist wesentlich weniger Hardware aktiv als zum Zeitpunkt, an dem das Betriebsystem die Hardware übernimmt. das wäre noch eine Möglichkeit ... ich deaktiviere in einem neuen Kernel mal soviel hardware wie möglich. Hm, das verstehe ich jetzt nicht. Treiber bzw. Module für nicht vorhandene Hanrdware sollte in einen selbstgebauten Kernel eh nicht sein. Wenn du Hardware deaktivierst für Hardware die du brauchst, hast du ein Problem. Wenn du aber kein Problem hast, brauchst du die Hardware nicht... Oder auf den Karten-Chips sind irgendwelche Voreinstellungen/Wünsche (setze mich bitte auf IRQ xyz, bei ISA-Karten gab es das mal). Das OS als Oberguru seiner Hardware ändert das jetzt und die Karte beschwert sich. Linux in seiner gnadenlosen Offenheit macht diese Beschwerde jetzt auch noch öffentlich ;-) hmm jo, wobei man auf den karten selbst nichts ändern kann, womöglich ist es doch das bios; Ändern kannst du nur durch Umstecken erreichen, das hatten wir ja schon. Und klar, nur BIOS und OS können das von der Softwareseite her ändern. Das BIOS hat aber keine /var/log/syslog wo es evtl. Unstimmigkeiten kundtun könnte, das OS deiner Wahl aber schon. Das meinte ich damit. ich probier heute nacht mal ein update (währenddessen kommt nur ein rechner ins Inet :-( )... Gut, aber BIOS-Update ist für mich immer eine der letzten Möglichkeiten, wenn nichts mehr hilft. Immer noch mein Vorschlag: NICs ausbauen, ISDN-Karten zum Funktionieren bringen, NICs wieder einbauen. IMHO hast du erst dann ein wirkliches Problem, wenn z.B. die NIC/ISDN-Karten Kombination seperat funktioniert aber im Zusammenspiel nicht. Kannst du dazu eine definitive Aussage machen? Und noch mal ganz zurück an den Anfang. Warum kannst du nicht bei 2.6.7 bleiben wenn es da doch funktioniert? 2.6.8 soll doch, was ich so lese, als Revision nicht unumstritten sein was die Änderungen betrifft. Und wenn schon 2.6.8 sein muß, dann würde ich mir testweise auch ein fertiges Deb dafür ziehen, deine Kernel-Source überprüfen ob es dafür nicht schon ein Update vom Maintainer gibt und/oder evtl. auch mal einen Vanilla-Source von kernel.org versuchen. Vielleicht hast du ja auch mISDN bzw. capi-seitig noch nicht alles aktiviert im Kernel. Es muß doch zu mISDN in /usr/share/doc doch eine Readme geben, wo die Konfiguration beschrieben ist? hmm ich bin eigentlich (zumindest bei mISDN, bei VoIP gabs probleme, debian-lib zu alt ...) im rahmen des tutorials der pbx ( http://isdn.jolly.de ) vorgegangen, bei 2.6.7 hat es so funktioniert - bei 2.6.8 nicht ich gehe das tut nochmals schritt für schritt durch, falls das problem nicht mit den IRQs zusammenhängen sollte, mache ich evtl. einen seperaten thread dafür auf Gut, oder setze lieber noch tiefer an. Also nur versuchen, mit mISDN (ich muß mich doch mal langsam damit beschäftigen) die Karte(n) zu initialisieren und eine Wählverbindung zu irgendeinem Provider herzustellen. Dazu *muß* es in mISDN eine Readme/Howto geben. mfg christoph Gruß Gerhard
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
Re: irq routing conflict - einige varianten
Christoph Klein wrote: 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 Naja, das kommt auf den Betrachtungswinkel an. Irgendwie hängt es schon zusammen, aber nicht sehr stark. IS funktioniert auch ohne ACPI, klar. aktivierung im kernel nutzlos ist - wie aktiviert man IRQ-sharing dann ? Gar nicht. Die Frage ist eher, wie kann man es vermeiden? Auf jedem gängigen PCI basierten System sind Shared Interrupts das normalste der Welt und lassen sich praktisch gar nicht vermeiden, es sei denn man hat einen IO-APIC. Damit stehen dann mehr IRQs zur Verfügung, mit den beiden cascadierten 8259a hat man ja nur 15. Die local APIC hat auf auf einem UP System _ohne_ IO-APIC nichts mit Interupts für Peripherie zu tun, die kannst Du also gerne aktiv lassen. Ob ein Treiber shared interrupts NICHT unterstützt kannst Du schnell herausfinden, nämlich indem Du in seiner Quelldatei nach SA_SHIRQ grepst und es nicht findest. -- Mit freundlichen Gruessen Bjoern Schmidt -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: irq routing conflict - einige varianten
Gruesse! * Christoph Klein [EMAIL PROTECTED] schrieb am [16.09.04 17:38]: 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 ? Ja, so ungefähr. Ich habe hier z.B. einen Dual-PentiumPro Server, der ein IRq-Sharing (oder besser Neuverteilung) machen kann weil das sowohl die Hardware-APIC wie auch das OS nutzen, also IRQs 15. Oftmals trifft man das auch bei Uni-Prozessor-Systemen v.a. mit Windows 2K/XP, wenn nach der Installation *alle* PCI-Hardware auf einem IRQ liegen, obwohl der Rest auch frei ist. Dazu hat Björn dir ja auch schon was geschrieben. Da du bei dem PC ja auch eine etwas betagtere Hardware einsetzt (ich werkele hier z.B. auch noch mit meinem K62/350 rum, glücklich und zufrieden!) wäre es auch noch mal eine Überlegung, über ein BIOS-Update nachzudenken. Evtl. behebt ein Update eine mangelhafte BIOS-Implementation im Bereich PCI-Bus. 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 System.map liegt nach dem Kompilieren in /usr/src/linux. Per Hand nach boot kopieren (make-kpkg nimmt dir das ab ;-). Genutzt und wichtig ist die IMHO beim Debuggen. Negativ im normlen Betrieb? Hm, ich hatte noch nie Kernel ohne die System.map. Müßte ich noch mal in die Doku schauen. 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 ;-) Gut, da kann ich garnichts zu sagen. Aber das sich die Module laden lassen und die IRQ/IO-Verteilung funktioniert macht eigentlich Hoffunng. Ich kenne halt auch weder die HFSs noch mISDN. Um sicherzugehen, ob die Karten wegen einen IRQ/IO-Konflikts *nicht* funktionieren, würde ich ggf. mal den umgekehrten Weg gehen und zeitweise die beiden NICs ausbauen. Dann die ISDN-Karten und mISDN so einrichten, das sich sagen wir mal ein Wahlvorgang auslösen läßt. Oder es gibt bei mISDN ein Tool wie z.B. capiinfo bzw isdnctrl bei Hisax zum Überprüfung des Status. pbx setzt ja scheinbar ein funktionierendes mISDN voraus, fällt als Test deshalb IMHO flach. Bei Nicht-Funktionieren würde ich einen eigenen Thread zu mISDN aufmachen. Wenn es funktioniert, würde ich eine oder beide NICs wieder einbauen und dann schauen, ob es immer noch geht. 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 ;-) Hm, auch da kann ich dir nichts sicheres sagen. Aber ich meine, ich konnte mit einem Versuchs-Kernel-2.6 und den neuen modultils trotzdem mit modconf Module laden und entladen. Ist aber schon länger her. Vielleicht kann dazu jemand der Woody+modutils+Kernel-2.6 einsetzt was genaues sagen? mfg vielen dank christoph Gruß Gerhard
Re: irq routing conflict - einige varianten
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: 0bfe - 0bff8000 (ACPI data) Sep 13 14:54:00 server kernel: BIOS-e820: 0bff8000 - 0c00 (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
Re: irq routing conflict - einige varianten
Gerhard Brauer wrote: 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. Nee, wieso? Auch wenn ihr die einzigen seid die schreibt gibt es sicher einige die nur lesen. Warum also verdrücken? Und warum hat es nichts mit Debian zu tun? -- Mit freundlichen Gruessen Bjoern Schmidt -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: irq routing conflict - einige varianten
Gruesse! * Björn Schmidt [EMAIL PROTECTED] schrieb am [14.09.04 12:20]: Nee, wieso? Auch wenn ihr die einzigen seid die schreibt gibt es sicher einige die nur lesen. Warum also verdrücken? Und warum hat es nichts mit Debian zu tun? Nun, in einer moderierten Liste wäre das OffTopic - Rüffel, Ausschluß, Vierteilen, Mailbombem von Michelle, 3-Wochen-Windows-Zwangsbenutzung... ;-) Ich schlage eigentlich immer dann weitere Diskussion per PM vor, wenn für mich ersichtlich ist das es: a) nichts Debian-spezifisches ist. Christophs Problem hätte genausogut unter Suse, Win,... auftreten können. b) das meistens recht lange Threads werden und eine Lösung meist so speziell ist (weil das Problem ein User/Hardware-spezifisches ist) das der Nutzen für andere *Debian*-Nutzer gering ist, außer vielleicht c) allgemeine Linux-Themen/Tips abgehandelt werden, die aber im Internet sicher auch dokumentiert sind. Aber klar, kein Verdrücken ;-) *Ich* habe PM schließlich angeboten, der Bjoern ist jetzt *schuld* wegduck, grins ;-)) Mit freundlichen Gruessen Bjoern Schmidt Gruß Gerhard
Re: irq routing conflict - einige varianten
Gruesse! Eine Bitte vorweg: könntest du eventuell bei weiteren Mails großzügiger mit Absätzen umgehen und vielleicht auch Groß/Kleinschreibung benutzen? Gerade bei langen Absätzen mit vielen Halbsätzen und Klammern habe zumindest ich Probleme dem Inhalt zu folgen ;-) * Christoph Klein [EMAIL PROTECTED] schrieb am [12.09.04 17:40]: hallo liste, Versuch mal am lilo(grub boot-prompt den Parameter pci=biosirq sorry, hat leider nichts bewirkt, es kommt weiterhin ein irq routing conflict Auch die anderen Parameter zu pci,apic,acpi sind für dich von Interesse. Siehe Dokumentation zu deinem Kernel, kernel-parameters.txt acpi=noirq habe ich mal probiert, der kernel zeigt sich jedoch auch davon unbeeindruckt. um ganz sicher zu gehen, habe ich den kernel nochmals komplett ohne acpi kompiliert, das problem tritt jedoch weiterhin auf. warum will der linux kernel andere irqs zuordnen, bringt einen routing conflict, obwohl die karten mit den bios-irqs dann funktionieren ? Wie hast du den Kernel kompiliert? Debian-konform mit make-kpkg oder per Hand (mit make ...)? Hast du für Woddy auch die neuen module-init-tools, die für den 2.6.x Kernel benötigt werden, installiert (z.B. von www.backports.org)? da hier acpi, apm, apic (ist das dasselbe wie acpi ?) und pnp involviert zu sein scheinen, stellt sich die frage, ob man das hier überhaupt braucht - mir reicht ein minimales system, das die vom bios zugewiesenen irqs verwendet, braucht also kein irq sharing zu machen, braucht keine acpi-features zu unterstützten, braucht nicht automatisch auszugehen, lediglich am automatischen abschalten der festplatte nach inaktivität bin ich interessiert. APM und ACPI dienen beide dem Power-Management. ACPI findet sich in neueren PCs/BIOSen und bietet mehr Möglichkeiten. PnP betrifft die automatische Konfiguration von ISA-Karten, im Gegensatz zur Konfig mit Jumpern (PlugAndPlay oder PlugAndPray, wie man will...). Keine ISA-Karten, keine PnP-Unterstützung nötig. APIC ist IMHO ein erweitertes Resourcen-Management, urspünglich dafür gedacht um Mehrprozessor-Systemen den geregelten Zugriff auf die Hardware(-IRQs) zu gewähren. Dabei werden die BIOS-seitig beschränkten IRQ/IO-Adressen logisch erweitert und umgeleitet (routing). Ist mittlerweile auch bei neueren Single-CPU-Systemen implementiert. Zur Kernel-Konfig: # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set CONFIG_M586MMX=y Ich bin mir nicht sicher ob dein PII (ist ein PII 350Mhz ?) schon MMX unterstützt. cat /proc/cpuinfo gibt dir bei Flags Auskunft darüber. Evtl. ist # CONFIG_MPENTIUMII is not set die bessere Wahl. Ist IMHO aber eher Nebensache. CONFIG_SMP=y Würde ich disablen. Gerade bei älteren Boards/CPUs kann aktivierte SMP-Untestützung Probleme bereiten. CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y Du schriebst, du hättest deinen Kernel ohne APIC kompiliert. Hier ist es aber noch ativiert ? Würde ich abschalten, da dein BIOS sowieso kein APIC kann, s.u. # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_SOFTWARE_SUSPEND is not set CONFIG_PM_DISK=y CONFIG_PM_DISK_PARTITION= # # ACPI (Advanced Configuration and Power Interface) Support # # CONFIG_ACPI is not set Ist ok, dein BIOS ist IMHO nicht ACPI-fähig. CONFIG_ACPI_BOOT=y # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set Must du einschalten, wenn du (APM)-Powermanagement für Festplatten und Abschalten benutzen wilst. # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCI_MSI is not set CONFIG_PCI_LEGACY_PROC=y CONFIG_PCI_NAMES=y Ich kenne den 2.8.-Kernel nicht sehr gut, aber zu diesen Optionen würde ich mir die Hilfe mal durchlesen, ob da welche nicht dein Problem berühren. Bei Unklarheit lieber die Default-Werte nehmen. Zum Logfile: /var/log/kern.log Sep 12 15:49:17 server kernel: klogd 1.4.1#10, log source = /proc/kmsg started. Sep 12 15:49:17 server kernel: Cannot find map file. Sep 12 15:49:17 server kernel: No module symbols loaded - kernel modules not enabled. Hm, das macht mich stutzig. Hast du die zu deinem Kernel passende System.map auch nach /boot installiert (wenn mit make bzImage gebaut) ? Diese Meldung und evtl. Probleme mit Modulen *könnten* mit dem Fehlen der Map-Datei zusammenhängen. Sep 12 15:49:17 server kernel: ACPI disabled because your bios is from 98 and too old Sep 12 15:49:17 server
Re: irq routing conflict - einige varianten
Hallo Liste, Eine Bitte vorweg: könntest du eventuell bei weiteren Mails großzügiger mit Absätzen umgehen und vielleicht auch Groß/Kleinschreibung benutzen? ok, ich versuche mein bestes ;-) 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 ;-) Hast du für Woddy auch die neuen module-init-tools, die für den 2.6.x Kernel benötigt werden, installiert (z.B. von www.backports.org)? genau, die module-init-tools von backports.org. APM und ACPI dienen beide dem Power-Management. ACPI findet sich in neueren PCs/BIOSen und bietet mehr Möglichkeiten. PnP betrifft die automatische Konfiguration von ISA-Karten, im Gegensatz zur Konfig mit Jumpern (PlugAndPlay oder PlugAndPray, wie man will...). Keine ISA-Karten, keine PnP-Unterstützung nötig. Vielen Dank für diese info :-) ich dachte bisher, dass das noch irgendetwas mit pci-Karten zu tun hat - werde ich nun abgeschalten (Kernel Image wieder etwas kompakter ...) APIC ist IMHO ein erweitertes Resourcen-Management, urspünglich dafür gedacht um Mehrprozessor-Systemen den geregelten Zugriff auf die Hardware(-IRQs) zu gewähren. Dabei werden die BIOS-seitig beschränkten IRQ/IO-Adressen logisch erweitert und umgeleitet (routing). Ist mittlerweile auch bei neueren Single-CPU-Systemen implementiert. 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 ? Also kann, wenn APIC verfügbar ist (ist ACPI hierbei erforderlich?), das Bios auch (also nur in der Tabelle während des Bootvorgangs) virtuelle IRQs 15 vergeben ? oder kann das IRQ 15 generell nur das Betriebssystem, also das Bios nicht ? bzw. ist aus Sicht des Betriebssystems nur ACPI nötig (also APIC optional) - oder umgekehrt - oder braucht man beides -um diese IRQs 15 vergeben zu können ? Abgesehen von APIC - funktioniert IRQ _sharing_ selbst andererseits nur, wenn ACPI vom Kernel unterstützt wird ? Falls ja, dann wäre ja der =IRQ sharing Bestandteil= von ACPI möglicherweise eine rein softwareseitige Erweiterung. Also es wäre kein spezielles Bios mit ACPI Unterstützung nötig, um wirklich nur IRQ sharing (im Gegensatz zu anderen Bestandteilen von ACPI, beispielsweise Standby-Modus, wo ja auch das Bios es unterstützen muss) nutzen zu können. Das wäre wirklich hilfreich, wenn man den Zusammenhang zwischen APIC und ACPI und deren Bestandteilen genau wüsste ;-) Ich bin mir nicht sicher ob dein PII (ist ein PII 350Mhz ?) schon MMX unterstützt. cat /proc/cpuinfo gibt dir bei Flags Auskunft darüber. Evtl. ist # CONFIG_MPENTIUMII is not set die bessere Wahl. Ist IMHO aber eher Nebensache. okay, habe ich eingestellt (hatte ursprünglich nur pentium MMX gewählt, um eine größere Kompatibilität des Kernels zu ermöglichen, aber aufgrund der zahlreichen Tuningmöglichkeiten, deren genaue Bedeutung ich jetzt erst im Nachhinein erfahren kann, scheint das keine gute Idee gewesen zu sein ) CONFIG_SMP=y Würde ich disablen. Gerade bei älteren Boards/CPUs kann aktivierte SMP-Untestützung Probleme bereiten. ok, ist deaktiviert (.. und das Kernelimage um einies kleiner ;-)) CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y Du schriebst, du hättest deinen Kernel ohne APIC kompiliert. Hier ist es aber noch ativiert ? Würde ich abschalten, da dein BIOS sowieso kein APIC kann, s.u. sorry, hatte einfach mal mit den Parametern irgendwie rumprobiert, da ich nicht genau wusste, was genau sie eigentlich bewirken, also deaktiviert ist es inzwischen :-) Ist ok, dein BIOS ist IMHO nicht ACPI-fähig. hmm... bedeutet das, dass auch kein IRQ sharing möglich ist ? CONFIG_ACPI_BOOT=y # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set Must du einschalten, wenn du (APM)-Powermanagement für Festplatten und Abschalten benutzen wilst. okay, vielen dank - zumindest beim herunterfahren schaltet er die Festplatte inzwischen ab und der Rechner schaltet sich auch automatisch ab - also auch das scheint wohl ein Bestandteil von APM zu sein. # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCI_MSI is not set
Re: irq routing conflict - einige varianten
hallo liste, Versuch mal am lilo(grub boot-prompt den Parameter pci=biosirq sorry, hat leider nichts bewirkt, es kommt weiterhin ein irq routing conflict Auch die anderen Parameter zu pci,apic,acpi sind für dich von Interesse. Siehe Dokumentation zu deinem Kernel, kernel-parameters.txt acpi=noirq habe ich mal probiert, der kernel zeigt sich jedoch auch davon unbeeindruckt. um ganz sicher zu gehen, habe ich den kernel nochmals komplett ohne acpi kompiliert, das problem tritt jedoch weiterhin auf. warum will der linux kernel andere irqs zuordnen, bringt einen routing conflict, obwohl die karten mit den bios-irqs dann funktionieren ? da ich die de4x5-karte ausgebaut habe, muss ja das modul nicht mehr geladen werden, der kernel 2.6.8.1 probiert es aber beim booten immer, also habe ich einfach die .ko datei gelöscht, nun kommt (voraussehbar) not found. da modconf nicht funktioniert (leere liste,update-modules bringt nichts, warum auch immer) habe ich selbst in /etc/modprobe.conf (welche auf /lib/modules/modprobe.conf verweist (include)) geschaut, ob hier ein verweis auf de4x5 zu finden war - fehlanzeige. nun stellt sich die frage, warum der kernel de4x5 weiterhin laden will - gibt es da noch weitere dateien ? (ich verwende keine initrd) bei der realtek karte ist genau das gegenteil der fall. ich muss das modul immer mit insmod kompletter pfad zu 8139too.ko laden, modprobe 8139too kann man zwar eingeben, doch es passiert nichts, laut lsmod wird das modul nicht geladen, es kommt aber auch kein fehler bei modprobe. weiterhin bringt ein eintrag in der modprobe.conf nichts, also install rtl8139 /bin/true wird auch keine beachtung geschenkt. beim laden von mISDN kommen übrigens auch die routing-probleme, die karten funktionieren aber. da hier acpi, apm, apic (ist das dasselbe wie acpi ?) und pnp involviert zu sein scheinen, stellt sich die frage, ob man das hier überhaupt braucht - mir reicht ein minimales system, das die vom bios zugewiesenen irqs verwendet, braucht also kein irq sharing zu machen, braucht keine acpi-features zu unterstützten, braucht nicht automatisch auszugehen, lediglich am automatischen abschalten der festplatte nach inaktivität bin ich interessiert. weiterhin ist mir auch bei anderen systemen aufgefallen, dass der kernel manchmal automatisch bemerkt, wenn neue hardware eingebaut wurde und dann das passende modul lädt, wenn es denn vorhanden ist. warum ist das hier mit der realtek karte nicht so ? ich habe mal teile aus der kern.log und meine kernelkonfiguration angehängt, vielleicht hilft das weiter. falls ein debuggen im rahmen von emails hier nicht möglich ist, könnte ich auch das root-passwort mit ssh zugang(nicht auf der liste direkt*g*) zur verfügung stellen. mfg christoph /proc/interrupts: CPU0 0: 1401797 XT-PIC timer 1: 656 XT-PIC i8042 2: 0 XT-PIC cascade 9: 35 XT-PIC HFC PCI 10: 1 XT-PIC HFC PCI 11: 113 XT-PIC eth0 12: 72 XT-PIC eth1 14: 5374 XT-PIC ide0 15: 16 XT-PIC ide1 NMI: 0 LOC: 1401769 ERR: 2 MIS: 0 /usr/src/linux/.config # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y # # General setup # CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_LOG_BUF_SHIFT=15 CONFIG_HOTPLUG=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set CONFIG_M586MMX=y # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_PPRO_FENCE=y CONFIG_X86_F00F_BUG=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y
irq routing conflict - einige varianten
Hallo Liste, ich habe ein problem mit 2 pci netzwerkkarten in einem rechner mit woody als OS bekomme beim laden eines moduls einen irq routing conlict - ich habe schon einiges an steckplatz-vertauschen durchprobiert, jedoch komme ich einfach nicht weiter. das system ist so aufgebaut: AGP - IRQ9 RivaTNT === PCI 1 - IRQ9-- leer -- === PCI 2 - IRQ10 --- ISDN #1 --- (HFC-S, mISDN) === PCI 3 - IRQ11 --- ISDN #2 --- (HFC-S, mISDN) === PCI 4 - IRQ12 --- LAN #1 --- (Davicom DM9102AF, modul: tulip/dmfe ) === PCI 5 - IRQ9 LAN #2 (digital 21143-PD/davicom DM9101F (2 chips drauf, aber ein RJ45-port), modul: tulip/de4x5 ) das sind die interrupts, wie sie das bios den pci steckplätzen anfangs zuteilt (in der pci-tabelle sichtbar während des bootvorgangs) und welche karten anfangs in welchem steckplatz waren - was mit kernel 2.6.7 (und 2.4.18) auch funktioniert hat. da aber bei pbx4linux 2.4 ein unangenehmes echo beim telefonieren auftrat das t-com sinus telefon sich hingegen dem siemes oft aufhängte beim auflegen (batterie raus, rein) entschied ich mich, die neue pbx4linux 2.5 mit neuerem mISDN Treiber und neuem kernel 2.6.8.1 zu installieren - in der hoffung, dass die probleme behoben sind. Also kernel-source geladen, konfiguriert, kompiliert und gebootet - aber er hängt bei autoconfiguring network devices, kein vorankommen mehr, strg+c hilft auch nicht. Ich schaute also in der kern.log nach, und sah, dass LAN#2 einige meldungen brachte beim modul-laden - using Mii-controller, if the device won't work mail to etc nunja, die netzwerkkarte funktionierte nicht (wahrscheinlich deswegen der hänger bei autoconfiguring ...)- also baute ich sie aus - und das booten mit 2.6.8.1 klappte. daraufhin baute ich die karte wieder ein, und testete mit dem debian 2.4.18-bf24 kernel, dieser bootete und ich konnte beide karten wieder verwenden - wie auch beim 2.6.7 (obwohl die mii-meldung weiterhin kam), beim 2.6.8.1 geht es jedoch nicht. da die karte auf IRQ 9 lag (pci 5), schaltete ich im bios einfach assign irq to vga ab - aber es änderte nichts an diesem sachverhalt. das wäre schon etwas, was mich brennend interessieren würde - wie ist sowas denn möglich - bug in 2.6.8.1 ? Als ich die kern.log durchschaute, war auch ein irq routing conflict von LAN#1 erkennbar - das gerät lief, wie auch vom bios angezeigt, auf IRQ12 - aber der kernel meinte (kern.log) wants IRQ 9 - diese meldung erschien bei allen kernelversionen, war mir bis dahin aber nicht aufgefallen, weil die karte problemlos funktionierte - trotz angezeigtem irq routing conflict. im bios ist plug play aware OS auf no gestellt - ich weiß zwar nicht, was das bewirkt und ob die einstellung generell bei linux korrekt ist, nur bei dieser konfiguration korrekt ist bzw. es überhaupt bei linux so eingestellt sein sollte - ich hatte nur etwas von der einstellung im zusammenhang mit pci karten, irq problemen und plug play gelesen - vielleicht ist sie also hier relevant. das mainboard hat zwar isa steckplätze, jedoch ist bei jedem interrupt pci/pnp eingestellt. nun, da die karte LAN#1 auf IRQ9 wollte (warum auch immer) baute ich sie in PCI 5 ein (LAN#2 ausgebaut) - sie (LAN#1) war zwar nun auf IRQ9, aber es gab wieder einen routing conflict; sie wollte nun interessanterweise auf IRQ11. Also habe ich ISDN#2 ausgebaut (PCI 3)und dort die netzwerkkarte rein - hier hat dann das modul ohne probleme geladen - auf irq 11, problem (anscheinend) gelöst. lan #2 funktionierte bei 2.6.8.1 aber weiterhin nicht. also probierte ich als LAN#2 eine rtl8139D auf PCI#5 aus. zunächste einmal kernel 2.6.8.1 gebootet - bei diesem jedoch hatte ich die gesamte kategorie für pci/onboard netzwerkkarten NICHT mit einkompiliert, also auch die darin enhaltenen realtek-module waren nicht verfügbar, da vorher beides karten waren (dmfe, de4x5), die in der tulip kategorie bei menuconfig zu finden sind, also NICHT unter pci/onboard netzwerkkarten, aber trotzdem unter ethernet 10/100mbit. der kernel kannte also die rtl8139d karte nicht. doch - man kann es schon fast ahnen *g* - LAN#1 wurde zwar nun ohne routing conflict geladen, war jedoch auf IRQ 0 (?!?) und funktionierte nicht (egal ob im bios assign irq to vga an oder aus war). also die neue LAN#2 (rtl8139d) in den PCI 4 statt PCI 5 und nochmals gebootet (2.6.8.1) - wieder ein irq routing conflict, LAN#1 war auf irq 11 und wollte jetzt auf (*würfel*...) irq 10, also zu ISDN#1. ISDN#2 war während dieser versuche ausgebaut. da mir das probieren nun echt zuviel wird, die karten vom bios zwar sauber angeordnet werden zu den IRQs, aber unter linux auf einmal was anderes machen wollen, denke ich, dass abgesehen vom probieren ein logisches vorgehen sinnvoll wäre. da es aber bei mir zuviele unbekannten gibt - wie, - was acpi mit interrupts verteilen zu tun hat - was es bewirkt, PNP im kernel zu aktivieren - welche einstellung im plug play aware OS wann korrekt ist - wie und wann bzw. ob linux IRQ sharing unterstützt (braucht man acpi,
Re: irq routing conflict - einige varianten
Gruesse! * Christoph Klein [EMAIL PROTECTED] schrieb am [12.09.04 00:14]: Nur ganu kurz, weil ich jetzt keine Zeit habe: - warum der kernel die (sauberen) bios einstellungen nicht einfach übernimmt Versuch mal am lilo(grub boot-prompt den Parameter pci=biosirq Auch die anderen Parameter zu pci,apic,acpi sind für dich von Interesse. Siehe Dokumentation zu deinem Kernel, kernel-parameters.txt schonmal vielen dank, falls jemand eine idee hat :-) mfg christoph Gruß Gerhard
