Platten Aerger

[Maik Holtkamp]

Hi,

0n 04/03/02 at 18:45 Florian Lohoff told me:

> On Tue, Mar 02, 2004 at 01:48:18AM +0100, Maik Holtkamp wrote:
> > 
> > irgendwie scheine ich mit Platten wohl derzeit auf dem Kriegsfuss zu
> > stehen :(.
> > 
> > Erst raucht die Platte im Family Server ab, dann diese Seagate, von
> > der fdisk behauptet sie waere groesser als sie tatsaechlich ist,
> > und jetzt grad eben das auf meiner Standardplatte:
> > 
> > ---cut---
> > Mar  2 00:39:56 syl kernel: end_request: I/O error, dev 21:06 (hde), sector 8704
> > Mar  2 00:39:56 syl kernel: XFS: device lvm(58,0)- XFS write error in file system meta-data block 0x0 in lvm(58,0)
> > ...
> > maik at syl maik(0) $ grep "end_request" /var/log/messages | wc -l
> > 1968
> > maik at syl maik(0) $ grep "XFS\ write\ error" /var/log/messages | wc -l
> > 26
> > ---cut---
> > 
> 
> Also - Es gibt keine IDE fehlermeldung die besagt das es einen
> oberflaechendefekt gibt - Du bekommst eine fehlermeldung aus dem Block
> Layer das eine sector nicht lesbar ist.
> 
> Ich vermute das das nicht die platte sondern irgendwas anderes ist es
> sei denn du hast da nicht alles gepasted.

Was die Geschichte rund um 00:39 anging gibt es nix weiter im log.

Aber leider kommt ein Übel ja selten allein:

---cut---
Mar  2 02:11:03 syl kernel: hde: dma timeout retry: status=0xd0 {Busy }
Mar  2 02:11:03 syl kernel: 
Mar  2 02:11:03 syl kernel: hde: DMA disabled
Mar  2 02:11:03 syl kernel: PDC202XX: Primary channel reset.
Mar  2 02:11:03 syl kernel: PDC202XX: Secondary channel reset.
Mar  2 02:11:03 syl kernel: hde: set_drive_speed_status: status=0xd0 { Busy }
....
Mar  2 02:11:23 syl kernel: hde: set_geometry_intr: error=0x04 { DriveStatusError }
Mar  2 02:11:23 syl kernel: hde: status error: status=0x01 { Error }
Mar  2 02:11:23 syl kernel: hde: status error: error=0x04 { DriveStatusError }
Mar  2 02:11:23 syl kernel: hde: status error: status=0x01 { Error }
Mar  2 02:11:23 syl kernel: hde: status error: error=0x04 { DriveStatusError }
Mar  2 02:11:23 syl kernel: hde: status error: status=0x01 { Error }
Mar  2 02:11:23 syl kernel: hde: status error: error=0x04 { DriveStatusError }
Mar  2 02:11:23 syl kernel: PDC202XX: Primary channel reset.
Mar  2 02:11:23 syl kernel: PDC202XX: Secondary channel reset.
Mar  2 02:11:23 syl kernel: hde: set_drive_speed_status: status=0x01 { Error }
Mar  2 02:11:23 syl kernel: hde: set_drive_speed_status: error=0x04 { DriveStatusError }
Mar  2 02:11:23 syl kernel: ide2: reset: master: ECC circuitry error
Mar  2 02:11:23 syl kernel: end_request: I/O error, dev 21:06 (hde), sector 111179352
....
---cut---

dannn ging es wieder in der gleichen Regelmaessigkeit weiter. Die
gleichen Symtome wie vorher. Der syslog auf meinem Arbeitsplatz
loggt auch die Meldungen meines routers/servers, damit mir dank
root-tail nie langweilig wird ;). 

Kann es sein, dass er zuviel mit dem logging der remote Meldungen zu
tun hatte und daher um 00:39 die o.g. Meldungen "geschluckt" hat?

Ich habe die 00:39er Umgebung abgesucht dort gab es sowas nicht.

In der .config des 2.4.24 sieht das so aus:

---cut---
root at syl linux(0) # grep PDC .config
CONFIG_BLK_DEV_PDC202XX_OLD=y
CONFIG_PDC202XX_BURST=y
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
CONFIG_PDC202XX_FORCE=y
CONFIG_BLK_DEV_PDC202XX=y
# CONFIG_BLK_DEV_ATARAID_PDC is not set
---cut---

Beim 2.4.23, bei dem ich solche Probleme nie hatte, wurde noch der
Raid Treiber als Modul gebacken, aber nachdem ich zwischenzeitlich
mal Erfahrung mit Software Raid unter Linux machte und der Treiber
AFAIK nichts anderes macht, habe ich es bei 2.4.24 ganz draussen
gelassen.

Das einzige was ich gestern noch ergoogeln konnte und ein wenig
erfolgversprechend klang, war fuer meinen lilo ein Versuch mit:

append = "pci=biosirq noapic"

Damit spielt er jetzt seit einer guten Stunde. Vorher, bei < 2.4.24
habe ich das aber nie gebraucht, obwohl beim Überspielen von DV
Daten dort bestimmt etwas Dampf drauf kam ... mal abwarten. Die
wichtigen Daten schaffe ich schon mal aus dem Weg.

Bernhard: Bei einem smartctl -i /dev/hde bekomme ich die Meldung das
          die Platte SMART unterstuetzt und es eigeschaltet waere und 
          dann ein reprozierbares Einfrieren der Kiste, bei ein paar
          netten @@@ Zeilen im log :(.
          Ich vermute eh' ganz schwer es liegt am Promise,
          vielleicht auch daran das das README nicht explizit hd_e_ 
          erwaehnt.

Auf jeden Fall erstmal danke.

-- 
bye maik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lug-owl.de/pipermail/linux/attachments/20040302/ca1967ea/attachment.sig>