Hallo Thomas Thomas Hertweck wrote:
Ja, solche Blaetter sagen immer viel... :-)
Na ja, hängt dann immer davon ab ob bei der Implementierung der entsprechende Standard _wirklich_ eingehalten wird. ;-)
Es sieht so aus, als kaeme das System nicht mit dem UDMA-Mode, den Du gewaehlt hast, zurecht.
Soweit ich in den "Kernel-Entwickler-Listen" nachgeforscht habe, hat es wohl irgend etwas mit "response" Zeiten zu tun.
Wenn die Kernel-Entwickler das sagen, wird es sicher stimmen. Das Problem ist aber manchmal nicht die Platte selbst, man muss immer alle beteiligten Komponenten im Blick haben.
Das war der Hintergrund für meine Frage. Soweit ich es verstanden habe wird beim aktivieren des DMA-Modus die Platte abgefragt, was sie "wirklich kann". Soweit ich es verstanden habe, antwortet wohl nicht jede Platte so wie gewünscht. Scheint wohl auch etwas zeitkritisch zu sein, bzw. die Antwort kommt in einer (vom Kernel) nicht erwartetet Form. BTW: Hardware ist in Ordnung, Fehler auf dem Filesystem (ext3) sind bisher nicht aufgetreten.
"Allein, mir fehlt das tiefere Verständnis" ;-)
Da musst Du dann in den Kernel-Source schauen, was genau diese Fehlermeldung ausloest.
<schmunzel> Also wieder extremer Kaffeemißbrauch und versuchen (als "Nichtprogrammierer") aus den Sourcen schlau zu werden. Ich stimme Dir allerdings zu, die "Wahrheit" liegt wie immer in den Quellen..... </schmunzel>
Was sagen denn $> hdparm -i /dev/hda bzw. ein $> hdparm /dev/hda und ein $> hdparm -tT /dev/hda auf Deinem System?
Danke für den Hinweis, hdparm ist bekannt und wird auf anderen Rechnern verwendet um die Platten "zu Konfigurieren". Es ging mir eher darum mal zu testen was denn die YaST-speziefischen Lösungen so erzeugen.
CU, Th.
Beste Grüße Gerald -- Gerald Engl AED-SICAD Aktiengesellschaft Lilienthalstrasse 7 / 85579 Neubiberg Tel.: +49 89 45026-110