May 2006 - openSUSE ISDN (Deutsch) - openSUSE Mailing Lists

Probleme mit capi4hylafax und Hylafax
by info＠abacus-computer.net 10 May '06

10 May '06

Hallo Liste, Ich habe auf meinem Server eine Primux 1S2M fuer einen PMA. Ich versuche auf diesem Server capi4hylafax und Hylafax zum laufen zu bringen. Beides scheint auch zu funktionieren. Ich kann mit c2faxrecv Faxe empfangen und auch mit c2faxsend Faxe versenden. Ich muss aus mehreren Gruenden aber sendfax benutzen. Obwohl Hylafax laeuft findet scheinbar keine Verbindung zwischen capi4hylafax und Hylafax statt. Ich bekomme mit faxaddmodem keine Modems eingebunden, da in /dev keine entsprechenden Devices vorhanden sind. Ich finde aber nirgendwo einen Hinweis, wie diese Devices erzeugt werden koennen. Und dann habe ich da noch seltsame Eintragungen in /var/log/messages. Ich habe mal ein paar Zeilen hier eingetragen. Ich weiss nicht, ob die normal sind. Mir kommen diese vielen Constructions und Deconstructions bei jedem eingehenden Fax sehr seltsam vor: May 9 01:32:28 faxserver4 kernel: VCAPI Constructing ExternalDSS1 F8CA576C May 9 01:32:28 faxserver4 kernel: VCAPI FindNameInformation: oid = FFFF/0036 May 9 01:32:28 faxserver4 kernel: VCAPI FindNameInformation: res = May 9 01:32:28 faxserver4 kernel: VCAPI FindNameInformation: oid = FFFF/0037 May 9 01:32:28 faxserver4 kernel: VCAPI FindNameInformation: res = May 9 01:32:28 faxserver4 kernel: VCAPI MapInbound: m_capiAnnahme=0, m_numberType=0, res=11 May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CA5AD0 May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CA7088 May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CA724C May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CA7410 May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CA7998 May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CA7B5C May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CA7D20 May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CA82A8 May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CA8630 May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CA87F4 May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CA8CEC May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CA8EB0 May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CA9074 May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CA9238 May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CA982C May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CA99F0 May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CA9BB4 May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CA9D78 May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CA9F3C May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CAA100 May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CAA2C4 May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CAA488 May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CAA64C May 9 01:32:28 faxserver4 kernel: VCAPI CAPIAnnahme: type=0, m_numberType=0, res=1 May 9 01:32:28 faxserver4 kernel: VCAPI Constructing PLCI20 F8CAA91C May 9 01:32:28 faxserver4 kernel: VCAPI CrossbarOn(F8C14360,88,04) May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CA7088 May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CA724C May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CA7410 May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CA7998 May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CA7B5C May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CA7D20 May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CA82A8 May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CA846C May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CA8630 May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CA87F4 May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CA8CEC May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CA8EB0 May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CA9074 May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CA9238 May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CA982C May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CA99F0 May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CA9BB4 May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CA9D78 May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CA9F3C May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CAA100 May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CAA2C4 May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CAA488 May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CAA64C May 9 01:32:28 faxserver4 kernel: VCAPI Destructing PLCI20 F8CAA91C May 9 01:32:28 faxserver4 kernel: VCAPI FindNameInformation: res = May 9 01:32:28 faxserver4 kernel: VCAPI Constructing B2Trans F8CA6B48 May 9 01:32:28 faxserver4 kernel: VCAPI BCallRefFax::BCallRefFax F8CB12F8/F8CB3310 May 9 01:32:34 faxserver4 kernel: VCAPI <V21(F8CB1308): FF 03 40 20 20 20 20 20 20 20 20 20 36 36 39 30 35 31 32 37 39 34 2B May 9 01:32:35 faxserver4 kernel: VCAPI <V21(F8CB1308): FF 13 80 00 C6 F8 44 May 9 01:32:36 faxserver4 kernel: VCAPI 00007B40: V.21 carrier detected (02C8) May 9 01:32:38 faxserver4 kernel: VCAPI 0000C3C0: V.21 carrier lost (04C9,EBC9,0C8F) May 9 01:32:38 faxserver4 kernel: VCAPI >V21(F8CB1308): FF 03 43 30 30 30 31 30 30 37 34 39 38 30 20 20 20 20 20 20 20 20 20$ May 9 01:32:38 faxserver4 kernel: VCAPI >V21(F8CB1308): FF 13 83 00 46 F8 44 C6 BD May 9 01:32:38 faxserver4 kernel: VCAPI 00000026: Energy detected (00000B44) May 9 01:32:38 faxserver4 kernel: VCAPI 00000054: P2 detected (00001303) May 9 01:32:38 faxserver4 kernel: VCAPI 000000FC: PN detected May 9 01:32:38 faxserver4 kernel: VCAPI 00000446: Carrier detected (00000000) May 9 01:32:40 faxserver4 kernel: VCAPI 000020E2: Energy lost (00000101) May 9 01:32:41 faxserver4 kernel: VCAPI <V21(F8CB1308): FF 13 84 May 9 01:32:42 faxserver4 kernel: VCAPI 00001328: Energy detected (00000AEA) May 9 01:32:42 faxserver4 kernel: VCAPI 0000135C: P2 detected (00001510) May 9 01:32:42 faxserver4 kernel: VCAPI 0000141C: PN detected May 9 01:32:42 faxserver4 kernel: VCAPI 00001766: Carrier detected (00000000) May 9 01:33:29 faxserver4 kernel: VCAPI 00038656: Energy lost (0000033A) May 9 01:33:30 faxserver4 kernel: VCAPI 00000CA0: V.21 carrier detected (02C5) May 9 01:33:31 faxserver4 kernel: VCAPI 00003960: V.21 carrier lost (04BF,EC10,0C5E) May 9 01:33:31 faxserver4 kernel: VCAPI >V21(F8CB1308): FF 13 BF 2F 00 00 CA 9C 2C May 9 01:33:31 faxserver4 kernel: VCAPI T30::FaxNotifyQuality(2338,2338) May 9 01:33:31 faxserver4 kernel: VCAPI OnEndReception 000000D0 00000922 00000922 May 9 01:33:32 faxserver4 kernel: VCAPI <V21(F8CB1308): FF 13 8C May 9 01:33:33 faxserver4 kernel: VCAPI 000057A0: V.21 carrier detected (02C6) May 9 01:33:34 faxserver4 kernel: VCAPI 00007F20: V.21 carrier lost (04C1,EBF5,0C49) May 9 01:33:34 faxserver4 kernel: VCAPI >V21(F8CB1308): FF 13 FB 9A F6 May 9 01:33:34 faxserver4 kernel: VCAPI CrossbarOff(F8C14360,88,04) May 9 01:33:34 faxserver4 kernel: VCAPI BCallRefFax::~BCallRefFax F8CB12F8/F8CB3310 May 9 01:33:34 faxserver4 kernel: VCAPI Destructing B2Trans F8CA6B48 May 9 01:33:34 faxserver4 kernel: VCAPI Destructing PLCI20 F8CA5AD0 May 9 01:33:34 faxserver4 kernel: VCAPI Destructing ExternalDSS1 F8CA576C Hat irgendjemand eine Vorstellung was da passiert? Ich bin fuer jeden Hinweis dankbar! Herzliche Gruesse Christian

2 1

Re: [suse-isdn] 2 ISDN Mehrger=E4teanschl=FCsse....
by Kristofer Hoelzer 09 May '06

09 May '06

Hallo Stefan, wenn das - Indikator: dein "mehrere Nummern" - jeweils ein Basisanschluss in Mehrgeraetekonfiguration ist (PMP) dann hilft da IMO nur das sogenannte "CLIP no screening"; denn sonst wird in der VSt - wenn keine gueltige MSN vorgegeben wurde - abgehend die erste MSN des jeweiligen Basisanschlusses ausgewaehlt. "CLIP no screening" ist uebrigens provideruebergreifend manchmal noch bisschen problematisch, da "gefiltert". Und kostenfrei wird das die TCom auch nicht freischalten .... HTH Kristofer Stefan Rother <stefan.rother(a)otrs.com> wrote (Tue, 09 May 2006 11:33:20 +0200): > Liebe Liste, > > kurz zu unserer Konfiguration: > > 2 Mehrger�teanschl�sse > Telefonanlage Asterisk > ISDN Karte Junghanns Quadbri > Sip Telefone Grandstream und Snom > > Ziel ist es, beide Mehrger�teanschl�sse mit einer zentralen Nummer > nutzen zu k�nnen (SPOC), bzw. unsere zentrale Nummer f�r alle 4 Kan�le > zu nutzen. > > Leider wurden unsere Settings in der zapata.conf und extensions.conf > bisher nicht beachtet, je nach verwendeten Kanal wird immer eine andere > Telefonnummer angezeigt. > > Die Telekom hatte mir versichert, dass es ohne weiteres m�glich w�re, > auch alle 4 Kan�le einer Rufnummer zuzuordnen. > > Meine Frage ist jetzt, ob unsere Konfiguration noch nicht richtig ist, > oder ob ich �berhaupt die M�glichkeit habe die urspr�ngliche, von der > Telekom vergebene, Nummer �berschreiben kann? > > Vielen Dank f�r Eure Hilfe und einen sch�nen Tag! > > Stefan Rother > > ((otrs)) :: OTRS GmbH :: Europaring 4 :: D - 94315 Straubing > Fon: +49 (0) 9421 1862 760 :: Fax: +49 (0) 9421 1862 769 > http://www.otrs.com/ :: Communication with success! > > -- > Um die Liste abzubestellen, schicken Sie eine Mail an: > suse-isdn-unsubscribe(a)suse.com > Um eine Liste aller verf�gbaren Kommandos zu bekommen, schicken > Sie eine Mail an: suse-isdn-help(a)suse.com > >

1 0

2 ISDN Mehrgeräteanschlüsse mit einer Nummer
by Stefan Rother 09 May '06

09 May '06

Liebe Liste, kurz zu unserer Konfiguration: 2 Mehrgeräteanschlüsse Telefonanlage Asterisk ISDN Karte Junghanns Quadbri Sip Telefone Grandstream und Snom Ziel ist es, beide Mehrgeräteanschlüsse mit einer zentralen Nummer nutzen zu können (SPOC), bzw. unsere zentrale Nummer für alle 4 Kanäle zu nutzen. Leider wurden unsere Settings in der zapata.conf und extensions.conf bisher nicht beachtet, je nach verwendeten Kanal wird immer eine andere Telefonnummer angezeigt. Die Telekom hatte mir versichert, dass es ohne weiteres möglich wäre, auch alle 4 Kanäle einer Rufnummer zuzuordnen. Meine Frage ist jetzt, ob unsere Konfiguration noch nicht richtig ist, oder ob ich überhaupt die Möglichkeit habe die ursprüngliche, von der Telekom vergebene, Nummer überschreiben kann? Vielen Dank für Eure Hilfe und einen schönen Tag! Stefan Rother ((otrs)) :: OTRS GmbH :: Europaring 4 :: D - 94315 Straubing Fon: +49 (0) 9421 1862 760 :: Fax: +49 (0) 9421 1862 769 http://www.otrs.com/ :: Communication with success!

1 0

Re: [suse-isdn] ich fliege immer ´raus!
by Kai Herlemann 07 May '06

07 May '06

Christian Lange schrieb: > Am So 07.05.2006 20:48 schrieb Kai Herlemann <netkai(a)ewetel.net>: > > >> Christian Lange schrieb: >> >>> Hallo Kai, >>> >>> vesuche mal auszuschließen, dass es sich um ein DNS Problem handelt; >>> denn wenn Dein einmal gestarteter Ping "durchläuft", d.h. nicht >>> abbricht, steht die Leitung ja noch. Welche Nameserver benutzt Du >>> (cat >>> /etc/resolv.conf) ? >>> >>> >>> Christian >>> >>> >> Der DNS wird automatisch abgerufen. Da ist keiner eingetragen. >> > > Ich mag mich irren, aber in der /etc/resolv.conf muss, auch wenn der > DNS-Server per dhcp bezogen wird, IMMER ein Eintrag > (nameserver=aaa.bbb.ccc.ddd) stehen. Ohne nameserver Eintrag ist es > verständlich, dass die Leitung tot wirkt. > Kann es sein, dass du /etc/ppp/resolv.conf meintest? Ich habe die mal nach /etc kopiert. Du hast Recht, in der Datei /etc/ppp/resolv.conf sind zwei Einträge. Die Nameserver wurden wohl automatisch abgerufen und dann geschrieben. Ich dachte, die werden nicht abgespeichert. Ich dachte, die werden jedesmal neu abgefragt und nicht gespeichert. Soweit stimmt das auch, aber sie werden neu abgefragt _und_ gespeichert. Ich hab das in YaST mal dahingehend geändert, dass die nicht immer neu abgefragt werden, sondern ich habe sie manuell eingegeben. Und sende deine eMails doch bitte an die Liste. Ich vergesse das leider auch oft. Gruß Kai Herlemann -- Kai Herlemann Albringhausen 60 27211 Bassum Mobil: 01621848562 Fax: 04241-921507 eMail: netkai(a)ewetel.net

1 0

Re: [suse-isdn] ich fliege immer ´raus!
by Kai Herlemann 07 May '06

07 May '06

Christian Lange schrieb: > Hallo Kai, > > vesuche mal auszuschließen, dass es sich um ein DNS Problem handelt; > denn wenn Dein einmal gestarteter Ping "durchläuft", d.h. nicht > abbricht, steht die Leitung ja noch. Welche Nameserver benutzt Du (cat > /etc/resolv.conf) ? > > > Christian > Der DNS wird automatisch abgerufen. Da ist keiner eingetragen. -- Kai Herlemann Albringhausen 60 27211 Bassum Mobil: 01621848562 Fax: 04241-921507 eMail: netkai(a)ewetel.net

1 0

ich fliege immer ´raus!
by Kai Herlemann 07 May '06

07 May '06

Hallo, ich besitze eine AVM Fritz!Card USB mit SUSE Linux 10.0 (nicht OpenSUSE). Leider fliege ich dauernd ´raus! Ich denke nicht, dass es an meinem Provider liegt. Oft ist es so, dass ich noch verbunden bin (zeigt sowohl KInternet als auch die Karte an), aber keine Website mehr aufgerufen werden kann. SeaMonkey (Mozilla) zeigt dann immer "warte auf www.xxx.de", "verbinde mit www.xxx.de" oder "löse www.xxx.de auf" an, da tut sich aber nichts. Manchmal trennt der PC die Verbindung selbst, manchmal tue ich es. Wenn ich mich neu verbinde, wird daraus nichts. Oder: es wird etwas, nach ein paar Sekunden geht aber wieder nichts mehr. Grüße Kai Herlemann -- Kai Herlemann Albringhausen 60 27211 Bassum Mobil: 01621848562 Fax: 04241-921507 eMail: netkai(a)ewetel.net

2 4

RE: [suse-isdn] AVM C2 - FDDI Digital DEFPA -> irq event 11: bogus return value 5
by KRBUSEK Christian 02 May '06

02 May '06

> -----Original Message----- > From: Holger Krull [mailto:holger.krull@gmx.de] > Sent: Dienstag, 02. Mai 2006 13:49 > > KRBUSEK Christian schrieb: >> Das eingesetzte Board ist ein AIMB-742, apic im BIOS aktivert und >> testweise > > apic im BIOS aktiviert? Bist du sicher das du das nicht mit acpi verwechselt hast? Ich hab extra nochmal nachgesehn, weil ich die beiden selbst gern verwechsel, und ja, apic und nicht acpi. >> hab ich den Kernel mit der Option apic booten lassen. Ergebnis ist >> leider das Gleiche :( > > Hat sich die Interruptzuordnung geändert? > Sonst hilft vielleicht noch das umsortieren der Karten in den Steckplätzen. > Irgendwelche ISA Karten drin? Ja, die Karten haben IRQ 17 statt 11 verwendet mit dem gleichen Effekt. Steckplätze hab ich mal teilweise getauscht, mit gleichem Effekt. Hier ist die Problematig - denk ich mal - dass ich nur 5 PCI Slots habe und alle 5 belegt sind (3 NICs, 1 ISDN Controller, 1 FDDI), aber ich werd noch weiter tauschen. ISA Karten sind keine in Verwendung. Grüsse

1 0

RE: [suse-isdn] AVM C2 - FDDI Digital DEFPA -> irq event 11: bogus return value 5
by KRBUSEK Christian 02 May '06

02 May '06

Hallo Holger, danke für die schnelle, wenn auch etwas ernüchternde Antwort. Das eingesetzte Board ist ein AIMB-742, apic im BIOS aktivert und testweise hab ich den Kernel mit der Option apic booten lassen. Ergebnis ist leider das Gleiche :( Grüsse > -----Original Message----- > From: Holger Krull [mailto:holger.krull@gmx.de] > KRBUSEK Christian schrieb: >> >> # cat /proc/interrupts >> CPU0 >> 0: 155960334 XT-PIC timer >> 1: 20 XT-PIC i8042 >> 2: 0 XT-PIC cascade >> 5: 9297309 XT-PIC uhci_hcd, eth3 >> 8: 25 XT-PIC rtc >> 9: 6978954 XT-PIC acpi, uhci_hcd, uhci_hcd, eth2 >> 10: 0 XT-PIC ehci_hcd >> 11: 3462338 XT-PIC libata, c2-d500, uhci_hcd, Intel ICH5, eth1, fddi0 >> 14: 120830 XT-PIC ide0 >> 15: 44 XT-PIC ide1 >> NMI: 0 >> LOC: 0 >> ERR: 0 >> MIS: 0 >> >> >> >> Apr 25 03:26:48 KRW1 kernel: Disabling IRQ #11 Apr 25 03:27:50 KRW1 kernel: >> capidrv-1: controller dead ?? >> >> quittiert. >> >> Ich bin mir nicht ganz sicher, aber denke, es handelt sich hier um ein IRQ >> Sharing Problem zwischen der FDDI Karte und einem anderen Gerät, welches auch >> den IRQ 11 verwenden will. >> >> Kennt jemand das Problem bzw. Ähnliches? Für Hinweise wäre ich dankbar. > Das spezifische Problem dürften wohl nur wenige Leute überhaupt sehen können, aber bei solchen IRQ Geschichten ist es immer einen > Versuch Wert den Kernel mit dem Parameter apic zu starten um zu sehen ob die IRQ Entzerrung hilft. (Geht natürlich nur wenn auch > ein apic auf dem Mainboard ist apic=advanced programmable interrupt controller)

2 1

AVM C2 - FDDI Digital DEFPA -> irq event 11: bogus return value 5
by KRBUSEK Christian 02 May '06

02 May '06

Hallo Karten, Hallo Liste, ich hoffe, ich bin mit meinem Problem hier richtig, habe keine netzwerkbezogene Liste gefunden auf der SuSE Seite. Ich habe in einem Rechner eine FDDI NIC des Typs Digital DEFPA eingebaut, zusätzlich stecken noch ein aktiver AMV C2 ISDN Controller und 3 PCI Ethernet NICs drinnen. Beim Aktivieren mittels "ifconfig fddi0 <ip> <broadcast> <netmask> up" erscheint dann in /var/log/messages nach einiger Zeit Folgendes: --- /var/log/messages --- Apr 27 10:20:23 KRW1 kernel: irq event 11: bogus return value 5 Apr 27 10:20:23 KRW1 kernel: Call Trace: Apr 27 10:20:23 KRW1 kernel: [__report_bad_irq+28/112] __report_bad_irq+0x1c/0x70 Apr 27 10:20:23 KRW1 kernel: [<c010a66c>] __report_bad_irq+0x1c/0x70 Apr 27 10:20:23 KRW1 kernel: [do_IRQ+364/416] do_IRQ+0x16c/0x1a0 Apr 27 10:20:23 KRW1 kernel: [<c010a92c>] do_IRQ+0x16c/0x1a0 Apr 27 10:20:23 KRW1 kernel: [common_interrupt+24/32] common_interrupt+0x18/0x20 Apr 27 10:20:23 KRW1 kernel: [<c0108d38>] common_interrupt+0x18/0x20 Apr 27 10:20:23 KRW1 kernel: [delay_tsc+11/32] delay_tsc+0xb/0x20 Apr 27 10:20:23 KRW1 kernel: [<c011221b>] delay_tsc+0xb/0x20 Apr 27 10:20:23 KRW1 kernel: [__delay+9/16] __delay+0x9/0x10 Apr 27 10:20:23 KRW1 kernel: [<c01f0049>] __delay+0x9/0x10 Apr 27 10:20:23 KRW1 kernel: [aec62xx_ratemask+65/144] dfx_hw_dma_uninit+0x51/0x70 Apr 27 10:20:23 KRW1 kernel: [<c024c421>] dfx_hw_dma_uninit+0x51/0x70 Apr 27 10:20:23 KRW1 kernel: [ali_get_info+1098/1808] dfx_adap_init+0x2a/0x360 Apr 27 10:20:23 KRW1 kernel: [<c024d93a>] dfx_adap_init+0x2a/0x360 Apr 27 10:20:23 KRW1 kernel: [ide_find_best_mode+281/464] dfx_open+0xa9/0xe0 Apr 27 10:20:23 KRW1 kernel: [<c024dd19>] dfx_open+0xa9/0xe0 Apr 27 10:20:23 KRW1 kernel: [dev_ethtool+996/2080] dev_open+0x84/0xd0 Apr 27 10:20:23 KRW1 kernel: [<c029be44>] dev_open+0x84/0xd0 Apr 27 10:20:23 KRW1 kernel: [ethtool_get_coalesce+60/128] dev_change_flags+0x4c/0x110 Apr 27 10:20:23 KRW1 kernel: [<c029aedc>] dev_change_flags+0x4c/0x110 Apr 27 10:20:23 KRW1 kernel: [ip_mc_find_dev+79/192] devinet_ioctl+0x5ff/0x740 Apr 27 10:20:23 KRW1 kernel: [<c02d8caf>] devinet_ioctl+0x5ff/0x740 Apr 27 10:20:23 KRW1 kernel: [ip_mc_del_src+6/336] inet_ioctl+0x66/0x90 Apr 27 10:20:23 KRW1 kernel: [<c02d92b6>] inet_ioctl+0x66/0x90 Apr 27 10:20:23 KRW1 kernel: [sock_setsockopt+788/1392] sock_ioctl+0x174/0x240 Apr 27 10:20:23 KRW1 kernel: [<c0294444>] sock_ioctl+0x174/0x240 Apr 27 10:20:23 KRW1 kernel: [sys_ioctl+662/1040] sys_ioctl+0x296/0x410 Apr 27 10:20:23 KRW1 kernel: [<c0170956>] sys_ioctl+0x296/0x410 Apr 27 10:20:23 KRW1 kernel: [sock_setsockopt+416/1392] sock_ioctl+0x0/0x240 Apr 27 10:20:23 KRW1 kernel: [<c02942d0>] sock_ioctl+0x0/0x240 Apr 27 10:20:23 KRW1 kernel: [sysenter_past_esp+82/121] sysenter_past_esp+0x52/0x79 Apr 27 10:20:23 KRW1 kernel: [<c0107db9>] sysenter_past_esp+0x52/0x79 Apr 27 10:20:23 KRW1 kernel: Apr 27 10:20:23 KRW1 kernel: handlers: Apr 27 10:20:23 KRW1 kernel: [__crc_sleep_on+2758017/2805638] (ata_interrupt+0x0/0x100 [libata]) Apr 27 10:20:23 KRW1 kernel: [<e091afc0>] (ata_interrupt+0x0/0x100 [libata]) Apr 27 10:20:23 KRW1 kernel: [__crc_recal_intr+1000341/1717578] (c4_interrupt+0x0/0xcf0 [c4]) Apr 27 10:20:23 KRW1 kernel: [<e0ae5b20>] (c4_interrupt+0x0/0xcf0 [c4]) Apr 27 10:20:23 KRW1 kernel: [__crc_recal_intr+1309605/1717578] (usb_hcd_irq+0x0/0x50 [usbcore]) Apr 27 10:20:23 KRW1 kernel: [<e0b31330>] (usb_hcd_irq+0x0/0x50 [usbcore]) Apr 27 10:20:23 KRW1 kernel: [__crc_ide_setup_dma+684631/14548870] (snd_intel8x0_interrupt+0x0/0x250 [snd_intel8x0]) Apr 27 10:20:23 KRW1 kernel: [<e0c50230>] (snd_intel8x0_interrupt+0x0/0x250 [snd_intel8x0]) Apr 27 10:20:23 KRW1 kernel: [__crc_ide_setup_dma+303991/14548870] (rtl8139_interrupt+0x0/0x4e0 [8139too]) Apr 27 10:20:23 KRW1 kernel: [<e0bf3350>] (rtl8139_interrupt+0x0/0x4e0 [8139too]) Apr 27 10:20:23 KRW1 kernel: [amd_set_drive+352/1088] (dfx_interrupt+0x0/0x90) Apr 27 10:20:23 KRW1 kernel: [<c024e340>] (dfx_interrupt+0x0/0x90) --- /var/log/messages --- # cat /proc/interrupts CPU0 0: 155960334 XT-PIC timer 1: 20 XT-PIC i8042 2: 0 XT-PIC cascade 5: 9297309 XT-PIC uhci_hcd, eth3 8: 25 XT-PIC rtc 9: 6978954 XT-PIC acpi, uhci_hcd, uhci_hcd, eth2 10: 0 XT-PIC ehci_hcd 11: 3462338 XT-PIC libata, c2-d500, uhci_hcd, Intel ICH5, eth1, fddi0 14: 120830 XT-PIC ide0 15: 44 XT-PIC ide1 NMI: 0 LOC: 0 ERR: 0 MIS: 0 # uname -r 2.6.5-7.252-default Der Calltrace "Spam" tritt meist unregelmäßig und für mich nicht reproduzierbar auf und nach einiger Zeit wird´s dann mit einem Apr 25 03:26:48 KRW1 kernel: Disabling IRQ #11 Apr 25 03:27:50 KRW1 kernel: capidrv-1: controller dead ?? quittiert. Ich bin mir nicht ganz sicher, aber denke, es handelt sich hier um ein IRQ Sharing Problem zwischen der FDDI Karte und einem anderen Gerät, welches auch den IRQ 11 verwenden will. Kennt jemand das Problem bzw. Ähnliches? Für Hinweise wäre ich dankbar. Mit freundlichen Grüßen, -- Christian Krbusek Maintenance FREQUENTIS GmbH Postal Address: A-1120 Wien, Spittelbreitengasse 34 Office Address: A-1120 Wien, Wolfganggasse 58-60 christian.krbusek(a)frequentis.com Tel. +43/1/81150-1570 Fax. +43/1/8115077-1570

2 1

Re: [suse-isdn] Problem beim fritz kompilieren
by Kyek, Andreas, VF-DE 02 May '06

02 May '06

Stefan Schilling wrote: > [...] > > Dazu hab ich mir das fcpci-suse9.1-3.11-02.tar.gz > gezogen und entpackt. Danach habe ich folgendes > gemacht: > > korfu:/usr/local/src# cd fritz/src/ > korfu:/usr/local/src/fritz/src# make > make -C /lib/modules/2.6.16.9/build > SUBDIRS=/usr/local/src/fritz/src modules > make[1]: Entering directory `/usr/src/linux-2.6.16.9' > CC [M] /usr/local/src/fritz/src/main.o > In file included from /usr/local/src/fritz/src/queue.h:27, > from /usr/local/src/fritz/src/tables.h:31, > from /usr/local/src/fritz/src/driver.h:31, > from /usr/local/src/fritz/src/main.c:45: > /usr/local/src/fritz/src/tools.h:74: Fehler: Fehler beim > Parsen vor "typeof" > make[2]: *** [/usr/local/src/fritz/src/main.o] Fehler 1 > make[1]: *** [_module_/usr/local/src/fritz/src] Fehler 2 > make[1]: Leaving directory `/usr/src/linux-2.6.16.9' > make: *** [fcpci.ko] Fehler 2 [...] Hast Du dir schon mal die Mühe mit google o.ä. gemacht? Dann hättest Du (so wie ich) herausgefunden, das der fcpci mit dem Kernel nicht mehr ohne Patch kompiliert. Lösung: In ./fritz/src im File tools.h die Definition von atomic_xchg ab Zeile 74 auskommentieren. (Wir nirgendwo verwendet!) Dann klappts Andreas

1 0