Festplattenschaden durch Magnete?

Versuch mal den AHCI Treiber (ahci_load="YES" in /boot/loader.conf) und poste hier pciconf -lv rein. Ich hatte die Tag nen Problem mit einem Marvell SATA3 Controller, dass mit einer Zeile mehr (aus -CURRENT) in ahci.c zu fixen war. Manchmal sind es die kleinen Hardwarebugs die Probleme machen. In meinem Fall fand ahci.ko keine Platten an den SATA Channels, weil Interrupts falsch signalisiert wurden und die Firmware der Karte nicht warte bis die Platten initialisiert waren.
 
Crest schrieb:
Versuch mal den AHCI Treiber (ahci_load="YES" in /boot/loader.conf) und poste hier pciconf -lv rein. Ich hatte die Tag nen Problem mit einem Marvell SATA3 Controller, dass mit einer Zeile mehr (aus -CURRENT) in ahci.c zu fixen war. Manchmal sind es die kleinen Hardwarebugs die Probleme machen. In meinem Fall fand ahci.ko keine Platten an den SATA Channels, weil Interrupts falsch signalisiert wurden und die Firmware der Karte nicht warte bis die Platten initialisiert waren.
Zum Vergrößern anklicken....

Läuft schon ne ganze Weile in ahci-Modus. pciconf:
Code: 
hostb0@pci0:0:0:0:      class=0x060000 card=0x96001022 chip=0x96001022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    class      = bridge
    subclass   = HOST-PCI
pcib1@pci0:0:1:0:       class=0x060400 card=0x96021022 chip=0x96021022 rev=0x00 hdr=0x01
    vendor     = 'Advanced Micro Devices (AMD)'
    class      = bridge
    subclass   = PCI-PCI
pcib2@pci0:0:4:0:       class=0x060400 card=0x96001022 chip=0x96041022 rev=0x00 hdr=0x01
    vendor     = 'Advanced Micro Devices (AMD)'
    class      = bridge
    subclass   = PCI-PCI
ahci0@pci0:0:17:0:      class=0x010601 card=0x43911002 chip=0x43911002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.'
    device     = 'SB700 SATA Controller [AHCI mode]'
    class      = mass storage
    subclass   = SATA
ohci0@pci0:0:18:0:      class=0x0c0310 card=0x43971002 chip=0x43971002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.'
    device     = 'SB700 USB OHCI0 Controller'
    class      = serial bus
    subclass   = USB
ohci1@pci0:0:18:1:      class=0x0c0310 card=0x43981002 chip=0x43981002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.'
    device     = 'Standard OpenHCD USB-Hostcontroller (SB700)'
    class      = serial bus
    subclass   = USB
ehci0@pci0:0:18:2:      class=0x0c0320 card=0x43971002 chip=0x43961002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.'
    device     = 'SB700 USB EHCI Controller'
    class      = serial bus
    subclass   = USB
ohci2@pci0:0:19:0:      class=0x0c0310 card=0x43981002 chip=0x43971002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.'
    device     = 'SB700 USB OHCI0 Controller'
    class      = serial bus
    subclass   = USB
ohci3@pci0:0:19:1:      class=0x0c0310 card=0x43991002 chip=0x43981002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.'
    device     = 'Standard OpenHCD USB-Hostcontroller (SB700)'
    class      = serial bus
    subclass   = USB
ehci1@pci0:0:19:2:      class=0x0c0320 card=0x43961002 chip=0x43961002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.'
    device     = 'SB700 USB EHCI Controller'
    class      = serial bus
    subclass   = USB
none0@pci0:0:20:0:      class=0x0c0500 card=0x43851002 chip=0x43851002 rev=0x3a hdr=0x00
    vendor     = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.'
    device     = 'ATI SMBus (ATI RD600/RS600)'
    class      = serial bus
    subclass   = SMBus
none1@pci0:0:20:2:      class=0x040300 card=0x888f16f3 chip=0x43831002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.'
    device     = 'IXP SB600 High Definition Audio Controller'
    class      = multimedia
    subclass   = HDA
isab0@pci0:0:20:3:      class=0x060100 card=0x43831002 chip=0x439d1002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.'
    device     = 'SB700 LPC host controller'
    class      = bridge
    subclass   = PCI-ISA
pcib3@pci0:0:20:4:      class=0x060401 card=0x00000000 chip=0x43841002 rev=0x00 hdr=0x01
    vendor     = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.'
    device     = 'IXP SB600 PCI to PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
ohci4@pci0:0:20:5:      class=0x0c0310 card=0x43961002 chip=0x43991002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.'
    device     = 'SB700 USB OHCI2 Controller'
    class      = serial bus
    subclass   = USB
hostb1@pci0:0:24:0:     class=0x060000 card=0x00000000 chip=0x12001022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(Family 10h) Athlon64/Opteron/Sempron HyperTransport Technology Configuration'
    class      = bridge
    subclass   = HOST-PCI
hostb2@pci0:0:24:1:     class=0x060000 card=0x00000000 chip=0x12011022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(Family 10h) Athlon64/Opteron/Sempron Address Map'
    class      = bridge
    subclass   = HOST-PCI
hostb3@pci0:0:24:2:     class=0x060000 card=0x00000000 chip=0x12021022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(Family 10h) Athlon64/Opteron/Sempron DRAM Controller'
    class      = bridge
    subclass   = HOST-PCI
hostb4@pci0:0:24:3:     class=0x060000 card=0x00000000 chip=0x12031022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(Family 10h) Athlon64/Opteron/Sempron Miscellaneous Control'
    class      = bridge
    subclass   = HOST-PCI
hostb5@pci0:0:24:4:     class=0x060000 card=0x00000000 chip=0x12041022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = '(Family 10h) Athlon64/Opteron/Sempron Link Control'
    class      = bridge
    subclass   = HOST-PCI
vgapci0@pci0:1:5:0:     class=0x030000 card=0x00001002 chip=0x96141002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.'
    device     = 'ATI RADEON HD 3300 Graphics (RS780)'
    class      = display
    subclass   = VGA
none2@pci0:1:5:1:       class=0x040300 card=0x960f1002 chip=0x960f1002 rev=0x00 hdr=0x00
    vendor     = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.'
    class      = multimedia
    subclass   = HDA
re0@pci0:2:0:0: class=0x020000 card=0x816810ec chip=0x816810ec rev=0x02 hdr=0x00
    vendor     = 'Realtek Semiconductor'
    device     = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)'
    class      = network
    subclass   = ethernet
atapci0@pci0:3:5:0:     class=0x010400 card=0x65121095 chip=0x35121095 rev=0x01 hdr=0x00
    vendor     = 'Silicon Image Inc (Was: CMD Technology Inc)'
    device     = 'SATALink/SATARaid Controller (Sil 3512)'
    class      = mass storage
    subclass   = RAID

Ich jetzt eine SATA-PCI-Karte reingesteckt, die ich noch rumliegen hatte (das letzte in der Auflistung) und die SSD daran gehangen. Jetzt kompilier ich weiter fleißig, momentan läufts (was aber auch nichts heißt).
 
Die Silicon Image Karte ist im ATA RAID Modus nicht im AHCI Modus und läuft dementsprechend nicht über ahci.ko.
 
Crest schrieb:
Die Silicon Image Karte ist im ATA RAID Modus nicht im AHCI Modus und läuft dementsprechend nicht über ahci.ko.
Zum Vergrößern anklicken....

Ja, aber die habe ich ja jetzt erst reingetan, vorher lief alles über ahci. Die Karte kann garkein ahci, wobei die device-Namen sich ja trotzdem auf ada* ändern.
 
So, ich habe jetzt ein neues Board (AMD Fusion), die Platten hängen dran und gerade wird gescrub'ed. Positiv gegenüber beiden Sapphire AM3-Boards von mir (Server und WS), ist schonmal dass powerd funktioniert. Vielleicht mag FreeBSD auch einfach Sapphire nicht...
 
Nicht funktionierendes Cool and Quiet ist meist ein Hinweis auf ein spinnendes BIOS. Da die Hersteller fast durchgehend die gleiche Software verbasteln, sind dann meist ganze Serien betroffen. Unvergessen zum Beispiel Asus komplette M2-Serie, die einfach nur Murks war und unter FreeBSD immer nur Ärger machte.
 
So, ein Update in der neverending story:

Der Server läuft mit dem Asrock Fusion Board problemlos, immerhin.

Der Desktop macht immernoch Probleme. Er hat jetzt auch ein neues Mainboard bekommen, nachdem die Fehler -- trotz Umtausch und Ersatz -- bei dem alten nicht weggingen. Das neue Mainboard ist auch Asrock, hat auch ein UEFI und ist aus der 800er Reihe von AMD (statt der 700er vorher). Außerdem sind noch 4GiB RAM dazugekommen..
Fazit nach einer Woche: Dieselben Problem wie vorher :grumble:
erst geht alles prima, ein buildworld mit -j5, ein install von KDE aus den Ports. Auch das Arch Linux tut prima... dann aufeinmal segfaulten alle Programme weg, kurz darauf panic. Ist jetzt sowohl unter Arch, als auch unter FreeBSD aufgetreten. Nach einem Reboot unter FreeBSD läuft der lost+found voll mit Dateistücken, danach kann ich aber erstmal wieder problemlos arbeiten, ein buildworld läuft wieder problemlos durch. Besonders merkwürdig, die Abstürze passierten nicht bei starker disk-IO, sondern z.B. beim Schauen eines Films über NFS vom Server.

Also zusammenfassend:
- der Desktop sitzt inzwischen hinter einem Spannungsregulator
- der Desktop hat ein neues Netzteil
- der Desktop hat ein neues Mainboard
- der Desktop hat neue SATA-Kabel, die Platte ist eine SSD
- die Probleme treten mit zwei unterschiedlichen CPUs auf

Was kann man da noch machen, außer religiös zu werden oder einen Mac zu kaufen? Kann es es sein, dass mit dem alten Mainboard die Fehler im FS gelandet sind und erst jetzt aufgetaucht? Trotz intensiver IO und Load zwischendurch?
Dann würde ich die SSD nochmal komplett plattmachen und neuinstallieren...
 
Jetzt wo Du "NFS" sagst...

Kannst Du mal proberweise die Netzwerkkarte im Mainboard ausschalten (geht im BIOS normalerweise) und dann versuchen, den zu betreiben. Wenn Du tatsächlich Netzwerk brauchst, kannst Du ja mal versuchen eine Karte einzubauen anstatt die Onboard-Variante.

Grund warum ich das sage:
- manche Netzwerkkarten sind einfach kaputt
- manche Netzwerkkarten gehen mit der Zeit kaputt
- manche BIOSe haben irgendwelche ominösen Probleme mit dem Zuordnen von Ressourcen zu PCI(e)-Geräten und verursachen unvorhersagbaren Ärger

Und zweitens ist "Film schauen" auch so eine Sache. Um Beschleunigung von 2D zu erreichen umgehen Grafikkartentreiber Schnittstellen und auch da kann Ressourcen-Mapping in die Hose gehen.

Du hast nicht zufällig irgendwo Deine dmesg gepostet oder? Nur um einen Blick darauf zu werfen, ob IRQs oder andere Ressourcen sich irgendwie überlappen.

Ich hatte auch Mainboards von MSI wo reihenweise AGP-Ports kaputt gegangen sind. Musste anschließend immer PCI-Grafikkarten in die PCs einbauen. Ich hatte auch einmal eine Netzwerkkarte, die Traffic gefälscht hat (kaputt). Das merkt man überhaupt nicht, bis es am Ende komplett knallt und nichts mehr geht.

Man sieht manchmal echt Pferde kotzen, wenn man viel Hardware in die Hände kriegt. Bei Problemen mit FreeBSD war stets die Hardware bei mir schuld. Es ist wahnsinnig schwierig einen Fehler zu finden und kann einiges kosten. Manchmal habe ich Sorgen, einen Defekt von 1500 Euro zu reklamieren, weil die Reklamationsabteilung vielleicht einfach doof ist und guckt ob MS-Windows startet oder sowas beklopptes laufen lassen wie "PC Doktor", anstatt einen richtigen Stresstest zu machen.

Ich hatte 1 Mainboard von Asrock, da war der Mikrofoneingang kaputt. Ich kaufe ab jetzt nur noch mit Qualitätskondensatoren (Feststoff oder Polymer). Mit Gigabyte habe ich bis jetzt gute Erfahrungen gehabt.
 
nakal schrieb:
Jetzt wo Du "NFS" sagst...

Kannst Du mal proberweise die Netzwerkkarte im Mainboard ausschalten (geht im BIOS normalerweise) und dann versuchen, den zu betreiben. Wenn Du tatsächlich Netzwerk brauchst, kannst Du ja mal versuchen eine Karte einzubauen anstatt die Onboard-Variante.

Grund warum ich das sage:
- manche Netzwerkkarten sind einfach kaputt
- manche Netzwerkkarten gehen mit der Zeit kaputt
- manche BIOSe haben irgendwelche ominösen Probleme mit dem Zuordnen von Ressourcen zu PCI(e)-Geräten und verursachen unvorhersagbaren Ärger

Und zweitens ist "Film schauen" auch so eine Sache. Um Beschleunigung von 2D zu erreichen umgehen Grafikkartentreiber Schnittstellen und auch da kann Ressourcen-Mapping in die Hose gehen.

Du hast nicht zufällig irgendwo Deine dmesg gepostet oder? Nur um einen Blick darauf zu werfen, ob IRQs oder andere Ressourcen sich irgendwie überlappen.

Ich hatte auch Mainboards von MSI wo reihenweise AGP-Ports kaputt gegangen sind. Musste anschließend immer PCI-Grafikkarten in die PCs einbauen. Ich hatte auch einmal eine Netzwerkkarte, die Traffic gefälscht hat (kaputt). Das merkt man überhaupt nicht, bis es am Ende komplett knallt und nichts mehr geht.

Man sieht manchmal echt Pferde kotzen, wenn man viel Hardware in die Hände kriegt. Bei Problemen mit FreeBSD war stets die Hardware bei mir schuld. Es ist wahnsinnig schwierig einen Fehler zu finden und kann einiges kosten. Manchmal habe ich Sorgen, einen Defekt von 1500 Euro zu reklamieren, weil die Reklamationsabteilung vielleicht einfach doof ist und guckt ob MS-Windows startet oder sowas beklopptes laufen lassen wie "PC Doktor", anstatt einen richtigen Stresstest zu machen.

Ich hatte 1 Mainboard von Asrock, da war der Mikrofoneingang kaputt. Ich kaufe ab jetzt nur noch mit Qualitätskondensatoren (Feststoff oder Polymer). Mit Gigabyte habe ich bis jetzt gute Erfahrungen gehabt.
Zum Vergrößern anklicken....

Es hatte vorher die Probleme auch mit ohne Netzwerk. Die Onboard-Karte ist Atheros, gehört also zu den besseren. Ich habe mal ein dmesg von Arch angehangen, weil das gerade läuft...
 

Anhänge

  • dmesg_arch.txt
    54,3 KB · Aufrufe: 393
h^2 schrieb:
Die Onboard-Karte ist Atheros, gehört also zu den besseren.
Zum Vergrößern anklicken....
Eine dieser guten Karten hat mir dank massiver Speicherkorruption durch einen Hardwarebug einen ganzen ZPool gekostet! Ich habe damals einen Patch eingereicht, der dann auch committed wurde. Leider erst nach 8.2, ist also nur im 8-STABLE und 9-CURRENT bzw. der kommenden 9.0-BETA1: http://svnweb.freebsd.org/base?view=revision&revision=220457

Betrifft allerdings nur die älteren if_age Karten und auch nur wenn mehr als 4GB RAM in der Kiste stecken. Die neueren if_ale und co sind nicht betroffen.
 
Mal ganz was anderes...

ich lese da in der dmesg sowas wie "bad subpartition". Poste mal bitte fdisk und bsdlabel Offsets und Größen. Da muss doch was faul sein! Am besten wären auch noch andere Platteninfos, wenn es geht (was GEOM so sagt etc).

Ich hatte auch mal bei dem bekloppten Partitionierungstool von OpenBSD (wo man einen Taschenrechner braucht) aus Versehen überlappende Partitionen hingekriegt und hatte auch ewig Daten kaputt in meinem Experimental-Setup.
 
Können wir vielleicht diese ewigen gegenseitigen Beleidigungen mal unterlassen? Sowas kann von mir aus im Mülleimer oder per PN geschehen, aber bitte nicht hier! :(
 
OpenBSD Partitionstool ist solange ein Krampf bis einem jemand sagt wo man "*" verwenden kann und sowie Größen auch in MiB und GiB angeben werden können.
 
Hoi,

können mer da nun endlich mal en Knopf dran machen ? - also, welche aktuelle Hardware und Konfiguration und Software ist vorhanden und welche Probleme treten dabei konkret, bei welchen Umgebungsbedingungen, jetzt auf ?

Gruß Bummibär
 
Vielen Dank für euren Input und das weitere Interesse die obskursten PC-Probleme ever zu lösen!
Ich habe vorübergehend kapituliert und verabschiede mich in den Urlaub. Wenn ich in drei Wochen zurückkomme, mache ich nochmal rundumschlag, d.h. alles neuformatieren, alles neubauen, load auf arch und freebsd, stresstests etc.
 
Leute, Leute....lasst doch mal die Kirche im Dorf.

Stell doch mal spasshalber einen Kompass bei deinem Arbeitsplatz auf. Da siehst dann gleich wo sich Magnetfelder befinden.
 
Nur zur Info: Nachdem ich eine Woche lang alle RAM-Riegel einzeln und in Kombinationen gememtestet habe, ließen sich mehrere Defekte ausmachen (manchmal erst nach 6 Stunden test...). Diese wurden ausgetauscht.
Ein Ach-Linux läuft seit einem Monat problemlos.

Fazit: nie aus einen erfolgreichen Memtest schließen, dass die RAM-Riegel funktionieren :S
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben