Hallo zusammen, ich benutze den Server (SuSE10) auch gleichzeitig als Gateway ins Internet. Alch ich den Server eingerichtet hatte habe ich alle Daten drauf kopiert (ca. 200GB) als der Server plötzlich nicht mehr ansprechbar war. Am Server war jedoch alles in Ordnung. Dann habe ich den Client (ebenfalls SuSE10) neu gestartet und dabei festgestellt das der Client keine IP mehr vom Server bekam. Ich schaute mir das Logfile am Server an und stellt fest das die DHCP-Anfrage dort ankam, der Server aber nichts über die Schnittstelle senden konnte. Ich dachte die Netzwerkkarte (Onboard) ist hinüber war. Bei dem Board handelt es sich um ein neues: Asus A8N-SLI Deluxe nForce4 SLI (dual PC3200) Da ich ein zweites, identisches Board, noch da hatte habe ich einfach das Board getauscht. Zunächst ging wieder alles und ich konnte weiter die Daten auf den neuen Server kopieren. Am nächsten Tag wieder das gleiche Spiel. Danach war mir klar das es nicht die Hardware war. Ich weiß leider nicht mehr genau was ich damals gemacht habe. Ich hatte mir überlegt das es wohl an der Firewall liegen könnte das zu viele Verbindungen "halboffen" sind und deshalb keine neuen mehr geöffnet werden können. Das komische war das auch ein Neustart daran nichts ändert. Ich machte mich auf der Festplatte auf die Suche nach einen Verzeichnis wo diese Daten persistent gespeichert werden. Ich habe wohl eines gefunden und gelöscht und danach ging es wieder. Nun habe ich das gleiche Problem wieder und weiß nicht mehr welches Verzeichnis es war. Nun sollte ich damit anfangen dem Problem auf den Grund zu gehen. Den einzigen Logeintrag den ich finde und der schon damals vorhanden war ist: kernel: NETDEV WATCHDOG: eth0: transmit timed out kernel: nv_stop_tx: TransmitterStatus remained busy<7>eth0: tx_timeout: dead entries! kernel: Badness in local_bh_enable at kernel/softirq.c:140 kernel: kernel: Call Trace: <IRQ> <ffffffff801383c1>{local_bh_enable+49} <ffffffff881e8655>{:ip_conntrack:destroy_conntrack+53} kernel: <ffffffff802c0c1b>{__kfree_skb+219} <ffffffff882d629a>{:forcedeth:nv_drain_tx+138} kernel: <ffffffff882d73ec>{:forcedeth:nv_tx_timeout+92} <ffffffff802d5e30>{dev_watchdog+0} kernel: <ffffffff802d5ea8>{dev_watchdog+120} <ffffffff8013c519>{run_timer_softirq+361} kernel: <ffffffff801385d7>{__do_softirq+87} <ffffffff8010f8db>{call_softirq+31} kernel: <ffffffff80111380>{do_softirq+48} <ffffffff801113dd>{do_IRQ+77} kernel: <ffffffff8010eebc>{ret_from_intr+0} <EOI> <ffffffff8010d2b0>{default_idle+0} kernel: <ffffffff8808b635>{:processor:acpi_processor_idle+292} Mar 1 09:28:01 darwin kernel: <ffffffff8010d311>{cpu_idle+49} <ffffffff804a87aa>{start_kernel+458} kernel: <ffffffff804a81f4>{_sinittext+500} kernel: Badness in local_bh_enable at kernel/softirq.c:140 Genau dieser Log war bei ersten Auftreten des Fehler auch vorhanden und daraus schloß ich den Hardwareschaden. Wurde dann jedoch eines besseren belehrt. Hat irgend jemand eine Idee worher das ganze kommen kann? Viele Grüße Sven Gehr / Linux-User-Nummer: 368994