Disk I/O blockiert System

[Corben]

Hallo,

auf meinem Notebook (Samsung X20) habe ich Debian Sid installiert. Die Hardware wird soweit auch fast vollständig unterstützt. Das einzige Problem, das ich habe, sind Plattenzugriffe, die manchmal mehr manchmal weniger lang das System zum Gefrieren bringen. Dann funktioniert weder die Tastatur noch lässt sich der Mauszeiger bewegen. Meist sind das nur ganz kurze Unterbrechungen für einen Bruchteil einer Sekunde, die ich nur dann merke, wenn ich gerade etwas tippe oder eben die Maus bewege. Aber ab und zu auch mal 2-3 Sekunden.

Mein erster Gedanke war, dass DMA ausgeschaltet ist, aber so ist es nicht. Von hdparm wird DMA als aktiviert angezeigt und hdparm -t liefert um die 30 MB/s, was für eine 2,5"-Platte in Ordnung ist.

Im Systemmonitor (Applet von Gnome) wird jedesmal, wenn das Problem auftritt, ein IO-Wait von ungefähr 100% angezeigt.

Das Systemlog zeigt nichts besonderes an.

Das einzig auffällige ist - außer den Freezes - die RTC: hwclock funktioniert nur mit Parameter --directisa. Aber ich weiß nicht, ob das wirklich etwas mit den Unterbrechungen zu tun haben kann.

Ich bin für jede Idee, woran es liegen könnte, dankbar.

So, zum Abschluss noch Infos zu meiner Hardware.

lspci -v
http://nopaste.debianforum.de/436

lsmod
http://nopaste.debianforum.de/437

[comes]

Hallo und Herzlich Willkommen im Forum!

was sagt den

Code: Alles auswählen

hdparm -v /dev/hda

?

[Corben]

was sagt den

Code: Alles auswählen

hdparm -v /dev/hda

?

Code: Alles auswählen

/dev/hda:
 multcount    =  0 (off)
 IO_support   =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 geometry     = 16383/255/63, sectors = 155306477, start = 0

Ich hatte auch schon testweise -c3 und -m16 gesetzt, das hat zwar etwas mehr Performance gebracht, aber das Problem leider auch nicht beseitigt.

[malachay]

Welche Kernelversion hast du denn?

[Corben]

Welche Kernelversion hast du denn?

Die neueste in Sid: 2.6.11-6

Ich bin mir inzwischen auch gar nicht mehr so sicher, ob das überhaupt ein Hardware-/Treiber-Problem ist. Könnte genau so gut sein, dass irgendein Daemon oder vielleicht sogar Gnome Ärger macht.

Ist es denn normal, dass annähernd 100% I/O-Wait ein Gefrieren des Systems bewirkt? Ist es überhaupt normal, dass man öfters mal annähernd 100% I/O-Wait hat? Mir ist das jetzt zum ersten Mal aufgefallen. Allerdings habe ich jetzt auch zum ersten Mal darauf geachtet.

[malachay]

Welche Kernelversion hast du denn?

Die neueste in Sid: 2.6.11-6

Ich bin mir inzwischen auch gar nicht mehr so sicher, ob das überhaupt ein Hardware-/Treiber-Problem ist. Könnte genau so gut sein, dass irgendein Daemon oder vielleicht sogar Gnome Ärger macht.

Ist es denn normal, dass annähernd 100% I/O-Wait ein Gefrieren des Systems bewirkt? Ist es überhaupt normal, dass man öfters mal annähernd 100% I/O-Wait hat? Mir ist das jetzt zum ersten Mal aufgefallen. Allerdings habe ich jetzt auch zum ersten Mal darauf geachtet.

Ich denke es ist normal das annähernd 100 % I/O Wait ein einfrieren bewirkt, allerdings ist ein iowait > 90% alles andere als normal.
Ich recherchier nun schon ein paar Tage dem Problem hinterher , es scheint erst im Kernel 2.6 aufzutauchen, genauer: ab 2.5.60 . Ich habe schon einiges in einem Thread zusammengestellt, allerdings musst du da bei der "Konkurrenz" mal schaun :
http://forums.gentoo.org/viewtopic-t-349889.html

Edit:
Es ist wohl definitiv ein Kernelproblem. Kann also ruhig ins richtige Forum verschoben werden.

[Corben]

Ich denke es ist normal das annähernd 100 % I/O Wait ein einfrieren bewirkt, allerdings ist ein iowait > 90% alles andere als normal.

Nur habe ich kurz nachdem ich das oben geschrieben hatte, über einen längeren Zeitraum (5-10 Sek.) wieder einen hohen iowait, wobei das System aber nicht wirklich ins Stottern gekommen ist.

Deshalb tendiere ich momentan stärker zur Vermutung, dass es nur zum Gefrieren kommt, wenn ein bestimmter Prozess auf die Platte zugreift.

Außerdem habe ich mal versucht, das Verhalten von http://bugzilla.kernel.org/show_bug.cgi?id=2864 nachzuvollziehen, aber selbst wenn iostat mal mehr als 90% iowait angezeigt hat, lief mein System immer noch flüssig.

Ich recherchier nun schon ein paar Tage dem Problem hinterher , es scheint erst im Kernel 2.6 aufzutauchen, genauer: ab 2.5.60 .

Gut, das lässt sich ja leicht nachprüfen. Dann installiere ich einfach mal einen 2.4er Kernel. Mal schaun, was dann überhaupt noch funktioniert.

[LessWire]

Hallo zusammen,

habe dasselbe Problem, nun seit einigen Monaten. Kann zwar gerade so damit leben, wirklich ärgerlich sind die hin und wieder auftretenden Aussetzer bei MP3-/DVB-Playback.

Ich gehe mittlerweile davon aus, daß es an einer im Kernel fehlerhaften Unterstützung der Hardware (P4, Intel-ICH5-Chipsatz) liegt. Auf meinen alten P3-Systemen mit identischer Konfiguration gibts diese Probleme nicht.

vg, L.W.

[malachay]

Hallo zusammen,

habe dasselbe Problem, nun seit einigen Monaten. Kann zwar gerade so damit leben, wirklich ärgerlich sind die hin und wieder auftretenden Aussetzer bei MP3-/DVB-Playback.

Ich gehe mittlerweile davon aus, daß es an einer im Kernel fehlerhaften Unterstützung der Hardware (P4, Intel-ICH5-Chipsatz) liegt. Auf meinen alten P3-Systemen mit identischer Konfiguration gibts diese Probleme nicht.

vg, L.W.

Auf meinem guten alten P3 hatte ich das auch nicht....
Das Problem betrifft also Chipsätze von Nvidia,Via und Intel, von SIS weiss ich jetzt noch nichts.
Werde heute noch folgende Bugzilla Einträge erweitern:
http://bugzilla.kernel.org/show_bug.cgi?id=2864
http://bugzilla.kernel.org/show_bug.cgi?id=3094
In der Hoffnung das sich ernsthafter um das Problem gekümmert wird.

[malachay]

Ich hab mit dem 2.6.12-mm1 eigentlich sehr gute Ergebnisse.
Das System fühlt sich besser an, auch wenn die bonnie++ Benchmarks nicht viel besser sind, auch das entpacken großer, gezippten Archiven geht nun deutlich schneller.

[meti]

Das gleiche Problem quält mich auch. Auf dem Server (mit Sarge) läuft alles glatt, aber auf meinem Laptop (desktop-Ersatz), ein Toshiba Satelllite 1950-801 hab ich auch diese Aussetzer.

Bisher konnte ich aber noch keine Ursache finden.

[Savar]

Edit:
Es ist wohl definitiv ein Kernelproblem. Kann also ruhig ins richtige Forum verschoben werden.

da geb ich dir Recht

verschoben von "andere Hardwareprobleme"

Gruß Savar

PS:

Code: Alles auswählen

/dev/hda:
 multcount    =  0 (off)
 IO_support   =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 geometry     = 16383/255/63, sectors = 155306477, start = 0 

das sieht irgendwie komisch aus.. ich hab noch mutlicount an und IO_support auch ..

Code: Alles auswählen

/dev/hda:
 multcount    = 16 (on)
 IO_support   =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 geometry     = 16383/255/63, sectors = 117210240, start = 0

[malachay]

Edit:
Es ist wohl definitiv ein Kernelproblem. Kann also ruhig ins richtige Forum verschoben werden.

da geb ich dir Recht

verschoben von "andere Hardwareprobleme"

Gruß Savar

PS:

Code: Alles auswählen

/dev/hda:
 multcount    =  0 (off)
 IO_support   =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 geometry     = 16383/255/63, sectors = 155306477, start = 0 

das sieht irgendwie komisch aus.. ich hab noch mutlicount an und IO_support auch ..

Code: Alles auswählen

/dev/hda:
 multcount    = 16 (on)
 IO_support   =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 geometry     = 16383/255/63, sectors = 117210240, start = 0

Hm, stimmt, das sollte unbedingt überprüft werden. Ich hab mich so verbissen in das iowait Thema das ich das gar nicht gesehen habe.
Bevor man aber mit hdparm rumschraubt -> unbedingt die man-page dazu lesen!

[Corben]

Savar und malachay, bitte lest nochmal meinen Beitrag, in dem ich die Ausgabe von hdparm gepostet habe. DMA setzt der IDE-Treiber bereits von selbst auf on, Multicount etc. ändern nichts an dem Problem.

Dann habe ich so meine Zweifel, ob malachay und ich wirklich das selbe Problem haben. Wenn ich z.B. mit bonnie++ hohe I/O-Last erzeuge, bekomme ich zwar auch hohe iowait-Werte, aber ohne dass es zum Gefrieren kommt.

Wenn ich dagegen praktisch nichts mache, höchstens etwas in einem Editor tippe (was ja weder den Prozessor noch die Platte besonders belastet), vor allem dann kommt es zu diesem Verhalten. Aber auch nicht immer.

Ich habe mir mal mit

Code: Alles auswählen

echo 1 > /proc/sys/vm/block_dump

ausgeben lassen, welche Prozesse auf die Platte zugreifen, wenn das Problem auftritt. Allerdings war das auch keine große Hilfe, da es nur kjournald und pdflush waren.

[malachay]

Sind es vielleicht irgendwelche cpu-freq-daemons die auf höhere Taktungen umschalten? (Und dabei alle Prozesse erst einmal blocken?)
Ist der Kernel preempt.?

[Corben]

Sind es vielleicht irgendwelche cpu-freq-daemons die auf höhere Taktungen umschalten? (Und dabei alle Prozesse erst einmal blocken?)

Ja, das ist ein interessanter Punkt. Ich habe am Anfang powernowd benutzt und den auch erst in verdacht gehabt. Inzwischen habe ich ihn allerdings wieder entfernt.

Jetzt setze ich einfach

Code: Alles auswählen

echo "ondemand" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Ich habe auch mal getestet, ob festes Setzen einer der möglichen Frequenzen das Problem beseitigt. Leider hat das auch nichts gebracht.

Aber dass irgendwelche Stromsparfunktionen (bzw. ACPI) der Grund für die Freezes sein könnten, halte ich immer noch für durchaus wahrscheinlich. Es sind nämlich immer solche Situationen, in denen von wenig Last kurz auf hohe Last umgeschaltet wird.

Ich werde am Wochenende, wenn ich etwas Zeit habe, mal versuchen, einen 2.4er-Kernel und / oder eine andere Distribution zu verwenden.

Ist der Kernel preempt.?

Kann ich so spontan nicht sagen. Sag mir, welche Kernel-Option dafür verantwortlich ist und ich schaue nach.

[malachay]

Preemptible Kernel:

Code: Alles auswählen

Processor type and features  --->
[*] Preemptible Kernel
   [*]   Preempt The Big Kernel Lock   

Da musst du einfach mal ausprobieren ob es dir hilt es entweder abzuschalten wenn es schon aktiviert ist oder zu aktivieren wenn es deaktiviert ist
Einge berichten das die preempt. Geschichte nur Probleme macht, bei anderen bewirkt es das was es soll: Ein System was unter Last besser schnell reagiert.
Wobei ja wie du sagts, du keine Probleme unter Last hast, sonder nur bei Lastwechsel...

Allerdings denke ich auch eher das es in deinem Fall Stromsparfunktionen sind, wird denn die Festplatte abegschaltet??

[Corben]

Allerdings denke ich auch eher das es in deinem Fall Stromsparfunktionen sind, wird denn die Festplatte abegschaltet??

Nein, es wird nur der Kopf geparkt. Die oben genannten Prozesse pdflush und kjournald lassen ein richtiges Abschalten gar nicht erst zu, weil sie dauernd auf die Platte zugreifen.

Aber mir ist inzwischen etwas anderes aufgefallen. Wenn ich mit hdparm den Durchsatz messen lasse, schwanken die Werte stark. Ich bekomme zwischen 30 und 10 (!) MB/s gemeldet. Gerade eben noch mal gemessen und es waren 19 MB/s.

Unter Windows (mit HDtach gemessen) bekomme ich konstant hohe Werte.

[LessWire]

Ich will mal den Thread nochmal aufleben lassen, denn es lässt sich die Ursache für die Aussetzer mit meiner SATA-Disk eingrenzen.

1. Ich habe im BIOS die Automatik für UDMA deaktiviert. Ergebnis: Es wird endlich UDMA-6 verwendet. HDPARM -tT ermittelt ca. 1850 MB/sec cached reads und ca. 54 MB/sec mit buffered disk reads. Ich denke, das kann sich sehen lassen.

2. Mein IDE-Controller wird zusammen mit der Netzwerkkarte über IRQ 3 angesprochen. Ein vermutlich nicht gerade brauchbares IRQ-Sharing, denn der kurzzeitige Stillstand, verursacht durch extrem hohen iowait, passiert fast ausschliesslich bei erhöhtem Nettraffic mit gleichzeitigen Diskwrites.

Leider sehe ich aber keine Möglichkeit, im BIOS entweder nur IDE oder nur dem Netzwerk einen anderen, "ruhigeren" IRQ zuzuweisen.
Gäbe es eine andere Möglichkeit ?

vg, L.W.