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 auskommentiert....es 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 0000:00:0a.0
Sep 19 18:36:09 server kernel: IRQ routing conflict for 0000: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 0000:00:0b.0
Sep 19 18:36:09 server kernel: IRQ routing conflict for 0000:00:0b.0, have
irq 11, want irq 12
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 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 50000us
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
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 50000us
Sep 19 18:36:09 server kernel: HFC PCI: IRQ(11) getting no interrupts during
init 2
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:10 server kernel: HFC-PCI status(ff) after 50000us
Sep 19 18:36:10 server kernel: inithfcpci: entered
Sep 19 18:36:10 server kernel: HFC PCI: IRQ 11 count 0
Sep 19 18:36:10 server kernel: HFC PCI: IRQ(11) getting no interrupts during
init 3
Sep 19 18:36:10 server kernel: try_ok(4) try_wait(0) try_mult(0)
try_inirq(0)
Sep 19 18:36:10 server kernel: irq_ok(0) irq_fail(0)
je nach steckplatz der karten kommt ein-oder 2mal irq_fail(0) - hier also
ein bsp. mit nur einem "fehler" - habe viele
möglichkeiten durchprobiert.
> 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.
hmm jo, hab sowas noch nie gemacht *g* nutze die karten nur zum telefonieren
über die pbx.
internet geht über dsl (deswegen die 2 netzwerkkarten).
> 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.
da könntest du recht haben, ich bin nach 2 wochen kompilieren und umstecken
und probieren und
kompilieren, umstecken, probieren, kompilieren, kompilieren .... etc pp.
langsam etwas frustriert *g*
> Hast Du mittlererweile die PCI-Karten ein wenig permutiert?
jo, also bisher max. eine isdnkarte & eine netzwerkkarte ohne routing
conflict....
falls auch das biosupdate nichts hilft, werde ich wohl das board tauschen
müssen - und falls
selbst das an der lage nichts ändert - naja gibts eine architektur wo jedem
steckplatz ganz simpel und
ohne extras sauber ein interrupt zugeordnet ist ?
Eine Frage am Rande noch, was ist ein "HZ Value" ?
falls jmd. von euch selbst etwas probieren will, wäre das kein problem (PM).
mfg & thx
christoph
Reply to: