energiesparendes AM2+ oder AM3 Mainboard

Jein, also ein Ubuntu vom USB-Stick macht keine Probleme. Es kann auch problemlos ut2004 von der besagten Platte laden. Von den Disks selber habe och noch nichts anderes booten können.
Versuch mal was auf auf die Platte zu schreiben, nur Lesen (UT2004) ist wohl nur die Hälfte....
wenn ich die Platten per USB an den Laptop packe kriege ich keine Probleme…
Ich vermute ja oben, dass du die Platten selbst ausschliessen kannst. Aber Kabel, IDE-Controller oder RAM könnten ja auch defekt sein...

Ausserdem ist USB vermutlich zu langsam, so dass zeitkritische Fehler damit evtl. gar nicht auftreten...
Das geht aber nur für SATA, nicht für IDE im BIOS. Für IDE kann ich garnichts einstellen…
Habe übersehen, dass du immer noch mit den alten Platten unterwegs bist. :o
Ich gehe davon aus, dass LBA eingeschaltet ist. Windows 95 und ME werden nämlich explizit nicht untersützt und diesen fehlt genau die Möglichkeit Festplatten via LBA anzusprechen. (Ist aber nur eine Vermutung von meiner Seite).

mousaka
 
Versuch mal was auf auf die Platte zu schreiben, nur Lesen (UT2004) ist wohl nur die Hälfte....
Ich werde jetzt mal ein Debian draufbügeln und gucken.
Ich vermute ja oben, dass du die Platten selbst ausschliessen kannst. Aber Kabel, IDE-Controller oder RAM könnten ja auch defekt sein...
Kabel und IDE-Controll kann ich doch ausschließen, weil die Probleme auch per USB auftreten, oder nicht? RAM wäre noch ne Möglichkeit, ich mach mit dem debian image gleich mal einen test.
 
So, das Debian läuft so weit. Bis jetzt keine Probleme, wobei es mit dem FreeBSD gestern ja auch keine gab :/
 
Obscurity part x

Also, das Debian hat jetzt innerhalb zweier Tage bei starker Fesplatteload auch zweimal gepanicked…

Ich habe daraufhin mit der UBCD eine intensiven RAM-Check gemacht (sehr viel Durchgänge) und mit einem SAMSUNG-tool einen Festplatten check inklusive vollständigem Surface-Scan (fast 3 Stunden). Heraus kam, dass die ganze Hardware fehlerfrei ist.

Was nun?

Ich habe die Platte mal an ein anderes Mainboard gehangen und probiere damit rum, aber das eigentliche Board ist sehr wichtig, es soll schließlich das neue Server-Board werden (und zuverlässig laufen!).

Was schlagt ihr vor? Direkt reklamieren auf Grund von Fehler im Controller? Hätte der dann nicht auch mit dem Tool auftauchen müssen?

Oder glaubt ihr das ist ein Softwarefehler, der sowohl unter Linux als auch FreeBSD auftritt? Und wenn ja, wieso? Die gnazen Chipsatzkomponenten sind doch Standard…

Bin leicht verzweifelt, danke für Hilfe.
 
Der Controller wird nicht schuld sein. Das Ganze klingt sehr nach verlorenen Interrupts. Aber was dagegen machen? Wenn der Controller nicht gerade sich mit was anderem den Interrupt teilt, würde ich noch mal nach einem BIOS-Update schauen und wenn das nichts wird einfach eine RMA machen. Mit dem Board wirst du nicht mehr glücklich werden. Zumindest nicht vom pragmatischen Standpunkt aus gesehen.
 
Also wenn der Plattentreiber klar "bad block" sagt, würde ich smartmontools installieren und mir das mal anschauen, ob die Platte den Abgang macht.

Wenn es Probleme gibt, dann ist dieser Wert meistens nicht "0":

Code:
197 Current_Pending_Sector  0x0032   252   100   000    Old_age   Always       -       0

Dieser Wert zeigt reparierte Schaden (weist aber meistens auf kommende Probleme hin):

Code:
5 Reallocated_Sector_Ct   0x0033   252   252   010    Pre-fail  Always       -       0


Im Grunde... alle "Pre-fail"-Attribute müssen größer als "THRESH"-Wert immer gewesen sein (also WORST-Wert).

Den Current-Pending-Sector-Count Wert kriegt man übrigens wieder auf "0", wenn man die Stelle mehrmals überschreibt. Tut man das nicht, gibt es so lange Lesefehler. Aber zuerst immer Backups machen, bevor man sein FS komplett frittiert.
 
Der Controller wird nicht schuld sein. Das Ganze klingt sehr nach verlorenen Interrupts. Aber was dagegen machen? Wenn der Controller nicht gerade sich mit was anderem den Interrupt teilt, würde ich noch mal nach einem BIOS-Update schauen und wenn das nichts wird einfach eine RMA machen. Mit dem Board wirst du nicht mehr glücklich werden. Zumindest nicht vom pragmatischen Standpunkt aus gesehen.
Ich kläre mal mit dem Versandhändler ob ich BIOS-Update machen kann, sonst gehts zurück.

Also wenn der Plattentreiber klar "bad block" sagt, würde ich smartmontools installieren und mir das mal anschauen, ob die Platte den Abgang macht.

Wenn es Probleme gibt, dann ist dieser Wert meistens nicht "0":

Code:
197 Current_Pending_Sector  0x0032   252   100   000    Old_age   Always       -       0

Dieser Wert zeigt reparierte Schaden (weist aber meistens auf kommende Probleme hin):

Code:
5 Reallocated_Sector_Ct   0x0033   252   252   010    Pre-fail  Always       -       0


Im Grunde... alle "Pre-fail"-Attribute müssen größer als "THRESH"-Wert immer gewesen sein (also WORST-Wert).
Den Satz check ich nicht so ganz :rolleyes:
Den Current-Pending-Sector-Count Wert kriegt man übrigens wieder auf "0", wenn man die Stelle mehrmals überschreibt. Tut man das nicht, gibt es so lange Lesefehler. Aber zuerst immer Backups machen, bevor man sein FS komplett frittiert.

Steckt jetzt in einem anderen Rechner drin, da sagt es:
Code:
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0007   065   001   000    Pre-fail  Always       -       5952
  4 Start_Stop_Count        0x0032   099   099   000    Old_age   Always       -       1460
  5 Reallocated_Sector_Ct   0x0033   097   097   010    Pre-fail  Always       -       8
  7 Seek_Error_Rate         0x000b   253   253   051    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0024   253   253   000    Old_age   Offline      -       0
  9 Power_On_Half_Minutes   0x0032   100   100   000    Old_age   Always       -       4008h+13m
 10 Spin_Retry_Count        0x0013   253   253   049    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       1135
194 Temperature_Celsius     0x0022   115   088   000    Old_age   Always       -       41
195 Hardware_ECC_Recovered  0x000a   100   100   000    Old_age   Always       -       68055594
196 Reallocated_Event_Count 0x0012   100   100   000    Old_age   Always       -       2
197 Current_Pending_Sector  0x0033   253   253   010    Pre-fail  Always       -       0
198 Offline_Uncorrectable   0x0031   253   253   010    Pre-fail  Offline      -       0
199 UDMA_CRC_Error_Count    0x000b   100   100   051    Pre-fail  Always       -       16
200 Multi_Zone_Error_Rate   0x000b   100   100   051    Pre-fail  Always       -       0
201 Soft_Read_Error_Rate    0x000b   100   100   051    Pre-fail  Always       -       0

Ist soweit in Ordnung, oder?

Oh man, Festplatten sind anstrengend…
 
Also, Deine smart-Logs zeigen, dass mindestens 2x Sektoren umkopiert worden sind, weil sie defekt waren. Es kann natürlich sein, dass dies genau die Sektoren sind, die zum Absturz geführt haben.

Du musst das auch so sehen, dass jedes System Festplatten anders mit Sektoren belegt. FreeBSD streut die Daten ziemlich gut über die Platte und man findet oft Fehler, die weit hinten liegen auch sehr leicht.

Du solltest die Platte mal mit "dd if=/dev/hddevice of=/dev/null bs=1m" mal komplett auslesen und schauen, ob Fehler passieren (bei angeschaltetem S.M.A.R.T. natürlich). Dann kannst Du anschließend im Log sehen, ob sich Fehler akkumulieren bei "Pending".

Auch meine relativ neue Platte hatte einen Lesefehler. Das ist heutzutage nichts ungewöhnliches. Beim mehrmaligen Überschreiben der betreffenden Stelle hat sich die Platte wieder eingekriegt. Das meiste ist hier ist halt Consumer-Kram! Die Hersteller kalkulieren das mit ein, dass man paar Daten verliert und es nicht mal merkt, weil die Benutzer so zu 99% einfach blöd sind (und es stimmt ja).
 
Hm, wenn ich jetzt öfter zurhören kriege:
g_vfs_done():ufs/DESKDATA[READ(offset=2251799619928064, length=16384)]error = 5
bad block -5916514288203263480, ino 712193
pid 19 (softdepflush), uid 0 inumber 712193 on /crypt: bad block
g_vfs_done():ufs/DESKDATA[READ(offset=2251799619928064, length=16384)]error = 5
bad block 4345365266525511267, ino 712193
pid 19 (softdepflush), uid 0 inumber 712193 on /crypt: bad block
g_vfs_done():ufs/DESKDATA[READ(offset=2251799619928064, length=16384)]error = 5
bad block 8553041303118716573, ino 712193
pid 19 (softdepflush), uid 0 inumber 712193 on /crypt: bad block
g_vfs_done():ufs/DESKDATA[READ(offset=2251799619928064, length=16384)]error = 5
bad block 9094905446467798694, ino 712193
pid 19 (softdepflush), uid 0 inumber 712193 on /crypt: bad block
g_vfs_done():ufs/DESKDATA[READ(offset=2251799619928064, length=16384)]error = 5
bad block 6643305431135024058, ino 712193
pid 19 (softdepflush), uid 0 inumber 712193 on /crypt: bad block
g_vfs_done():ufs/DESKDATA[READ(offset=2251799619928064, length=16384)]error = 5
bad block -47440663866450345, ino 712193
pid 19 (softdepflush), uid 0 inumber 712193 on /crypt: bad block
handelt es sich da jetzt immer um den selben inode, kann ich den gezielt "blacklisten"?

Übrigens habe ch diese Fehler jetzt auch auf einem anderen System. Eine andere der besagten Platte geht in einem dritten System aber problemlos. Also ists vielleicht doch ne Kombination aus kaputtem BIOS/Controller und kaputten Platten :|

Ich glaub ich muss von HDs in den Clients weg, aber dazu mach ich dann ein neues Thema auf :rolleyes:
 
Die Platte ist hinüber. Wenn moderne Platten Sektoren als schlecht nach oben durchgeben bedeutet das nichts anderes, als das alle Ersatzsektoren in dem Bereich bereits genutzt sind. Sonst würde die Platte den Sektor verlegen und du würdest den Defekt nie sehen. Wenn du sie trotzdem weiter verwenden möchtest:

1. Die Platte einmal komplett per "dd if=/dev/zero of=/dev/platte bs=8M" ausnullen. Eventuell schafft die Magie es denn doch den Block zu erkennen und auszumappen. Das könnte dich retten, da nur beim LESEN ausgemappt wird, aber nicht beim Schreiben. Wenn der Block also noch dem letzten Schreiben gestorben ist, hast du eine Chance.

2. Hilft das nicht, kannst du als letzte Option badsect(8) anwenden. Aber ist nicht zu empfehlen.
 
Nein. Yamagi. Die Platte muss man vorher an der Stelle einige Male überschreiben. S.M.A.R.T. muss merken, dass es da ein Problem gibt (beim Schreiben merkt es das nicht, man muss Lesen). Wenn man anschließend einen Schreibzugriff macht, dann kann S.M.A.R.T. das (glaube ich; also wirklich eine Vermutung, weil es oft klappt) zuordnen und einen Sektor auslagern. Solange Du keine Schreibzugriffe auf den kaputten Sektor machst, bleibt der Sektor hängen im "Current_Pending_Sector"-Status. Wenn er ausgelagert worden ist, dann notiert das S.M.A.R.T. in "Reallocated_Sector_Ct". Erst wenn Du siehst, dass der Wert dort unter "THRESH(old)" sinkt, sind alle Reservesektoren in Benutzung.

Vorgehen:
  1. S.M.A.R.T. anschalten (mit smartd)
  2. Leseprobe mit: dd if=/dev/HDD-DEVICE of=/dev/null bs=512 count=1 skip=LBA-BLOCK-NR (Vorsicht! Rechner wird schwer anhalten zeitweise und evtl eine Zeit lang nicht reagieren bis er den Hardware-Fehler ausspuckt)
  3. dd if=/dev/zero of=/dev/HDD-DEVICE bs=512 count=1 seek=LBA-BLOCK-NR (mehrmals!)
  4. Block nochmal auslesen (siehe: 2). Hier dürfen dann keine Fehler mehr stehen.
  5. S.M.A.R.T. nochmal prüfen (es darf kein Sektor mehr "Pending" auftauchen). Evtl lohnt sich die Wiederholung der Prozedur.

Achso... und oft sind Nachbarsektoren gleich mitbeschädigt. Es ist gut eine Leseprobe um den Wert herum durchzuführen.

Aber das ganze ist nur eine Vermutung wie das funktioniert. Hersteller können es anders machen und ich hab die Specs von S.M.A.R.T. auch nicht gelesen.

Noch einige Anmerkungen:

LBA-NR gilt da oben für Platten mit Sektorgröße 512.

Dann Du siehst an dem fixen Wert "2251799619928064" dass die Platte an der gleichen Stelle nicht lesbar ist (für LBA ist mir das allerdings etwas groß, wahrscheinlich ist das die Position, also durch 512 teilen!). Wäre das die Elektronik, würdest Du eher an verschiedenen Stellen, die keinen wirklichen Zusammenhang zeigen, Lesefehler haben.

Versuch einfach die Platte zu heilen. Aber wenn das ein Server ist mit wichtigen Sachen drauf, dann würde ich sie schon ersetzen, egal ob geheilt oder nicht.
 
Zuletzt bearbeitet:
In dem Fall müsste er es ja auch wieder hinbekommen, wenn er wie in Vorschlag 1 das ganze Ding einmal komplett ausnullt. Aber gut, den Block selektiv zu behandeln ist natürlich effektiver. :)
 
Das "Nein" bezog sich auf Deine Hoffnungslosigkeit und auf die Aussage, dass alle Reservesektoren bereits belegt sind. Meine Erfahrung ist, dass Platten Fehler so lange behalten, bis Du schreibend auf die Stellen zugreifst.

Die ganze Platte ausnullen kann man auch machen, klar. Dauert aber lange und an die betreffende Stelle sollte man mehrmals schreibend zugreifen.
 
irgendwie ist das hier extrem off-topic geworden.. könntet ihr bitte zum ursprungsthema zurückkommen oder einen neuen thread öffnen?
 
Jo, stimmt ist OT geworden, Ich danke auf jeden Fall erstmal für die Hilfe. In den Ferien geh ich das alles mal an und berichte dann, auch wie es insgesamt mit dem AMD-Board läuft, worum es ja ging!
 
Zurück
Oben