AsRock K8Upgrade VM800: SATA-HDD spackt

System:
AMD Athlon64 3400+ (Newcastle)
AsRock K8Upgrade VM800 (aktuelles Hersteller-BIOS installiert)
2 GiB RAM
Ati Radeon X1600Pro

Wenn an einem SATA-Port eine nackte, also zuvor an einem anderen System mit dd gebügelte SATA-HDD (auf 1.5 GB/s per Jumper gesetzt, sonst geht es generell nicht) hängt, startet das System normal und auch das BIOS lässt sich normal aufrufen und bedienen. Wird aber nun auf dieser SATA-HDD eine Partition angelegt (bootable flag gesetzt oder nicht spielt keine Rolle), bleibt beim nächsten Start POST reproduzierbar unmittelbar nach der Erkennung der SATA-HDD hängen. Dabei spielt es keine Rolle, ob und was an den IDE-Ports hängt.

Was ist das nun wieder für ein Müll und wie bekomme ich die SATA-HDD richtig in Gang? Da soll nämlich das Betriebssystem drauf.

Nochmal duckduckgo mit anderem String "post hangs after partitioning sata hdd" gefüttert, und gleich der erste Treffer führt zu dem hier. Es ist tatsächlich auf den ersten Blick widersinnig, im BIOS für SATA den RAID-Modus – bei dazu abgestöpselter SATA-HDD, sonst kommt man ja gar nicht ins BIOS, s. o. – zu aktivieren, wenn man kein SATA-RAID fahren will, aber es funktioniert. Der SATA-Controller hat nämlich ein eigenes BIOS, das nur angestartet wird, wenn im BIOS der Hauptplatine für SATA der RAID-Modus aktiviert wird. Ein RAID wid durch diese Einstellung nicht angelegt. Das könnte man (mit zwei SATA-HDDs) im BIOS des SATA-Controllers anlegen. Auch die andere SATA-HDD, auf der schon ein passendes Linux drauf ist, läuft. Physikalisch HDDs tauschen geht in diesem Fall schneller als per Software klonen.

Zitat von Sje

Kann sein das du das die Platte falsch gejumpert hast […]

Danke, aber es läuft jetzt alles, Kernel wurde erfolgreich kompiliert. Es lag wirklich nur an dieser seltsamen notwenigen Einstellung im BIOS der Hauptplatine.

Zitat von Sje

Ansonsten test mal ob der RAM sauber läuft, ältere Sockel 754/939 CPU's haben Probleme mit größern DDR-RAM Modulen.
https://de.wikipedia.org/wiki/AMD_Athlon_64#Prozessorkerne

Trifft hier nicht zu, Newcastle mit zwei DS-Riegeln ist unter den Problemen nicht aufgelistet. Außerdem wurde vor irgendwelchen Software-Installationsversuchen memtest86+ drüber gescheucht und nach drei fehlerfreien Durchläufen beendet.

Diese ganze Aktion mit dem AsRock K8Upgrade VM800 hat eine längere Vorgeschichte. Ursprünglich steckte in der Kiste ein MSI MS-7181 Ver. 2.0, aber das zeigt sich extrem wählerisch hinsichtlich der AGP-Grafikkarte. Ati Radeon X1650Pro, Ati Radeon X1050 und nvidia GeForce 7600GS funktionieren nicht richtg. Ein Start mit einem Kernel mit KMS führt dazu, dass das System beim Start irgendwann nach dem Modesetting zufällig verteilt einfriert. Ein Kernel ohne KMS bzw. mit Bootparameter nomodeset startet durch, aber beim Versuch einen neuen Kernel zu kompilieren friert das System zufällig verteilt entweder bei make clean oder spätestens ziemlich am Anfang von make bzImage ein. Mit einer GeForce FX5200 fuktioniert das System fehlerfrei, aber diese Grafikkarte gehört in ein AGP-Endzeitsystem nicht rein. Sockel-A-Bretter von MSI sind bekannt dafür, nicht jede AGP-Grafikkarte, die von den Specs her eigentlich laufen müsste, zu nehmen, aber so extrem wie beim MS-7181, das zudem den neueren Sockel-754 hat, ist das bei den drei Sockel-A-Bretter von MSI in meinen Museumskisten nicht. Für die drei fand sich dann doch jeweils eine relativ leistungsstarke Grafikkarte.
Ende vom Lied: Prozessor und RAM wurden vom MS-7181 auf das K8Upgrade VM800 transferiert. Bei genauerer Betrachtung des ausgebauten MS-7181 fallen zwölf baugleiche Elkos "TEAPO 1000 µF 6,3 V" auf, von denen neun sichtbar aufgebläht sind. Lötorgie mit ungewissem Ausgang oder gleich Begleitung beim letzten Gang?