# Großes Ratespiel...

## NightDragon

Hallo zusammen.

Also Jungs.

Ich habe da ein Problem das mich etwas doof aus der Wäsche gucken lässt.

Notebook (siehe Signatur). Stürzt verdammt gerne ab wenns darum geht Daten zu versenden oder zu empfangen (also nicht ein paar kb aber VOIP mit sipgate reicht schon aus.. oder ein ICQ-transport).

Manchmal hängt sich das ganze X auf, (geht aber auch ohne X in der konsole wo er sich aufhängt -  und egal ob kde oder nicht) und manchmal das ganze system.

Szenario: Ich sende jemanden (3 MB z. bsp.) via icq... die datei fängt an upgeloadet zu werden... und irgendwann... schwubs... hängt er (oder mit glück geht er noch weiter).

Sporadische Abstürze, es ist Egal:

ob

a) ich die WLAN-Karte verwende oder das onBoard LAN

b) ich es via Samba oder sonst was sende

c) welche Kernel ich verwende

d) wie groß die Datei ist

Besonders die Kombination "schnelle Übertragung" + X am laufen bringen ihn oft zum abstürzen.

Was könnte das sein?

Was schlagt ihr vor?

Wer rätselt mit?

Ansonsten ist das System sehr stabil...

----------

## 76062563

Steht im log was?

Siehst du Fehler wenn du ifconfig aufrufst?

----------

## NightDragon

ifconfig ist fehlerfrei, genauso wie alle logs die ich bisher fand (xorg log bis hin zum systemlog usw...)

das system hängt sich wenn, voll auf und wenn nur teils, dann ohne fehler...

...

----------

## think4urs11

thermische Probleme des NIC-Chips der dann evtl. den ganzen PCI-Bus blockt?

----------

## NightDragon

so plötzlich? und dann unabhängig obs WLAN oder onboard ist? ... nein unwahrscheinlich.

ach dazugesagt wäre noch das unter Knoppix und windows das problem nicht auftaucht...

----------

## think4urs11

überaggressive Cflags und Co.?

irgendwelche 'kritischen' Pakete '~x86' die in letzter Zeit ein Update hatten? (oder ist das ein generelles Problem auf der Kiste)

----------

## tam

Ich hatte mal was ähnliches als sich NIC und Soundkarte einen IRQ geteilt haben.

----------

## NightDragon

@Think4UrS11

dann dürfte das aber nicht jegliche Übertragung beeinflussen und schon gar nicht in einem vollen hang up verursachen.

Die kernel, so wie samba sind alle keine ~x86.

agressiuce Cflags? schließe ich mal aus, die kernel wird ja nicht mit normalen cflags compiliert.

@tam

irq sharing... hm guter ansatz... ich checks mal... (nur warum sollte die WLAN-PCMCIA-karte und der onboard-chip die selben IRQ zusammen mit einem anderne teilen?

[EDIT --> IRQ:]

IRQ 10 + 11:

Der PCMCIA-Controller (slot 1 +2) sowie der onboard Ethernet-Controller teilen sich den IRQ.

Ideen wie man sowas unterbinden kann? - nur um es testweise mal als "IRQ-Problem" auszuschließen

[/EDIT]

[EDIT die 2.]

Die IRQ-tabelle - da ist viel auf 11:

root@ndragon nightdragon # cat /proc/interrupts 

           CPU0       

  0:   11143797          XT-PIC  timer

  1:       6451          XT-PIC  i8042

  2:          0          XT-PIC  cascade

  7:      43125          XT-PIC  parport0

  9:      11078          XT-PIC  acpi

 10:     502024          XT-PIC  yenta, ath0

 11:    3818761          XT-PIC  ohci1394, yenta, ehci_hcd, ohci_hcd, ohci_hcd, ohci_hcd, SiS SI7012, SiS SI7013

 12:     320113          XT-PIC  i8042

 14:      87224          XT-PIC  ide0

 15:     100574          XT-PIC  ide1

NMI:          0 

LOC:          0 

ERR:          5

MIS:          0

Sind als 3, 4, 5, 6 und 8 frei sowie 13, oder?

[/EDIT 2.]

----------

## tam

 *NightDragon wrote:*   

> Ideen wie man sowas unterbinden kann? - nur um es testweise mal als "IRQ-Problem" auszuschließen

 

Ich würd mal im BIOS deines Notebooks nachsehen ob es da irgendwie eine Möglichkeit gibt.

----------

## NightDragon

@tam danke für den Tipp  :Wink:  Gestern gegen 2:00 ists mir dann auch eingefallen.

Nun habe ich folgende IRQ-Aufteilung (was anderes lies sich nicht machen):

```
  0:    2887739          XT-PIC  timer

  1:       6108          XT-PIC  i8042

  2:          0          XT-PIC  cascade

  5:          0          XT-PIC  parport0

  7:       4260          XT-PIC  yenta, ohci1394

  9:       1797          XT-PIC  acpi

 10:     625109          XT-PIC  ehci_hcd, ohci_hcd, SiS SI7012, SiS SI7013 Modem

 11:      91146          XT-PIC  yenta, ohci_hcd, ohci_hcd, ath0

 12:     160824          XT-PIC  i8042

 14:      32622          XT-PIC  ide0

 15:      24232          XT-PIC  ide1

NMI:          0 

LOC:          0 

ERR:          4

MIS:          0

```

Damit wären die IRQ etwas besser verteilt... 

Hat aber das Problem nicht geändert.

Ach ja: die ERR (ich denke mal das sollen Errors sein) steigen nicht... d. h. das passiert nur kurz wo ich meine PCMCIA-Karte reinstecke und dann bleibt die Fehleranzahl.

Ich würde langsam sogar soweit gehn, und sagen, das es die IRQ auch nicht sein können.

Weitere Ideen zu meinem Problem?

Ach noch ein kleiner zusatz: Das System wird selten wärmer wie 45 Grad und die CPU bleibt auch meist unter 50 grad, daher schließe ich thermische Fehler an der Hardware mal allgemein aus...

Was ist bei Linux den alles für den Datentransport zuständig?

Vielleicht hilft mir wer, den weg stückweise durchzugehn...

----------

## schachti

Hast Du mal für 1-2 Stunden memtest86 auf der Kiste laufen lassen?

----------

## NightDragon

Jope - so Fehlerlos sah ich Memtest niergendswo anderst außer hier.

Selbst auf meinem Gentoo-Server der 24/7 läuft, bringt Memtest Fehler (aber der läuft Problemlos) nur der Notebook wo Memtest ohne Meldung durchläuft, alles okay.

ich kann die CPU und den Speicher auch völlig ausnehmen, weil a) der RAM zwischendurch (afgerüstet) gewechselt wurde. und naja... die CPU hätte sich sonst anderwertig bemerkbar gemacht.

Er stürzt auch unter keiner Belastung ab, nur wenns ums Netzwerk geht.

----------

## NightDragon

*hochschieb* Hat keiner mehr Ideen?

----------

## amne

Schon einmal ein Bios-Update aus Verzweiflung versucht?

----------

## NightDragon

Jope... habe ich... down und upgeradet... *grübel* ich verstehs echt nicht mehr...

ich vermute auch ganz stak einen Softwarer fehler... es kann eine Option in der Kernel sein, oder irgendwas anderes das läuft. Aber soviel gibt es nicht das nach dem Systemstart irgendwie aufs Netz zugreift...

Irgendwann mal passierte der Fehler ... zur selben zeit als ich ein emerge world -u ausgeführt habe... also in etwa der selben Zeit. 

naja da sich der Fehler ja erst bei größeren Aktionen bemerkbar machte, könnte ich nicht mit sicherheit sagen ab wann der fehler auftrat... und ob er nun wirklich mit dem update zu tun hat.

Daher vermute ich eigentlich eher folgendes

a) eine Software die instabil wird

b) die Kernel selbst die irgendwo hängen anfängt

c) doch ein hardware-defekt? Aber welcher würde sich nur aufs Netz auswirken - egal ob PCMCIA oder onBoard?

Alles andere käuft ja problemlos.

----------

## amne

Wie siehts aus wenn du von einer Live-CD deiner Wahl bootest, tritt dann der Fehler auch auf?

----------

## NightDragon

Nope dann nicht... das System bleibt stabil.

Auch unter Knoppix

----------

## amne

Einen deutlich älteren Kernel booten hast du vermutlich auch schon versucht?

Mit den Magic-SysRQ Tastenkombinationen könntest du versuchen, den Fehler zu debuggen. Schau mal in /usr/src/linux/Documentation/sysrq.txt wie das geht, vielleicht bekommst du ja einen Hinweis, was nicht funktioniert.

----------

## NightDragon

Hi amne.

Ja also ne deutlich ältere Kernel wäre dann wohl die 2.6.9-r9.

Aber die brachte die selben Probleme  :Smile: 

Hm... aber danke für den Tipp mit Magic... ich werds mal durchspielen und dann schauen was es bringt...  :Smile: 

----------

