ForumPromise Controller und die wunderbare Scheibenwelt — schnell/langsam
Ottfried Meyer – Samstag, 22. Oktober 2005 12:15 Uhr

Hallo,

Ein etwas merkwürdiges Verhalten macht mich stutzig:
Ich habe zwei absolut baugleiche Festplatten :
WDC WD800BB (80GB, Winchester Digital).

Die eine ist am IDE0 als Master angeschlossen.
Die zweite hängt an IDE3 als Master an einem Promise-Controller.
(Mass storage controller: Promise Technology, Inc. PDC20268 (Ultra100 TX2)
(rev 02) — laut lspci)).

Diese zweite Platte benutze ich als “Ablage” für mein System, wenn ich
mal wieder etwas Größeres “verdrehen” will.

Wenn ich KNOPPIX boote oder auch den Kernel meines LFS-Systems, wird
die erste Platte entsprechend ihrer Fähigkeiten mit DMA/UDMA5 versorgt.

Ausgabe von hdparm -i
solfire:/home/mccramer>sudo hdparm -i /dev/hda

/dev/hda:

Model=WDC WD800BB-00CAA1, FwRev=17.07W17, SerialNo=WD-WCA8E6540871
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156301488
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=no WriteCache=enabled
Drive conforms to: device does not report version:

* signifies the current active mode

Desweiteren finde ich unter /proc/ide/ide0/hda/settings:

name value min max mode
—- —– — — —-
acoustic 0 0 254 rw
address 0 0 2 rw
bios_cyl 65535 0 65535 rw
bios_head 16 0 255 rw
bios_sect 63 0 63 rw
bswap 0 0 1 r
current_speed 69 0 70 rw
failures 0 0 65535 rw
init_speed 12 0 70 rw
io_32bit 1 0 3 rw
keepsettings 0 0 1 rw
lun 0 0 7 rw
max_failures 1 0 65535 rw
multcount 0 0 16 rw
nice1 1 0 1 rw
nowerr 0 0 1 rw
number 0 0 3 rw
pio_mode write-only 0 255 w
unmaskirq 1 0 1 rw
using_dma 1 0 1 rw
wcache 1 0 1 rw

So weit so schön.

Seltsamerweise ist für die zweite, absolut identische Platte kein
“tuning” aktiv. UDMA5 ist nicht aktiviert (wohl aber DMA) und
ich muss mit hdparm immer -c 1 -u 1 setzen, damit es zumindest etwas
an die EInstellungen von hda herankommt.

Meinen Kernel habe ich so konfiguriert und gebacken, dass der Promise-
Controller (auch der eingebaute Typ) unterstützt wird.

An Optionen wie -X und -p von hdparm wage ich mich nicht ohne weitere
Informationen heran.

Weiss jemand, was da falsch läuft? Warum wird diese zweite Platte so
behandelt, als käme sie aus der Computer-Steinzeit ???

Vielen Dank schonmal für jede Form von Hilfe im Voraus!
Schönes Wochenende!
Meino

2 Antworten
Jan Kandziora – Samstag, 22. Oktober 2005 12:40 Uhr

Seltsamerweise ist für die zweite, absolut identische Platte kein “tuning” aktiv. UDMA5 ist nicht aktiviert (wohl aber DMA) und ich muss mit hdparm immer -c 1 -u 1 setzen, damit es zumindest etwas an die EInstellungen von hda herankommt.

Dein Promise-Controller vermutlich einer der Controller, die beim Ausprobieren der falschen UDMA-Einstellungen auch gerne mal komplett bis zum nächsten Strom-aus den Dienst versagen. Daher musst du das von Hand machen, z.B. über hdparm -d1 -X67 etc. Dann per dmesg beobachten, ob es Fehlermeldungen gibt. Ob das Einschalten des UDMA-Modus geklappt hat, kannst du kurz mit hdparm -tT /dev/hd.. nachprüfen.

Jan

Ottfried Meyer – Samstag, 22. Oktober 2005 14:23 Uhr

Hi,
Danke für Deine Antwort.

Wie ich schon andeutete:

> …UDMA5 ist nicht aktiviert (wohl aber DMA)…

damit erübrigt sich hdparm -d 1

Aus der manpage zu hdparm:
On drives which support alternate transfer
modes, -X can be used to switch the mode of the drive only.
Prior to changing the transfer mode, the IDE interface should be
jumpered or programmed (see -p flag) for the new mode setting to
prevent loss and/or corruption of data. Use this with extreme
caution!

oder mit anderen Worten: Setzte ich mit -X (übrigens für udma5 ist es 69)
den _PLATTEN_ udma-Mode ohne vorher mit -p den Controller auszutricksen,
schieße ich mir mit aller wahrscheinlich zumindest meine Daten zum Mond.
Schlecht für eine System-Backup Disk (siehe meine Mail).

Nur leider schweigt sich die Manpage zu hdparm aus, /wie/ man mit -p den
Controller manipuliert — wahrscheinlich aus reiner Vorsicht.

Was mir fehlt ist a) ein Tipp /wieso/ es zu den Problemen kommt und
b) wie man sie umschifft. Und zwar nicht durch probieren (Daten futsch oder nicht), sondern durch einen gezielten Eingriff ins System.

Any ideas ?

Keep hacking!
Meino

Jan Kandziora – Samstag, 22. Oktober 2005 22:22 Uhr

Aus der manpage zu hdparm: On drives which support alternate transfer modes, -X can be used to switch the mode of the drive only. Prior to changing the transfer mode, the IDE interface should be jumpered or programmed (see -p flag) for the new mode setting to prevent loss and/or corruption of data. Use this with extreme caution! oder mit anderen Worten: Setzte ich mit -X (übrigens für udma5 ist es 69) den _PLATTEN_ udma-Mode ohne vorher mit -p den Controller auszutricksen, schieße ich mir mit aller wahrscheinlich zumindest meine Daten zum Mond. Schlecht für eine System-Backup Disk (siehe meine Mail).

Falsch. -p hat nur etwas mit den PIO-Modes zu tun, die man ja auch über -X einstellen kann. Wenn man den DMA-Modus benutzt, ist -p ohne Bedeutung. Ich habe übrigens früher immer den UDMA-Modus mittels hdparm -X einstellen müssen, das die Distributionen dazu immer zu dämlich waren. Daten gehen nur verloren, falls UDMA wieder erwarten (Platte-Controller-Unverträglichkeit oder Grund #1: Kabel==Mist) nicht richtig funktioniert. Wenn du es ausprobieren willst, ohne dein Dateisystem zu beschädigen, solltest du dieses einfach readonly mounten und dann mal was von der entsprechenden Platte kopieren, was ja bei einer Backupplatte auch ziemlich einfach geht.

Jan

reuter_joe – Samstag, 22. Oktober 2005 16:51 Uhr

Hallo

also als erstes würde ich probieren die pesteplatten zu tauschen. das heisst die mir dem IDEO anschluss schliess die an den IDE3. Es kann sein dass sich im system einige dateien verändert haben.