Hi Liste Nach dem Neuaufsetzen einer Maschine (A) mit SuSE 8.2 (vorher 8.1) habe ich ein merkwürdiges Netzwerkproblem. (Zwei andere, die ich vor längerer Zeit auf 8.2 gebracht habe, funktionieren anstandslos) Ich bekomme die Maschine schlicht nicht an's Netz. In der gleichen HW-Konfiguration lief sie unter früheren SuSE-Versionen. Auffällig ist, dass sie sich bei wiederholten Versuchen nicht immer gleich verhält.Versuche ich von A nach B zu pingen, erhalte ich (heute) immer: Destination Host Unreachable ein anschliessendes arp -a ergibt: ? (192.168.1.10) at <incomplete> on eth0 Bei den Versuchen gestern ist allerdings ab und an mal ein Ping durchgekommen allerdings mit Antwortzeiten zwischen 10 und 20 Sekunden (jawohl Sekunden, nicht Millisekunden). Versuche ich die andere Richtung (ping von B nach A, wobei B im Verkehr mit andern Maschinen läuft), so bekomme ich bei ping und anschliessendem arp meist dasselbe wie oben (natürlich mit der andern IP-Adresse). Manchmal aber ergibt der Ping von B nach A gar keinen Output (ausser 100% packet loss), und in ganz seltenen Fällen enthält das anschliessende arp -a die korrekte Mac-Adresse von B! Ein weiterer Unterschied zwischen A und B, ist der, dass A Einträge ins Log schreibt (B nicht). Ein grep eth0 /var/log/messages ergibt Einträge der Art: kernel: NETDEV WATCHDOG: eth0: transmit timed out kernel: eth0: Transmit timed out, status fc69c1d7, CSR12 00000000, resetting... (der status ändert sich von Zeit zu Zeit) Sämtliche Einstellungen sind dieselben wie früher und habe ich schon x-mal geprüft (ifconfig netstat yast). Verwende ich einen andern Port am Switch, ändert sich nichts. Verwende ich ein anderes Patchkabel ändert sich nichts. Der einzige Unterschied in der Netzwerkkonfiguration zwischen A und andern Maschinen ist der, dass die Netzwerkkarte eine 3Com ist, die den tulip-Treiber verwendet. Gibt's damit etwa Probleme unter 8.2? Hat irgend jemand noch ne Idee???? MfG Christoph Steinemann
On Tue, 2003-07-29 at 04:21, susemail@elmiura.ch wrote:
Hi Liste
[...]
Hallo Christoph, kann dir nur sagen das ich diese Probleme mit versch. 3com Karten hatte. Besonders Problematisch waren: 3com EtherLink II ( 3c509 / ISA ) 3com 3c905 ( Managed / PCI ) Im allgemeinen sollte dir dieser Link dir viel Info's geben. http://www.scyld.com/network/vortex.html Eine brauchbare/stabile Lösung habe ich mit dem eingesetzten Linux nicht gefunden - die Karten wurden ausgetauscht. Würde mich über Interessieren, fall's es bei dir klappt... Viel Glück, MfG Marcel Schmedes
Hi, Ekkard Gerlach wrote:
==> raus damit. Nimm' ne rtl8139 mit oder ohne WOL. Die fluppt.
Bei mir (meinem Sohn)läuft die 509 immer noch anstandslos (kernel 2.4.18-debian woody). Das war ein schweineteures Teil damals. Ok, ich habe sie geerbt :). Performance technisch bremmst die Karte aber meist der ISA bus (5,xx MB), also wenn sie auf 100Mbit eingestellt ist trotzdem bei gut 40 Schluss. -- - maik
On Tuesday 29 July 2003 04:10, Marcel Schmedes wrote:
Muss mich etwas korrigieren. Es ist keine 3com. Die Herstellerangabe ist Linksys, aber irgendwo in den Hardwareerkennungsmeldungen wurde mal ein 3com-Chip erkannt. Im übrigen läuft sie, genauso wie auch eine mit Realtek-Chip, seit ich ACPI ausgeschaltet habe, wie im andern Teil des Threads zu sehen ist. Das hilft dir wohl nicht weiter... Gruss, Christoph
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 29 July 2003 04:21, susemail@elmiura.ch wrote:
Schau mal nach auf welchem PCI Slot die NIC von A sitzt und ob sie sich den Slot mit ner anderen INT Leitung teilt (Shared PCI Slot, sollte in der Doku des Mainboards von A zu erfahren sein). Wen ja dann steck mal die NIC auf 'nen anderen PCI Slot. Sonst versuch mal, ie NIC aus A nehmen und in B oder C einbauen. Lässt sich das Problem nun zwischen B und C reproduzieren kann man schon mal davon das Problem auf die Hardware der NIC von A eingrenzen. Ich hatte auch schon mal NIC's die sich nach Gewitterlage teilweise verabschiedet haben, die Dinger sind manchmal sehr langsam am Sterben. Andererseits würde ich mir bei der anstehenden ein-, aus, um-, und was noch sonst alles -Bauerei und Stöpselei bereits überlegen ob sich nicht eher die Investition in eine neue NIC lohnt. Alleine wenn ich mal jede Stunde mit dem Stundensatz eines HiWis im Vergleich sehe sollte das billiger kommen. Ein genaues tracen des Problemes hat aber nicht geringe sattisfaktionelle Aspekte, mal sportlich gesehen. Tschüss, Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/JeU1wUbCBG+D/AIRAu8yAKCLNc5kv6BuGK3Xy9608dZ0I7TETACfWaXM eHsNOHQw4HiCTJdRpav95ds= =tvCt -----END PGP SIGNATURE-----
On Tuesday 29 July 2003 05:08, Thomas Templin wrote:
Das habe ich nicht ganz verstanden. Die Doku sagt natürlich nichts... Im BIOS sehe ich, dass Slot 1 und Slot 5 gemeinsamen konfiguriert werden. Die NIC steckt aber in Slot 2. Im ControlCenter sehe ich, dass sich die NIC den IRQ mit dem Firewire-Anschluss der Soundkarte teilt (den ich nicht benutze). Ich habe nie verstanden, weshalb IRQs geteilt werden, wenn es noch freie gibt. Ich habe aber auch nie rausgefunden, wie IRQs in Linux einzustellen sind (hat vor langer, langer Zeit in DOS prima funktioniert, aber das waren wohl noch ISA-Karten...). Die BIOS-Einstellungen werden von Linux überschrieben. Aber wo kann ich das sonst einstellen?
Weiss nicht weshalb mir erst dank deinem Meil einfiel, dass ich sogar noch ne überzählige NIC rumliegen habe (mit RealTek-Chip). Bloss: Gebracht hat's leider nichts. Nur die jeweils zweite Zeile im Log ändert sich: statt: kernel: eth0: Transmit timed out, status fc69c1d7, CSR12 00000000, resetting... nun: kernel: eth0: Tx queue start entry 22 dirty entry 18. kernel: eth0: Tx descriptor 0 is 00002000. kernel: eth0: Tx descriptor 1 is 00002000. kernel: eth0: Tx descriptor 2 is 00002000. (queue head) kernel: eth0: Tx descriptor 3 is 00002000. Die Log-Einträge deuten aber schon darauf hin, dass die 'packets' irgendwo stecken und "nicht raus können". Ich versuche schon lange den Befehl zu finden, der mir das sauber anzeigt. Laut Craig Hunt (TCP/IP Netzwerk-Administration) sollte "netstat -i" schön anzeigen wieviele Packete gequeued und nicht ausgeliefert sind. Das scheint auf Solaris zu funktionieren, Linux zeigt aber nicht das gewünschte. Aktuell scheinen sich nicht mal "netstat --help" und "man netstat" über die Syntax einig zu sein: # man netstat ... --interface=iface , -i Display a table of all network interfaces, or the specified iface). ... # netstat --interface=eth0 netstat: option `--interfaces' doesn't allow an argument ... Kennt jemand den Befehl, der diese "queued packets" anzeigt? Gruss, Christoph
Am Dienstag, 29. Juli 2003 03:21 schrieb susemail@elmiura.ch:
starte mal SuSE im "Failsafe" Modus uns schau, ob es dann geht. Bei mir (und anderen hier aus der Liste) musste die "noapic" Option beim Booten gesetzt werden. cu stonki -- www.stonki.de: the more I see, the more I know....... www.proftpd.de: Deutsche ProFTPD Dokumentation www.krename.net: Der Batch Renamer für KDE www.kbarcode.net: Die Barcode Solution für KDE
Hallo, am Dienstag, 29. Juli 2003 um 17:08 schrieb Christoph Steinemann
Aber was das mit der NIC zu tun hat??? Ob da wohl die WOL-Fähigkeit (die ich nie benutze...) der NIC reinspielt?
ich hatte dass das erste mal im Maerz bei einem rechner, den ich in den USA als Server fuer unsere Firma konfigurierte. Da ich durch die Fluege relativ lange Zeit hatte zum "rumspielen", habe ich verschiedene Varianten ausprobiert. Aktueller Vanilla Kernel, Karten vertauschen etc. Ich meine, dass es an den Interrupts liegt. Mit dem Vanilla Kernel klappte es beim ersten mal, nach einem Reboot lief es dann nicht mehr. Dann habe ich die Netzwerkkarten vertauscht (billige Dinger), dann ging es wieder. Da mir das jedoch alles zu unsicher war (Rechner ohne Netzwerkzugang mehrere Flugstunden entfernt, habe ich dann den Weg via "noapic" genommen. cu stonki -- Deutsche ProFTP Docs: http://www.proftpd.de, EFNET: #proftpd KDE3 Renamer: http://www.krename.net KDE3 Barcode und Label Solution: http://www.kbarcode.net
On Tue, 2003-07-29 at 04:21, susemail@elmiura.ch wrote:
Hi Liste
[...]
Hallo Christoph, kann dir nur sagen das ich diese Probleme mit versch. 3com Karten hatte. Besonders Problematisch waren: 3com EtherLink II ( 3c509 / ISA ) 3com 3c905 ( Managed / PCI ) Im allgemeinen sollte dir dieser Link dir viel Info's geben. http://www.scyld.com/network/vortex.html Eine brauchbare/stabile Lösung habe ich mit dem eingesetzten Linux nicht gefunden - die Karten wurden ausgetauscht. Würde mich über Interessieren, fall's es bei dir klappt... Viel Glück, MfG Marcel Schmedes
Hi, Ekkard Gerlach wrote:
==> raus damit. Nimm' ne rtl8139 mit oder ohne WOL. Die fluppt.
Bei mir (meinem Sohn)läuft die 509 immer noch anstandslos (kernel 2.4.18-debian woody). Das war ein schweineteures Teil damals. Ok, ich habe sie geerbt :). Performance technisch bremmst die Karte aber meist der ISA bus (5,xx MB), also wenn sie auf 100Mbit eingestellt ist trotzdem bei gut 40 Schluss. -- - maik
On Tuesday 29 July 2003 04:10, Marcel Schmedes wrote:
Muss mich etwas korrigieren. Es ist keine 3com. Die Herstellerangabe ist Linksys, aber irgendwo in den Hardwareerkennungsmeldungen wurde mal ein 3com-Chip erkannt. Im übrigen läuft sie, genauso wie auch eine mit Realtek-Chip, seit ich ACPI ausgeschaltet habe, wie im andern Teil des Threads zu sehen ist. Das hilft dir wohl nicht weiter... Gruss, Christoph
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 29 July 2003 04:21, susemail@elmiura.ch wrote:
Schau mal nach auf welchem PCI Slot die NIC von A sitzt und ob sie sich den Slot mit ner anderen INT Leitung teilt (Shared PCI Slot, sollte in der Doku des Mainboards von A zu erfahren sein). Wen ja dann steck mal die NIC auf 'nen anderen PCI Slot. Sonst versuch mal, ie NIC aus A nehmen und in B oder C einbauen. Lässt sich das Problem nun zwischen B und C reproduzieren kann man schon mal davon das Problem auf die Hardware der NIC von A eingrenzen. Ich hatte auch schon mal NIC's die sich nach Gewitterlage teilweise verabschiedet haben, die Dinger sind manchmal sehr langsam am Sterben. Andererseits würde ich mir bei der anstehenden ein-, aus, um-, und was noch sonst alles -Bauerei und Stöpselei bereits überlegen ob sich nicht eher die Investition in eine neue NIC lohnt. Alleine wenn ich mal jede Stunde mit dem Stundensatz eines HiWis im Vergleich sehe sollte das billiger kommen. Ein genaues tracen des Problemes hat aber nicht geringe sattisfaktionelle Aspekte, mal sportlich gesehen. Tschüss, Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/JeU1wUbCBG+D/AIRAu8yAKCLNc5kv6BuGK3Xy9608dZ0I7TETACfWaXM eHsNOHQw4HiCTJdRpav95ds= =tvCt -----END PGP SIGNATURE-----
participants (9)
-
Andreas Winkelmann -
Christoph Steinemann -
Ekkard Gerlach -
Maik Holtkamp -
Marcel Schmedes -
Stefan Onken -
Stefan Onken -
susemail＠elmiura.ch
-
Thomas Templin