Etch (64-Bit): Probleme mit DMA (vermutlich)

[greyhound]

Hallo zusammen !

Ich bin noch relativ neu auf dem Gebiet Linux und habe bisher nur Erfahrungen mit Ubuntu sammeln können (sprich apt-get reinklopfen und fertig ). Nun hab ich mir aus Neugierde das Etch-"Netinst"-Image geschnappt und das Ganze auf meinem Zweitrechner installiert. Ich habe nur die Grundinstallation + Dateiserver (Samba) ausgewählt, mehr brauche ich vorerst nicht. Nach der Installation hab ich gleich ein update + dist-upgrade ausgeführt, um aktuell zu sein.

Nun zu meinem Problem:

Wenn ich Dateien von meinem Hauptrechner übers LAN auf den Zweitrechner kopiere, beträgt die CPU-Auslastung auf der Debian-Kiste fast immer 85% oder mehr, auch dann, wenn ich Dateien nur auf der Platte der Debian-Kiste rumkopiere. Mein erster Gedanke war: Das kennst du doch irgendwoher, wahrscheinlich ist DMA nicht aktiviert ?!
Also "hdparm" installiert und überprüft... Ergbnis -> DMA = 1 (on). Hmm, komisch ! Ich hab dann ein bissl rumgegoogelt und habe u.a. gelesen, dass Etch Probleme mit manchen VIA-Chipsätzen hat.

Mein System:

- MSI Sockel 939-Board mit VIA K8T800 Pro Chipsatz
- Athlon 64 3500+
- 2GB RAM
- 2x160 GB Samsung-Platten (Software RAID1)

Wär super, wenn hier jemand das Problem kennt und mir weiterhelfen könnte. Gibt es eventuell auch die Möglichkeit, einen aktuelleren Kernel einzuspielen, der das Problem vieleicht behebt ? Wie funktioniert das genau mit den Backports ?

Danke schonmal !

p.s.: das Problem hab ich auch mit der 32-Bit Version

[greyhound]

Ich bin's nochmal.

Ich hab jetzt testweise mal den aktuellen daily-testing-build installiert (2.6.22er Kernel) und da hab ich das gleiche Problem...

[cirrussc]

Hi,

Wie funktioniert das genau mit den Backports ?

Ist auf der Projekt Seite Beschrieben. Und SuFu benutzen!
Was sagen denn die Tests von hdparm?

Code: Alles auswählen

hdparm -tT /dev/xxx

Könnte es nicht auch am Software RAID liegen?

[greyhound]

Ich glaube du hast Recht ! Ich hab jetzt nochmal nen Ubuntu-Server aufgesetzt und die CPU-Last ist da genauso hoch ! Ich werde es jetzt denk ich anders machen:

Ich erstelle ne separate Backup-Partition und nur die wird gespiegelt. Das eigentliche System läuft auf einer Platte...

Dein Test sagt folgendes:

Timing cached reads: 2132 MB in 2.00 seconds = 1065.92 MB/sec
Timing buffered disk reads: 180 MB in 3.00 seconds = 59.99 MB/sec

Edit:

So, jetzt hab ich das ganze ohne RAID installiert und die Last is trotzdem noch so hoch...

[Spasswolf]

Code: Alles auswählen

 Timing cached reads: 2132 MB in 2.00 seconds = 1065.92 MB/sec
Timing buffered disk reads: 180 MB in 3.00 seconds = 59.99 MB/sec 

Das scheint nicht das Problem zu sein.
Was sagt denn top zur Cpu Last, stell mal die Ausgabe von top -b nach http://nopaste.debianforum.de/
Gibt's Meldungen in /var/log/syslog oder /var/log/messages?

[greyhound]

Hab ich gemacht:

http://nopaste.debianforum.de/7410

[Spasswolf]

Du hast jetzt ohne Raid installiert? Da scheint aber noch eins zu sein:

Code: Alles auswählen

1073 root 10 -5 0 0 0 S 2.0 0.0 0:04.52 md1_raid1
1074 root 10 -5 0 0 0 D 2.0 0.0 0:05.51 md1_resync

Was sagen denn

Code: Alles auswählen

cat /proc/mdstat
fdisk -l

[greyhound]

Oh ne sorry, ich hab's wieder als RAID installiert, da es von der Auslastung her keinen Unterschied gemacht hat.

cat /proc/mdstat:

Code: Alles auswählen

~# cat /proc/mdstat
Personalities : [raid1]
md2 : active raid1 sda4[0] sdb3[2]
      1855424 blocks [2/1] [U_]
        resync=DELAYED

md1 : active raid1 sda3[0] sdb2[2]
      133789248 blocks [2/1] [U_]
      [>....................]  recovery =  1.0% (1380736/133789248) finish=52.2min speed=42232K/sec

md0 : active raid1 sda2[0] sdb1[1]
      120384 blocks [2/2] [UU]

unused devices: <none>

fdisk -l:

Code: Alles auswählen

~# fdisk -l

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        2550    20482843+   7  HPFS/NTFS
/dev/sda2            2551        2565      120487+  fd  Linux raid autodetect
/dev/sda3            2566       19221   133789320   fd  Linux raid autodetect
/dev/sda4           19222       19457     1895670   fd  Linux raid autodetect

Disk /dev/sdb: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1          15      120456   fd  Linux raid autodetect
/dev/sdb2              16       16671   133789320   fd  Linux raid autodetect
/dev/sdb3           16672       16902     1855507+  fd  Linux raid autodetect
/dev/sdb4           16903       19457    20523037+   f  W95 Ext'd (LBA)
/dev/sdb5           16903       19457    20523006    7  HPFS/NTFS

Disk /dev/md0: 123 MB, 123273216 bytes
2 heads, 4 sectors/track, 30096 cylinders
Units = cylinders of 8 * 512 = 4096 bytes

Disk /dev/md0 doesn't contain a valid partition table

Disk /dev/md1: 137.0 GB, 137000189952 bytes
2 heads, 4 sectors/track, 33447312 cylinders
Units = cylinders of 8 * 512 = 4096 bytes

Disk /dev/md1 doesn't contain a valid partition table

Disk /dev/md2: 1899 MB, 1899954176 bytes
2 heads, 4 sectors/track, 463856 cylinders
Units = cylinders of 8 * 512 = 4096 bytes

Disk /dev/md2 doesn't contain a valid partition table

[Spasswolf]

Dann lass das Raid mal fertig syncen bei 137Gb kann das durchaus 90 min daueren. Den Fortschritt kannst du mit

Code: Alles auswählen

cat /proc/mdstat

überwachen. Erst wenn da nichts mehr resynced würde ich weiter nach dem Problem suchen.

[greyhound]

Das RAID hat nach ~60min ausgesynct
Die Auslastung ist nach wie vor so hoch, ich weiß langsam echt nicht mehr weiter. Ich denke aber, dass es doch irgendwas mit dem VIA Chipsatz zu tun haben könnte...

[Spasswolf]

Dann poste bitte nochmal:

Code: Alles auswählen

top -b
dmesg

[greyhound]

http://nopaste.debianforum.de/7414

[Spasswolf]

Verschiebe die Dateien bitte nach http://nopaste.debianforum.de/
Was genau läuft den langsam, auf den ersten Blick sieht es so aus, als sei das Problem behoben:
Vorher:

Code: Alles auswählen

load average: 1.92, 1.67, 0.93

Nachher:

Code: Alles auswählen

load average: 0.05, 0.01, 0.00

[greyhound]

Nene, die Messungen hab ich gemacht, als ich keine Daten rumgeschoben hab, sprich im Leerlauf. Beim Datenschieben ist die Last nach wie vor noch so hoch.
Die kleine Dauerauslastung von ~2-3% kam ja wohl nur durch das syncen zustande.