Re: AHCI

Am Donnerstag, den 08.12.2011, 15:25 +0100 schrieb Oliver Fromme:
> Marc Santhoff wrote:
> > da ich durch Zufall weiß, daß wir sehr ähnliche Hardware verwenden, mal
> > eine Zusatzfrage, die sich beim Update von FreeBSD ergeben hat:
> >
> > Das lezte Systemupdate lag ja schon zurück, und zwar bis vor dem Umstieg
> > auf ahci. War auch schön problemlos zu machen, meine Platten sind
> > ge'label't und wurden ohne Gefummel an fstab sofort richtig
> > eingehängt. :)
> >
> > Aber dann:
> > Es dauert zwischen 0 und 30 Minuten (ersteres gleich beim Booten,
> > letzteres geschätzt) bis die Systemplatte, eine SSD, sich "abmeldet", in
> > der Form daß der Treiber "device lost" meldet und dann panic'ed.
> >
> > Ein in den Listen gefundener Tip, das Powermanagement auf den Platten
> > einzuschalten, damit der Treiber mit dem Abmelden der Platte rechnet,
> > half nur bedingt, sie kann nicht wieder aktiviert werden.
> >
> > Also zurück zu ata_disk und /dev/adX und alles läuft. Mich stört es
> > erstmal nicht, aber die Datenverluste waren spürbar, kann immer noch
> > sein, daß ich ab dem Backup vor dem Update neu ansetzen muß ... vorher
> > vielleicht noch nach neuem BIOS gucken.
> >
> > Hattest Du solche Schwierigkeiten auch?
>
> Davon höre ich zum ersten Mal. Sowas ist bei mir noch nie
> passiert. Ich habe auch kein Powermanagement eingeschaltet
> (jedenfalls nicht bewusst).
>
> Eigentlich klingt Deine Beschreibung nach eine Kabelwackler
> oder einem schwächelnden Netzteil, aber da es offenbar nur
> im AHCI-Modus auftritt und sonst nicht, tendiere ich eher
> zu einem (Firmware-)Bug, entweder im SATA-Adapter oder in
> der SSD.

Ans Kabel dachte ich auch schnell, aber dann würde ATA das gleiche
machen. Is aber nich.

Die SSD funktioniert ja auch eigentlich ...

> Du könntest mal testweise mit den Loader-Tunables spielen,
> die in der ahci(4)-Manpage beschrieben sind, z.B. MSI aus-
> schalten, oder die SATA-Geschwindigkeit drosseln (aber an
> letzterem liegt es vermutlich nicht). Wenn man es nicht
> weiter eingrenzen kann, könnte man noch versuchen, ob das
> Problem auch mit einem anderen SATA-Adapter bzw. Board
> auftritt, sofern man eins zur Verfügung hat.

Ich überlege noch, der Rechner soll laufen. Wenn aber die Gefahr von
Problemen eingebaut ist, lohnt sich Testen wohl doch. Ich könnte die
Platte mal umstöpseln, FreeBSD zumindest sollte das wegstecken.

Am meisten foppt mich, daß es wirklich echte Datenverluste gibt, d.h. im
Extrem nach jedem auftretenden Fehler das Backup einspielen.

Mal gucken, wenn ich mehr Zeit habe, damit rumzuspielen, mache ich wohl
noch ein paar Versuche. Zumindest das Mainboard hatte ein BIOS-Update
nötig und hat's bekommen.

> Ich nehme an, die Ausgabe von "smartctl -a /dev/ada0" hast
> Du schon auf Verdächtiges untersucht, nicht wahr?

Selbstverständlich ... jetzt zumindest. Auffällig sind die "unexpected
power loss"-Ereignisse, allerding "old_age", was auch immer das genau
heißt:

=== START OF INFORMATION SECTION ===
Model Family: SandForce Driven SSDs
Device Model: OCZ-AGILITY2 3.5
Serial Number: OCZ-6CT65J5XA30Z4A43
LU WWN Device Id: 5 e83a97 f18137531
Firmware Version: 1.25
[...]
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate 0x000f 120 120 050 Pre-fail Always - 0/0
  5 Retired_Block_Count 0x0033 100 100 003 Pre-fail Always - 0
  9 Power_On_Hours_and_Msec 0x0032 100 100 000 Old_age Always - 145h+24m+34.940s
 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 50
171 Program_Fail_Count 0x0032 000 000 000 Old_age Always - 0
172 Erase_Fail_Count 0x0032 000 000 000 Old_age Always - 0
174 Unexpect_Power_Loss_Ct 0x0030 000 000 000 Old_age Offline - 27
177 Wear_Range_Delta 0x0000 000 000 000 Old_age Offline - 0
181 Program_Fail_Count 0x0032 000 000 000 Old_age Always - 0
182 Erase_Fail_Count 0x0032 000 000 000 Old_age Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
194 Temperature_Celsius 0x0022 001 129 000 Old_age Always - 1 (0 127 0 129 0)
195 ECC_Uncorr_Error_Count 0x001c 120 120 000 Old_age Offline - 0/0
196 Reallocated_Event_Count 0x0033 100 100 000 Pre-fail Always - 0
231 SSD_Life_Left 0x0013 100 100 010 Pre-fail Always - 0
233 SandForce_Internal 0x0000 000 000 000 Old_age Offline - 64
234 SandForce_Internal 0x0032 000 000 000 Old_age Always - 128
241 Lifetime_Writes_GiB 0x0032 000 000 000 Old_age Always - 128
242 Lifetime_Reads_GiB 0x0032 000 000 000 Old_age Always - 192

Ich schließe daraus erstmal, daß der Platte der Saft weggeschaltet wird,
es also wohl nicht auf der Seite liegt.

> > FreeBSD 9.0-CURRENT #0: Thu Jul 7 19:31:29 CEST 2011
> >
> > jetzt RELENG_9 von vorgestern.
>
> Ich verwende hier stable/8, aber das sollte nicht ursächlich
> für das Problem sein.

Würde ich so nicht behaupten wollen, kann auch an V9 liegen. Um es
auszuschließen müßte ich dann nochmal 8-STABLE drauftun.

> > ad10: 114473MB <OCZ-AGILITY2 3.5 1.25> at ata5-master UDMA100 SATA 3Gb/s
>
> Ich habe insgesamt drei OCZ in Betrieb (zweimal 120 GB und
> einmal 60 GB), allerdings sind es alles Vertex-2E mit
> Sandforce-Controller. Mit der Agility-Reihe habe ich noch
> keine Erfahrungen gesammelt.
>
> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
> ada0: <OCZ-VERTEX2 1.23> ATA-8 SATA 2.x device
> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
> ada0: Command Queueing enabled
> ada0: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C)
>
> > ad12: 953869MB <Hitachi HDS721010CLA332 JP4OA3EA> at ata6-master UDMA100
> > SATA 3Gb/s
>
> Das ist ein Zwilling von meiner. :-)

Schätze wir kaufen beim gleichen Laden, oder so ... =:)

> ada1 at ahcich1 bus 0 scbus1 target 0 lun 0
> ada1: <Hitachi HDS721010CLA332 JP4OA3EA> ATA-8 SATA 2.x device
> ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
> ada1: Command Queueing enabled
> ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C)
>
> Gruß
> Olli
>

-- 
Marc Santhoff <M.Santhoff(at)web.de>
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message