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 -- 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)
