ppp-2.4.2-39.3.i586.patch.rpm inkompatibel zu Vanilla 2.6.7?
Aufgrund der augenblicklichen Situation mit dem SuSE-Kernel 2.6.5-7.75-default, der mit mancher Hardware nicht funktioniert, habe ich einen Vanilla-Kernel 2.6.7 gebaut. Der Internetzugang funktionierte danach nicht mehr. Das war aber ein Firewall-Problem. Nach einem Deaktivieren der SuSE-FW2 mit anschließendem Aktivieren und Reboot konnte ich eine Internetverbindung aufbauen. Ich verstehe zwar die Ursache dafür nicht, aber Hauptsache es funktioniert. Als ich dann ppp-2.4.2-39.3.i586.patch.rpm installierte, war es wieder vorbei mit Internet. Ich erhielt 2 unterschiedliche Fehlermeldungen: kernel: ippp0: dialing 1 1002019088333... smpppd[11512]: smpppd version 1.16 started kernel: isdn_net: local hangup ippp0 kernel: ippp0: Chargesum is 0 kernel: NETDEV WATCHDOG: ippp0: transmit timed out kernel: isdn_tx_timeout dev ippp0 dialstate 0 kernel: ippp0: dialing 1 1002019088333... kernel: isdn: contr0,ch0 cause: E001B kernel: isdn_net: local hangup ippp0 kernel: ippp0: Chargesum is 0 kernel: NETDEV WATCHDOG: ippp0: transmit timed out kernel: isdn_tx_timeout dev ippp0 dialstate 0 Ich habe dann den NTBA abgeklemmt und alle Kabel ab- und angesteckt. Erst nach einem Löschen von ppp und Installation von ppp-2.4.2-39.i586.rpm von der 9.1 CD konnte ich wieder eine Verbindung aufbauen. Andererseits _glaube_ ich mich aber zu erinnern, dass gestern Internet mit ppp-2.4.2-39.3.i586.patch.rpm nach einem Reboot nach der Installation funktionierte. Ich bin mir nicht sicher, ob ein Reboot wirklich gemacht wurde. Hätte das überhaupt Auswirkungen auf die Funktion gehabt? Vgl. oben, Internet funktionierte erst nach Reboot. Habe ich nun ein tückisches Hardwareproblem oder liegt einfach eine Inkompatibilität zu Kernel 2.6.7 vor? Al
On Fri, Jun 25, 2004 at 03:27:10PM +0200, Al Bogner wrote:
Aufgrund der augenblicklichen Situation mit dem SuSE-Kernel 2.6.5-7.75-default, der mit mancher Hardware nicht funktioniert, habe ich einen Vanilla-Kernel 2.6.7 gebaut. Der Internetzugang funktionierte danach nicht mehr. Das war aber ein Firewall-Problem. Nach einem Deaktivieren der SuSE-FW2 mit anschließendem Aktivieren und Reboot konnte ich eine Internetverbindung aufbauen. Ich verstehe zwar die Ursache dafür nicht, aber Hauptsache es funktioniert.
Als ich dann ppp-2.4.2-39.3.i586.patch.rpm installierte, war es wieder vorbei mit Internet. Ich erhielt 2 unterschiedliche Fehlermeldungen:
Das ppp Paket hat nichts mit ISDN und ippp0 zu tun, das muss ein anderes Problem sein. Auch die Cause E001B deutet eher auf ein Problem mit IRQ oder Hardware hin. -- Karsten Keil SuSE Labs ISDN development
Am Freitag, 25. Juni 2004 15:45 schrieb Karsten Keil:
Als ich dann ppp-2.4.2-39.3.i586.patch.rpm installierte, war es wieder vorbei mit Internet. Ich erhielt 2 unterschiedliche Fehlermeldungen:
Das ppp Paket hat nichts mit ISDN und ippp0 zu tun, das muss ein anderes Problem sein.
Danke Karsten, ich habe das fast schon befürchtet und nun geht das Rätselraten weiter.
Auch die Cause E001B deutet eher auf ein Problem mit IRQ oder Hardware hin.
Jetzt funktioniert es ja wieder. Kann man mit "Bordmitteln" Tests durchführen, die darauf schließen lassen, was defekt sein könnte? Das Problem tritt unregelmäßig und selten seit ein paar Wochen auf. Gibt es eine Möglichkeit den NTBA vom Linux-Rechner aus zu testen? Meine nächste Vermutung ist, dass sich der NTBA manchmal aufhängt. Nach einer Netztrennung von ein paar Sekunden funktionierte es nicht. Es funktionierte aber wieder nach einer längeren Netztrennung des NTBA. Zufall? Wie könnte man eine 0000:00:0c.0 Network controller: AVM Audiovisuelles MKTG & Computer System GmbH A1 ISDN [Fritz] (rev 02) Subsystem: AVM Audiovisuelles MKTG & Computer System GmbH FRITZ!Card ISDN Controller Flags: medium devsel, IRQ 11 Memory at df000000 (32-bit, non-prefetchable) I/O ports at b000 [size=32] testen, ob sie zeitweise Fehler liefert? Du schriebst einmal, dass man das IRQ-Problem ausschließen kann, wenn es manchmal funktioniert. cat /proc/interrupts CPU0 0: 5513223 XT-PIC timer 1: 14 XT-PIC i8042 2: 0 XT-PIC cascade 4: 10 XT-PIC serial 5: 0 XT-PIC ES18xx 8: 3 XT-PIC rtc 9: 238380 XT-PIC uhci_hcd, eth0 11: 748850 XT-PIC HiSax 14: 21434 XT-PIC ide0 15: 101444 XT-PIC ide1 NMI: 0 LOC: 5513792 ERR: 0 MIS: 0 Al
On Fri, Jun 25, 2004 at 04:38:21PM +0200, Al Bogner wrote:
Am Freitag, 25. Juni 2004 15:45 schrieb Karsten Keil:
Als ich dann ppp-2.4.2-39.3.i586.patch.rpm installierte, war es wieder vorbei mit Internet. Ich erhielt 2 unterschiedliche Fehlermeldungen:
Das ppp Paket hat nichts mit ISDN und ippp0 zu tun, das muss ein anderes Problem sein.
Danke Karsten, ich habe das fast schon befürchtet und nun geht das Rätselraten weiter.
Auch die Cause E001B deutet eher auf ein Problem mit IRQ oder Hardware hin.
Jetzt funktioniert es ja wieder. Kann man mit "Bordmitteln" Tests durchführen, die darauf schließen lassen, was defekt sein könnte? Das Problem tritt unregelmäßig und selten seit ein paar Wochen auf.
Gibt es eine Möglichkeit den NTBA vom Linux-Rechner aus zu testen? Meine nächste Vermutung ist, dass sich der NTBA manchmal aufhängt. Nach einer Netztrennung von ein paar Sekunden funktionierte es nicht. Es funktionierte aber wieder nach einer längeren Netztrennung des NTBA. Zufall?
Sieht nach NTBA oder VST Problem aus.
Wie könnte man eine
0000:00:0c.0 Network controller: AVM Audiovisuelles MKTG & Computer System GmbH A1 ISDN [Fritz] (rev 02) Subsystem: AVM Audiovisuelles MKTG & Computer System GmbH FRITZ!Card ISDN Controller Flags: medium devsel, IRQ 11 Memory at df000000 (32-bit, non-prefetchable) I/O ports at b000 [size=32]
testen, ob sie zeitweise Fehler liefert?
Ohne Protokollanalyser nur schlecht, wobei als Protokollanalyser durchaus auch ein 2. Linux PC mit einer HiSax Karte Verwendung finden kann.
Du schriebst einmal, dass man das IRQ-Problem ausschließen kann, wenn es manchmal funktioniert.
ja. Wobei es natuerlich auch einige Möglichkeiten gibt, z.B: Wackelkontakt (Karte neu einbauen oder anderen Slot, festschrauben). -- Karsten Keil SuSE Labs ISDN development
-----Ursprüngliche Nachricht----- Von: Al Bogner [mailto:suse-linux@ml04q2.pinguin.uni.cc] Gesendet: Freitag, 25. Juni 2004 16:38 An: suse-isdn@suse.com Betreff: Re: [suse-isdn] ppp-2.4.2-39.3.i586.patch.rpm inkompatibel zu Vanilla 2.6.7?
Jetzt funktioniert es ja wieder. Kann man mit "Bordmitteln" Tests durchführen, die darauf schließen lassen, was defekt sein könnte? Das Problem tritt unregelmäßig und selten seit ein paar Wochen auf.
Meine nächste Vermutung ist, dass sich der NTBA manchmal aufhängt. Nach einer Netztrennung von ein paar Sekunden funktionierte es nicht. Es funktionierte aber wieder nach einer längeren Netztrennung des NTBA. Zufall?
Das kommt mir bekannt vor. Bei mir hat sich gelegentlich die Telefonanlage aufgehängt. Um wieder eine Verbindung aufbauen zu können, habe ich diese kurz (ca. 10 Sec) vom Stromnetz getrennt und damit neu gestartet. Ich habe bei mir elektrische Störsignale im Verbindungskabel PC-Telefondose im Verdacht. Seit ich das Netzteil meiner Palm-Dockingstation konsequent von diesem Kabel fernhalte, habe ich keine Störungen mehr. Vielleicht ist es bei Dir etwas ähnliches. -- Jan Neuhäußer
Hi, Al Bogner schrieb am 25.06.2004 16:38:
Am Freitag, 25. Juni 2004 15:45 schrieb Karsten Keil:
Als ich dann ppp-2.4.2-39.3.i586.patch.rpm installierte, war es wieder vorbei mit Internet. Ich erhielt 2 unterschiedliche Fehlermeldungen:
Das ppp Paket hat nichts mit ISDN und ippp0 zu tun, das muss ein anderes Problem sein.
Danke Karsten, ich habe das fast schon befürchtet und nun geht das Rätselraten weiter.
Auch die Cause E001B deutet eher auf ein Problem mit IRQ oder Hardware hin.
Jetzt funktioniert es ja wieder. Kann man mit "Bordmitteln" Tests durchführen, die darauf schließen lassen, was defekt sein könnte? Das Problem tritt unregelmäßig und selten seit ein paar Wochen auf.
Gibt es eine Möglichkeit den NTBA vom Linux-Rechner aus zu testen? Meine nächste Vermutung ist, dass sich der NTBA manchmal aufhängt. Nach einer Netztrennung von ein paar Sekunden funktionierte es nicht. Es funktionierte aber wieder nach einer längeren Netztrennung des NTBA. Zufall?
Zufall wenn du nur den Netzstecker und nicht gleichzeitig den Stecker zur Telekom-Dose gezogen hast. Der NTBA braucht die 230V-Versorgung nur wenn du Geräte ohne eigene Stromversorgung (z.B. Telefone) angeschlossen hast, ansonsten reicht die Fernversorgung von der Vermittlungsstelle aus. Wenn du nur ein Stecker ziehst wird nix zurückgesetzt. Ingo -- ## Registered Linux User #274727 -- http://counter.li.org/ ## Office-Suite für Windows, Linux, Mac -- http://de.openoffice.org/ ## Die OpenOffice.org PrOOo-Box -- http://prooo-box.org/
participants (4)
-
Al Bogner -
Ingo Göppert -
Jan Neuhäußer -
Karsten Keil