# 100% CPU auslastung beim Kopieren von/auf PCI IDE Controller

## borlander

Hy Leute.

[EDIT]

Der Fehler tritt bei allen Platten auf. Also liegt es nicht am Controller.

[/EDIT]

Ich habe 4 Platten in meinem Rechner 2 am Board und 2 an meinem

Silicon Image PCI-0860 ATA/133 Controller von Z-Cyber (nicht als RAID).

Pentium4 2Ghz

768 MB RAM

gentoo-dev-sourcen-2.6.8-r3

Device Drivers ->

ATA/ATAPI/MFM/RLL support ->

<*>         Silicon Image chipset support

Wenn ich nun von/auf einer der Platten große Datein kopiere steigt die CPU Last auf 100% (top zeigt 0% an und supercaramba zeigt 100% an). Die ersten 10 - 15 Sekunden ist der Durchsatz gut (15 - 25 MB/s). Dann bricht er auf 0,1 - 2 MB/s zusammen. Das ganze System ist dann fast unbrauchbar, da viel zu langsam.

hdparm -tT /dev/hde läuft gut (aber auch kurzzeitig mit 100% CPU Auslastung)

```
/dev/hde:

 Timing buffer-cache reads:   1332 MB in  2.00 seconds = 665.10 MB/sec

 Timing buffered disk reads:   84 MB in  3.03 seconds =  27.75 MB/sec

```

hdparm -I /dev/hde

```
ATA device, with non-removable media

        Model Number:       ST380020A

        Serial Number:      5GC0CQ7H

        Firmware Revision:  3.39

Standards:

        Supported: 6 5 4 3

        Likely used: 6

Configuration:

        Logical         max     current

        cylinders       16383   16383

        heads           16      16

        sectors/track   63      63

        --

        CHS current addressable sectors:   16514064

        LBA    user addressable sectors:  156301488

        device size with M = 1024*1024:       76319 MBytes

        device size with M = 1000*1000:       80026 MBytes (80 GB)

Capabilities:

        LBA, IORDY(can be disabled)

        bytes avail on r/w long: 4      Queue depth: 1

        Standby timer values: spec'd by Standard

        R/W multiple sector transfer: Max = 16  Current = 16

        Advanced power management level: unknown setting (0x0040)

        Recommended acoustic management value: 254, current value: 254

        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5

             Cycle time: min=120ns recommended=120ns

        PIO: pio0 pio1 pio2 pio3 pio4

             Cycle time: no flow control=240ns  IORDY flow control=120ns

Commands/features:

        Enabled Supported:

           *    READ BUFFER cmd

           *    WRITE BUFFER cmd

           *    Host Protected Area feature set

           *    Look-ahead

           *    Write cache

           *    Power Management feature set

                Security Mode feature set

           *    SMART feature set

           *    Device Configuration Overlay feature set

           *    Automatic Acoustic Management feature set

                SET MAX security extension

           *    Advanced Power Management feature set

           *    DOWNLOAD MICROCODE cmd

           *    SMART self-test

           *    SMART error logging

Security:

        Master password revision code = 65534

                supported

        not     enabled

        not     locked

        not     frozen

        not     expired: security count

        not     supported: enhanced erase

HW reset results:

        CBLID- above Vih

        Device num = 0 determined by the jumper

Checksum: correct

```

Was kann ich machen?? Wird der Chipsatz nicht richtig unterstützt??Last edited by borlander on Fri Sep 10, 2004 1:24 pm; edited 1 time in total

----------

## Jlagreen

Hi,

da ich grad nicht zu hause bin, kann ich nicht nach schauen, ob mein controller denselben chipsatz hat, war aber ein Sil 860 oder so, also deinem sehr ähnlich und bei mir läufts super mit den 2 UDMA66 platten, also werde dann später meine config im kernel checken

ich weiss noch, dass es 2 stellen im kernel gibt, an denen man den sil auswählen kann und eine hat bei mir nix gebracht (weil falsche), könnte aber für dich die richtige sein (unter raid-controller oder so)

----------

## borlander

Könnte es ein Fehler von reiserfs sein?? ich hatte die Partitionen gerade mit mkreiserfs formatiert. 

reiserfsprogs-3.6.11

progsreiserfs-0.3.0.4

----------

## PuckPoltergeist

ReiserFS ist zwar sehr CPU-intensiv, aber daß es so extrem ist, ist mir auch neu. Das hört sich eher nach fehlendem DMA an. Ist das für alle Platten aktiviert? Ansonst, steht was auffälliges im syslog?

----------

## borlander

```
hdparm -I /dev/hdg

/dev/hdg:

ATA device, with non-removable media

        Model Number:       Maxtor 4D080H4

        Serial Number:      D409RSJE

        Firmware Revision:  DAH017K0

Standards:

        Used: ATA/ATAPI-6 T13 1410D revision 0

        Supported: 6 5 4 3

Configuration:

        Logical         max     current

        cylinders       16383   16383

        heads           16      16

        sectors/track   63      63

        --

        CHS current addressable sectors:   16514064

        LBA    user addressable sectors:  160086528

        device size with M = 1024*1024:       78167 MBytes

        device size with M = 1000*1000:       81964 MBytes (81 GB)

Capabilities:

        LBA, IORDY(can be disabled)

        bytes avail on r/w long: 57     Queue depth: 1

        Standby timer values: spec'd by Standard, no device specific minimum

        R/W multiple sector transfer: Max = 16  Current = 16

        Advanced power management level: unknown setting (0x0000)

        Recommended acoustic management value: 192, current value: 254

        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5

             Cycle time: min=120ns recommended=120ns

        PIO: pio0 pio1 pio2 pio3 pio4

             Cycle time: no flow control=120ns  IORDY flow control=120ns

Commands/features:

        Enabled Supported:

           *    NOP cmd

           *    READ BUFFER cmd

           *    WRITE BUFFER cmd

           *    Host Protected Area feature set

           *    Look-ahead

           *    Write cache

           *    Power Management feature set

           *    SMART feature set

           *    Device Configuration Overlay feature set

           *    Automatic Acoustic Management feature set

                SET MAX security extension

                Advanced Power Management feature set

           *    DOWNLOAD MICROCODE cmd

           *    SMART self-test

           *    SMART error logging

HW reset results:

        CBLID- above Vih

        Device num = 0 determined by the jumper

Checksum: correct

root:/usr/src/linux# hdparm -tT /dev/hdg

/dev/hdg:

 Timing buffer-cache reads:   1376 MB in  2.00 seconds = 688.10 MB/sec

 Timing buffered disk reads:  104 MB in  3.01 seconds =  34.58 MB/sec

```

Bei der 2ten Platte ist es genau das selbe. Auch beim Kopieren.

----------

## PuckPoltergeist

Passiert das (100% CPU) bei jeder Konstellation? Was ist, wenn du Dateien nur auf einer Platte kopierst, oder bei den Platten am Board?

----------

## borlander

 :Embarassed: 

Sorry

OHHH ich habe gemerkt, dass es von jeder zu jeder Platte das Selbe ist.

Auch von Partition zu Partition.

Dann liegt es garantiert nicht am Raid Controller. 

Aber was ist es dann.

----------

## PuckPoltergeist

Überall das selbe Dateisystem?

----------

## borlander

Ich hab nur resierfs

überall 

Bis auf die boot partition. Aber die ist zu klein zum testen.

----------

## PuckPoltergeist

Kannst du irgendwo eine Partition mit einem anderen Dateisystem erstellen? Notfalls sicherst du die Daten einer Partition woanders hin und killst die Partition, bzw. erstellst darauf das neue Dateisystem. XFS wäre ein guter Kandidat, weil es die geringste CPU-Last erzeugt.

----------

## borlander

Ich habs mal getestet. 

Von einer XFS zu einer XFS Partition ist es auch genau das Selbe

----------

## PuckPoltergeist

Was heißt bei dir "große Dateien"?

----------

## borlander

ab 300 MB

800 MB werden noch ganz gut kopiert.

Wir aber mehr als 700 MB kopiert (können auch mehrere kleinere Dateien sein) wird der Kopiervorgang ab 700 MB sehr langsam.

Dabei ist mir aufgefallen, dass ich 700 MB RAM in der Kiste habe. ca. 500 MB werden im augenblick nicht benutzt. Das heißt Linux benutzt sie als Dateicache. Warscheinlich cacht Linux die Dateien und deswegen geht es erstmal ziehmlich schnell.

Aber warum ich 100% CPU Auslastung habe ...

----------

## Neo_0815

 *PuckPoltergeist wrote:*   

> Kannst du irgendwo eine Partition mit einem anderen Dateisystem erstellen? Notfalls sicherst du die Daten einer Partition woanders hin und killst die Partition, bzw. erstellst darauf das neue Dateisystem. XFS wäre ein guter Kandidat, weil es die geringste CPU-Last erzeugt.

 

Darf ich deine Quelle fuer die Aussage mal sehen ... das XFS die wenigste Last erzeugt, als Journaling System, sehr interessant, wo hast du das her?

Back2Topic:

Tritt das auch auf, wenn du die Platten am OnBoard Controller hast? Wenn nein würde ich sagen liegts am Controller/Treiber - was es dann aber genau ist, tjoah gute Frage  :Wink: .

MfG

----------

## PuckPoltergeist

 *Neo_0815 wrote:*   

> Darf ich deine Quelle fuer die Aussage mal sehen ... das XFS die wenigste Last erzeugt, als Journaling System, sehr interessant, wo hast du das her?

 

War in einer Ausgabe des Linux Magazin. Die genaue Nummer muß ich erst suchen. Dort wurden mehrere Dateisysteme verglichen. Wenn ich mich richtig erinnere waren das ext2, ext3, ReiserFS, JFS und XFS.

----------

## borlander

Um den Post noch ein letztes mal nach oben zu bringen.

Ich hatte erst gedacht es ligt an meinem IDE Controller. Aber ich habe von jeder Platte zu jeder Platte, oder von Partition zu Partition auf einer Platte (ob onBoard oder PCI IDE) immer sofort 100% CPU Auslastung egal ob ich mit cp  oder Konqueror kopiere. Ich habe alle Platten auf UDMA5.

Ich habe die aktuelle Kernel installiert 2.6.8r3 und ein emerge system durchgeführt.

Es muss also ein fehlerhaftes Packet im System sein oder die Kernel kommt mit meinen onBoard und PCI Controller nicht zurecht, was ich nicht glaube.

Welche Packete könnten sowas denn verursachen?

----------

