# Hangup bei viel Netzverkehr....

## NightDragon

Hallo zusammen.

ich habe nun vor Tagen das Problem gehabt, das Samba bei viel Netzverkehr, sprich jeder Kopieraktion wo viel Daten hin und her gehn, sich der Rechner voll aufhängt.

Das Problem besteht auch, wenn ich mit iperf einen bandbreiten Test mache.

Das System hängt sich dann komplett auf.

Es gibt auch hinterher im Syslog keine Infos und es liegt auch kein IRQ-Konflikt vor.

Es spielt auch keine Rolle ob ich via WLAN (PCMCIA Karte) im Netz bin oder via onBoard Ethernet.

Er kopiert kurz und dann aus. Keine Maus, Keine Tastatur, kein ping, nichts wird mehr am PC akzeptiert.

Habt ihr irgend eine Idee?

Kernel: Gentoo-dev-sources-2.6.10-r6

Dev-Manager: Udev

eth0 (fix im Kernel): Sis 900 onboard vom Sis645DX Chipsatz

ath0 (als modul mit madwifi und wpa): WG511T

Egal was up udn down ist, egal über welches interface ich kopiere oder sonst was mache: Voller HangUp.

Solang der Datenverkehr aber nur ein Download aus dem Internet ist, ich via XMMS über Samba Sound höre oder sonst was in der Art mache, passiert nichts.

Ideen? Bugs bekannt?

Das ganze nervt natürlich irre, weil ich sehr viel Daten im Netz hin und her schiebe.

----------

## Sumpfdrache

Hi,

hört sich vielleicht saudumm an, aber hast Du mal gekuckt, ob Dein Board ausreichend belüftet wird?

Damit meine ich nicht die CPU (dass merkst an was Anderem  :Very Happy: ), aber manchmal ist auf dem Board noch so ein kleiner Chipsatzlüfter. Hatte das Problem selbst und genau die beschriebenen Symptome wie Du. Der Lüfter war ausgefallen und unter Last blieb das Teil einfach komplett stehen, nix im Syslog und supernervig...

Natürlich kriegt man dann murphymäßig nicht so nen passenden Lüfter auf die Schnelle. Hab das Problem dadurch gelöst, dass ich den Ventilator aus dem Chassis rausgebrochen hab, das Gehäuse wieder auf den Kühlkörper geschraubt- und dann einen CPU-Lüfter mit Sekundenkleber draufgeklebt hab   :Twisted Evil: 

P.S.: Sieht sch**sse aus, aber es geht  :Laughing: 

----------

## NightDragon

*g* Naja... es ist ein notebook.

die temperatur scheint okay zu sein. ist nicht über 40 grad.

und früher gings ja auch.

----------

## Sumpfdrache

OK, galt auch nur fÃ¼r TowergehÃ¤use, Asusboards und entsprechende anzunehmende Skrupellosigkeit   :Laughing: 

Ansonsten, hm, evtl mal nen anderen Kernel ausprobieren, aber hab leider sonst auch keinen anderen Schimmer  :Sad: 

----------

## NightDragon

Probiert efolglos  :Sad: 

Genauso mit anderen samba versionen, egal ob wireless oder onboard ethernet usw... total komisch...

----------

## NightDragon

Wie ist das eigentlich mit Linux...

ich bin eben dabei alles neuzumergen das irgendwie net im Packetname oder in einer net-kategorie ist.

Was könnte man noch alles durchchecken?

Wie geht Linux vor wenn es aufs netz zugreift?

----------

## manuels

 *Quote:*   

> Was könnte man noch alles durchchecken? 

 

was seht denn so in den loggs kurz vorm aufhängen?

 *Quote:*   

> Wie geht Linux vor wenn es aufs netz zugreift?

 

wie meinst du das? die kernelebene oder die samba ebene?

worauf willst du hinaus?

----------

## NightDragon

Die Logs sind unauffällig, die sagen Null darfüber aus was passiert.

Kein Log meldet was komisches... alles wies im normalen Betrieb auch ist.

Sprich es wird darüber nix verzeichnet und es gibt auch kein Muster...

Das einzige ist, ist das ich den Fehler repdorduzieren kann, indem ich einfach Daten übertrage.

Es ist außerdem Dienst unabhängig. es muss nicht via samba sein ... es kann auch licq oder sonst was sein.

Nervig wird das ganze bei VoIP oder cups via lan...

Weil sich da der Rechner zu 90% aufhängt...

----

Mich würde einfach interessieren welche packete ich mir genau anschauen müsste, um dem ganzen auf die Schliche zu kommen.

----------

## think4urs11

Am ehesten würde ich auf Kernel tippen, speziell das NIC-Modul.

Hast du APM/ACPI aktiv, das auch testhalber mal komplett deaktiviert?

Passiert das ganze auch bei Übertragungen LAN <-> LAN oder nur bei LAN <-> Internet?

Im letzteren Fall - hast du mal das Modem (PPPoA nehme ich an in Ö?) tauschen lassen?

Eine Freundin von mir hatte mal ewig ein ähnliches Problem, jeder Upload (Anhang an Mails z.B.) und ihre I-Net-Verbindung war weg/gestört.

Erst nachdem endlich das Modem getauscht wurde war alles plötzlich wieder in Ordnung.

----------

## NightDragon

die kernel würde ich ausschließen. Genauso das Netzwerkodul.

Wie ganz oeben erwähnt spielt es keine Rolle ob Kernel internes Sis 900 Modul oder madwifi treiber... egal welche version.

Das Problem tritt wie auch schon gesagt, bei JEDER art von Netzwerkverkehr auf.

egal ob LAN oder Internet.

----------

## manuels

naja, das heißt aber nicht, dass es trotzdem nicht der kernel sein könnte.

muss ja nicht der gerätetreiber sein, sondern vielleicht generell ein fehler in der netzwerkdatenverarbeitung des kernels.

hast du mal einen anderen kernel ausprobiert (komplett neue .config) oder es mit win oder knoppix versucht?

-> wenn es bei knoppix läuft würde ich es auf den kernel schieben

----------

## NightDragon

Windows und knoppix laufen problemlos.

Wieso ich die Kernel ausschließe hat folgenden Grund.

Als der Fehler passierte, war das nach einem update. Aber nicht nach einem kernel-update sondern einem packet-update.

Da der Fehler aber nicht sofort auftaucht sondern nur bei höheren datentransferraten, kann das auch etwas früher schon passiert sein. Sprich ich weiß nur das es nach einem update, das nicht die kernel betroffen hat, passierte.

Die Kernel wurde mehrmals gewechselt... Und auch alle configs neu gemacht.

Sprich die Kernel kanns schon fast nicht mehr sein.

Habe mehrere varianten durchprobiert. 

Zu dem zeitpunkt als der Fehler das erste mal auftrat (vor gut über einem halben jahr), war die damalige kernel unverändert und länger in betrieb.

Ich vermute eher ein Modul/Programm nach der Kernel.

----------

## manuels

 *Quote:*   

> Ich vermute eher ein Modul/Programm nach der Kernel.

 

also module gehören ja zum kernel, aber wenn du meinst es könnte an einem programm liegen, schreib dir doch ein kleines programm, dass mit udp packeten dein netzwerk flooded.

wenn das Programm nicht läuft, sehe ich keinen grund, warum es an einem programm liegen sollte.

Ich finde, dass auch gegen ein programmfehler spricht, dass es bei allen programmen auftaucht, nicht nur bei einzelnen

----------

## NightDragon

Naja...

Es geht dabei wohl eher darum wie die Kernel die Daten verwaltet.

Wie das ganze bei Linux abläuft... und kernel eigene Module und fremdmodule unterscheide ich schon.

Interessant ist ja nur das es anscheinen egal ist ob via WLAN(PCMCIA) oder Ethernet(onBoard).

D. h. es kann schon mal nicht an den madiwifi-modulen oder dem sis900 modul (das in die kernel nmtegriert ist) liegen.

Was aber blebt dann noch?

ich weiß von herumprobieren das es egal ist welche kernel.

Das BIOS selbst ist auch auf den aktuellsten stand und außerdem funktionierte das alles ja schon... Ist ja nicht so das es nie ging...

Komische sache eben. Wie könnte ich das ganze loggen?

----------

## manuels

 *Quote:*   

> ich weiß von herumprobieren das es egal ist welche kernel. 

 

aber wenn es knoppix kann, würde ich schon sagen, dass deine kernelkonfiguration irgendwie einen fehler hat.

poste doch mal deine .config dann könnten wir die mit unseren vergleichen

----------

## NightDragon

uff naja *g* die aktuelle ist ja nicht gerade die kernel-config die ich als einzige ausprobiert habe...

zur konfig möchte ich noch sagen das ich bereits eine minimnal-netzerkkonfig verwendet hatte.

Sprich alles experimentelle war mal draußen.

Da es der Kernel aber egal war, hab ichs wieder reingegeben.

naja. ich hab ja geschrieben, das die kernel älter ist als das problem.

also die damalige... mittlerweile habe ich natürlich auch eine aktuelle Kernel. weil es keinen unterschied machte,

die Konfig ist hier zu finden:

http://www.shadowghost.net/others/.config

Na da ich ohnehin den Fehler nicht weiter lokalisieren kann, gebe ich euch mal alle infos die ihr haben wollt. Mehr wie das ich das problem los bin kann ja nicht sein.

PS.: Es handelt sich um das in der Signatur angegebene P4 System.

----------

## Anarcho

Sollte es tatsächlich an einem Programm liegen dann kann es nur, da es bei diversen Programmen auftaucht, an einer gemeinsam benutzten Library liegen und da fällt mir spontan eigentlich nur die glibc auf. 

Hast du vielleicht zu dem Zeitpunkt mit hardened USE Flags experimentiert oder sowas? Vielleicht einfach mal die glibc neu emergen und testen.

----------

## tam

Ich hatte mal genau das gleiche Problem. Bei mir war die Soundkarte und die NIC auf dem gleichen IRQ. Als ich das geändert hatte, war das Problem verschwunden.

----------

## Anarcho

 *tam wrote:*   

> Ich hatte mal genau das gleiche Problem. Bei mir war die Soundkarte und die NIC auf dem gleichen IRQ. Als ich das geändert hatte, war das Problem verschwunden.

 

 *NightDragon wrote:*   

> ... und es liegt auch kein IRQ-Konflikt vor.

 

Das hat er wohl schon geprüft.

Ausserdem wird es da bei nem Laptop auch verdammt schwer was dran zu ändern. Umstecken ist da nicht.

----------

## NightDragon

Naja.-.. die IRQs sind ja nach wie vor virtuell... sprich die werden nach Adressen belegt.

Aber IRQ-Konflikt ists wie schon gesagt keiner...

Hm... die glibc ist ganz normal gemergt worden... wurde erst beim letzten update wieder gemergt.

----------

## tam

 *Anarcho wrote:*   

>  *NightDragon wrote:*   ... und es liegt auch kein IRQ-Konflikt vor. 
> 
> Das hat er wohl schon geprüft.

 

Wollte es trotzdem nochmal anmerken   :Smile:  weil es eben ganz genau so war.

 *Quote:*   

> Ausserdem wird es da bei nem Laptop auch verdammt schwer was dran zu ändern.

 

Meistens kann man im BIOS was einstellen. Bei meinem zumindest.

Vielleicht kann der OP mal sein /proc/interrupts posten.

----------

## NightDragon

Morgen zusammen...

Wow der Tag war wieder heftig:

Anbei cat /proc/interrupts

 *Quote:*   

>            CPU0       
> 
>   0:      53104-XT-PIC  timer
> 
>   1:         30          XT-PIC  i8042
> ...

 

Wie man erkennen kann ist hier das yenta zusammen gelegt mit USB...

und der andere yenta Slot mit dem Firewire... wenn ich das richtig sehe.

ich hatte eine Zeitlang ziemlich viele ERRors... diese wurde ich los durch umkonfigurieren der IRQ's im BIOS.

Hm... ich hatte auch bereits das USB+Firewire aus... sprich, so dass nichts den yenta (und somit die PCMCIA-Karte) strören kann.

Ohne erflog.

Hier noch die Ausgabe von der onboard-NIC.

Diese scheint in der IRQ-Tabelle ja nicht auf:

 *Quote:*   

> root@ndragon / # ifconfig eth0
> 
> eth0    Protokoll:Ethernet  Hardware Adresse 00:00:E2:96:13:AC  
> 
>           BROADCAST MULTICAST  MTU:1500  Metric:1
> ...

 

Das Interface ist normalerweise down (startet via ifplugd... wenn das Kabel eingesteckt wird).

Ach ja... was auch noch interessant ist, aber vielleicht normal wenn man WLAN hat mit WPA ist folgende Ausgabe (bitte auf die Fehler achten):

 *Quote:*   

> 
> 
> ath0   Protokoll:Ethernet  Hardware Adresse 00:09:5B:93:29:F5  
> 
>           inet Adresse:10.0.1.12  Bcast:10.0.255.255  Maske:255.255.0.0
> ...

 

----------

## tam

Hast Du mal versucht im BIOS alles zu dekativieren was geht (außer LAN)? Ich tippe nach wie vor auf ein IRQ Problem.

----------

## m.b.j.

Bios Update gemacht?

----------

## manuels

noch ne idee, was wäre denn wenn du via qos die "absturzschwelle" herausfindest, falls diese nur knapp über der maximalen auslastung liegt, kannst du es ja dabei belassen.

Will sagen:

Maximale Übertragungsrate setzen.

----------

## prior_philip

Ich habe aktuell ein ganz ähnliches Problem eben nur bei NFS. Sobald ich Datentransfers, wie DVD Backups, tätige, schmiert der Server früher oder später ab. In meinem Fall ist ein VIA Epia V8000. Hier liegt der Verdacht nahe das es sich um ein DMA Problem handelt, da auch die Festplatte sehr aktiv ist.

Vielleicht deaktivierst du versuchsweise mal den DMA Transfer deiner IDE Interfaces.

Gruß

----------

## NightDragon

@tam 

hab ich probiert - ohne erfolg

@m.b.j

Das aktuellste das FJSC rasugegeben hat, ist drauf.

@manuels

Naja... anscheinend ist es so... als würde es einen gewissen bereich geben, der aber nicht ganz klar ist.

Sprich so zwischen x und y... An die idee habe ich nämlich auch gedacht... wäre zumindest ein workaround...

wobei die frage ist wo das passiert... Wenn das ganze im TCP-IP Stack passiert, dann bringts wahrscheinlich nur wenig.

Aber eine idee ist es  :Smile: 

@prior_philips

Der Server hat bei mir Null probs... und das prob scheint von CPU und Plattenauslastung unabhängig zu sein

Gestern habe ich die gesamte Kernel nochmals neu konfiguriert (von 0 weg). Ohne erfolg...

einige Tage zuvor alle "net" packete gemergt (sys-net / net-lib usw...) Aber auch nichts....

----------

## NightDragon

Uuuiiiiiiiiiii:

Leute kleiner Nachtrag.

Durch zufall habe ich eben etwas entdeckt, das der Auslöser des problems sein könnte.

Allerdings ist dieser Fehler völlig neu für mich:

 *Quote:*   

> Nov 29 23:20:00 ndragon irq 7: nobody cared (try booting with the "irqpoll" option)
> 
> Nov 29 23:20:00 ndragon [<c0150bba>] __report_bad_irq+0x2a/0xa0
> 
> Nov 29 23:20:00 ndragon [<c0150430>] handle_IRQ_event+0x30/0x70
> ...

 

Jope. so schauts aus.

Dieser Fehler stand eben in meinem Systemlog.

Hatte ich vorher noch nie zu gesicht bekommen, den Fehler.

Sprich er scheint neu zu sein.

Er tritt mitten im Betrieb auf (unabhängig von Arbeiten mit dem Netzwerk), und wie man sehen kann läuft das System aber noch weiter.

Kleine Info: Natürlch habe ich bereits mit dem Parameter gebootet.

Allerdings erhalte ich dann bei /proc/interrupts jede Menge fehler (ERR: steigender Zahlenwert)

Abhilfe schafft das bei den Abstürtzen außerdem auch nicht.

----------

