Re: Festplatten-Zugriffsfehler

[Stephan Gromer <stephan.gromer@xxxxxx>]

Hallo Werner,

Zu
> Dec 18 01:37:27 linux kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> Dec 18 01:37:27 linux kernel: hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
>   
Siehe Thread auf http://lists.suse.com/archive/suse-linux/2003-Sep/2868.html
Ich zitiere:

"Das bedeutet "nur", dass die CRC-checks Fehler liefern. Das Feature 
dieser CRC-checks auf dem IDE-Bus gibt es (erst) seit UDMA 66 mit den 
Kabeln mit 80-Adern. Falls also diese Meldungen auftreten, gilt es, 
zuerst mal die Kabel und die Steckverbindungen zu ueberpruefen. 
Ausserdem kann das durch ein zu langes (Spezifiziert als maximale 
Kabellaenge sind 45cm) oder schlechtes Kabel verursacht werden.  Falls 
das Kabel und die Verbindungen ok sind (teste am besten mal mit einem 
anderen Kabel), dann schalte erstmal auf UDMA66 zurueck. Apropos: was 
sagt ein 'hdparm -i /dev/hdd'?

"Jedenfalls: Fuer pATA ist dein Kabel dann definitiv zu lang, bei 
langsameren Modi als UDMA33 _kann_ das u.U. auch noch mit laengeren 
Kabeln funktionieren, ich hab hier auch ein Kabel mit 50cm oder so, aber 
mit Modi >= UDMA66 aber funktioniert das dann definitiv nicht mehr 
sicher. Apropos: du hast schon 80-adrige Kabel,oder?"

"Wobei die CRC-Errors ja sowieso nix ueber die HDD selbst  aussagen, 
sondern ueber den Transportweg Platte -> IDE-Controller... Denn die 
CRC-Summe, gegen die der Transfer geprueft wird, errechnet ja  die HDD, 
und nicht der Controller.
Die Platte bekommt vom Controller den Auftrag, $Datensektoren zu 
liefern. Die Elektronik macht also daran, die Daten von der Platte zu 
fischen, packt die Daten dann in Paeckchen, errechnet ne CRC zu jedem 
Paeckchen, schickt beides ueber die Leitung zum Controller, der 
errechnet dann wieder die CRC und vergleicht das Ergebnis mit der CRC, 
die er von der Plattenelektronik bekommen hat -- und falls beide CRC 
unterschiedlich sind, dann gibt's eben o.g. "BadCRC" Fehler... Der Grund 
ist dann entweder, dass die Daten unterwegs gelitten haben -- oder auch 
die CRC selbst... Und das liegt dann logischerweise nicht an defekten 
Sektoren, sondern z.B. an zu langen oder zu schlechten Kabeln.
In der Gegenrichtung wird's analog gemacht...

Mit der CRC wird der _Transportweg_ zwischen IDE-Controller und der 
Elektronik auf der HDD abgesichert, da es bei UDMA Modi (auch bei 
UDMA33, nur da gibt's das mit den CRCs noch net) auf den Kabeln bzw. den 
Steckverbindungen recht haeufig zu Fehlern kommt. AFAIR wird dann bei so 
einem CRC-Mismatch dann das Datenpaket erneut angefordert... "

Vielleicht hilft das etwas beim Verstaendnis,

LG
Stephan



-- 
Stephan Gromer, MD. PhD.
Work: Biochemie-Zentrum Heidelberg / Im Neuenheimer Feld 504 / D-69120
      Heidelberg / Tel.: +49 (6221) 544291 / Fax.: +49 (6221) 545586
Home: Sternallee 89 / D-68723 Schwetzingen / Tel.: +49 (6202) 855038
      Mobil: +49 (172) 7694555 / URL: http://www.gromer-online.de

-- 
http://mailman.uugrn.org/mailman/listinfo/uugrn