[Nobbi Habogs]

Board: GIGABYTE GA-MA790XT-UD4P (AM3, DDR3)
CPU: Phenom II X4 955 BE


Komischerweise bleibt der Takt immer bei 800 MHz. Also 200 MHz Bustakt und Multi x4.
Reagiert allerdings überhaupt nicht aufjegliche manuelle Änderungen des Mutliplikators, deaktivieren vom Speedstepping oder sonstwas. Die Spannung wurde aber auch nur mit 0,950V angegeben... Also erstmal BIOS geflashed auf das aktuellste nicht Beta BIOS.

Die Spannung ist nun schonmal korrekt höher, ob er aber wirklich so taktet weiß ich nicht. Als er dann ins Windows gehen wollte, bekommt er immer einen Bluescreen während des Ladevorgangs. Kann aber auch am OS liegen, ist ja nur meine Testsystem SSD, die überall dranhängt. Werd das mal neu installieren und gucken obs geht.

Aber kennt jemand den Fehler oder ist das bekannt?
CoolnQuiet bzw. die Lüftersteuerung des CPU Kühlers funktioniert leider nicht mehr nach dem BIOS Update, das hat vorher immer funktioniert

[foobar]

Ich kann dir zumindest schon mal sagen, dass der „955BE” nicht in der offiziellen Kompatibilitätsliste dieses Boards aufzutauchen scheint.

Ansonsten prüfe mal die Temperaturen (WLP eingetrocknet etc). Eventuell wird ihm einfach zu heiß, so dass er das Hochtakten deshalb verweigert.

Ich meine mich dunkel zu erinnern, dass die ErP-Einstellung sowie C1E-Support im BIOS manchmal auch zu Problemen mit dem CPU-Takt führen konnte.

Und natürlich könntest du mal Linux testen, um zu schauen, ob es vielleicht ein softwareseitiges Problem ist (irgendein Windows-Treiber für die CPU hält sie niedrig oder so).

[Nobbi Habogs]

Hm, in der Tat, da stehen gar keine BE CPUs, aber die listet Gigabyte wohl nie auf. Macht zwar keinen Sinn, aber auch bei neueren Boards werden diese nicht aufgelistet. Hab jetzt bei einem anderen 790er und einem neuen 970er Board von Gigabyte geguckt, die stehen da einfach nicht drin, obwohl alle AM3 CPUs beim 970er mit Release BIOS unterstützt werden. Bei einem ASRock Board sind die BEs extra ausgewiesen.

Also ich hab Windows ja mal neu installiert wie angekündigt und nun geht alles reibungslos. Der Prozessor wurde dann auch sichtlich zu heiß und ging auf 90°C, habe also erstmal den Kühler gereinigt und neue WLP drauf. Davon abgesehen, dass er wirklich was heiß wurde, ging er vorher ja aber auch nie über 60°C im BIOS. Scheinbar ist der echt recht empfindlich bei den Temperaturen, checkt beim Startup wie heiß er wird und regelt sich selbst runter. Witzig war ja, vor dem BIOS Update lief Windows Da hat er sich dann bei genau 80°C immer selbst abgeriegelt in der Stromzufuhr vermutlich, auch wenn man das in CPU-Z an der Spannung nicht sehen konnte. Nur komisch wieso er dann nach Neuinstallation von Windows normal verhält wie ich es erwartet hätte und halt einfach normal taktet und heiß wird.

Nun, die Plattform scheint definitiv ihre Eigenheiten zu haben.
Allein die Tatsache das Dualchannel aktiv ist, wenn man die RAM Module in Channel 1+2 setzt, welch ein Unding!

Aber der Vorbesitzer hat dort auch schon Windows 10 installiert gehabt und Windows per Hardware ID aktiviert. Als ich Windows neu installiert habe, war es danach nämlich sofort aktiviert. Das könnte natürlich auch zu Problemen geführt haben, wenn ich dann einfach wahllos irgendeine andere SSD mit Windows 10 drangehangen hab.

[Nobbi Habogs]

Der folgende Kommentar ist recht interessant. Jemand hatte auch berichtet, dass nach einem BIOS Flash sein MBR beschädigt wurde. Darauf wurde wie folgt reagiert:

"Hallo zusammen,

Gigabyte sichert doch unter dem Begriff "Virtual Dual BIOS" das BIOS auf einem für das OS eigentlich nicht sichtbaren Sektor. Wenn da was schief geht, kann z.Bsp. Windows nicht mehr starten.
Unter einer bekannten Suchmaschine einfach als Suchbegriff "Virtual Dual BIOS" eingeben.
Dort schreibt jemand in einem Forum: "Die Kopie landet in der ersten Spur hinter dem MBR".
Des weiteren schreibt er: "Normalerweise" wird die erste Spur nur vom MBR ganz vorn genutzt, der Rest bleibt frei. Das muß aber nicht zwingend so sein." Es gibt wohl auch Programme, die ihre Aktivierungsdaten dort hinterlegen.
Mittlerweile gibt es wohl BIOS-Updates von Gigabyte für div. Boards, in denen man diese Funktion deaktivieren kann."

[Homerclon]

Allein die Tatsache das Dualchannel aktiv ist, wenn man die RAM Module in Channel 1+2 setzt, welch ein Unding!

Wieso Unding? Ungewöhnlich, aber kein Unding.

[foobar]

"Die Kopie landet in der ersten Spur hinter dem MBR"

Der Bereich nennt sich auch „MBR-Lücke”. Also die Lücke zwischen dem MBR und dem Beginn der ersten Partition.

Normalerweise besteht der MBR aus dem ersten Sektor, also den ersten 512 Byte. Davon sind die ersten 440 Byte der eigentliche Code zum Booten des Rechners. Das ist das, was das BIOS ganz am Schluss in den RAM lädt und dort ausführt. Der muss dann das Betriebssystem hochfahren. Im Rest stecken ein paar Verwaltungsbytes und die MBR-Partitionstabelle mit ihren 4 Einträgen.

Im alten CHS-Adressierungsschema (Cylinder, Head, Sektor) aus den Urzeiten des PC waren 6 Bit für die Zylindernummer vorgesehen. Das macht 2⁶ = 64 mögliche Werte. Allerdings werden die ab 1 gezählt, nicht ab 0. Es gibt also nur 63 mögliche Sektoren in einem Zylinder. Weil DOS verlangte, dass die Partitionen immer auf einem ganzen Zylinder anfangen und der erste Zylinder nun schon teilweise mit dem MBR belegt war, hat man den Anfang der ersten Partition dann auf den zweiten Zylinder verfrachtet. Entsprechend blieb der Rest des ersten Zylinders (31 KB) einfach frei. Irgendwann wurde dann auf LBA-Adressierung umgestellt, aber man wollte abwärtskompatibel bleiben, also blieb die Lücke bestehen. Ähnliches hat man dann wegen 4Kn erneut gemacht: Die Partitionsgrenzen sollten durch 8 teilbar sein, damit man keine Leistung verliert. Tatsächlich wurde die Lücke dann erweitert, aus Gründen, und heute ist es üblich, dass die erste Partition auf Sektor 2048 anfängt.

Das Problem ist, dass in dieser Lücke mehr oder weniger Wildwest-Zustände herrschen. Es gibt halt kein Dateisystem oder sonstige Verwaltungsstrukturen oder verbindliche Standards, die festlegen, wer den Bereich für was nutzen darf. Manche Programme haben dort ihre Kopierschutzfunktionen hinterlegt. Viele Bootloader, die nicht komplett in die o.g. 440 Byte rein passen, lagern den Rest dann da. GRUB ist so ein Beispiel. In den 440 Byte des MBRs steckt die Stage 1, welche nichts weiter macht, als die in der MBR-Lücke liegende Stage 1.5 zu laden. Die hat gerade genug Platz, um einen Dateisystemtreiber für Linux zu enthalten und kann damit den Rest (Stage 2) in der normalen Boot-Partition finden und ausführen. Und erst diese letzte Stufe ist dann der eigentliche Manager mit Menüs und Konfigurationsdateien und so weiter. Und in der MBR-Partitionstabelle ist ja nur Platz für die 4 primären Partitionen. Die logischen Laufwerke in einer erweiterten Partition müssen irgendwo anders eingetragen werden. Auch das passiert häufig in der MBR-Lücke.

Ich kann also nicht einfach sagen: Den Bereich von Byte 513 bis 1023 nehme ich jetzt mal für mich, um da meinen Müll zu lagern. Denn jemand anderes könnte bereits die selbe Idee gehabt haben. Man müsste also herausfinden, welche Bereiche bereits belegt sind und wo man ggf. noch was für sich selbst nutzen kann. Und dann hoffen, dass alle anderen auch so nett sind, nicht einfach aufs Geratewohl in meine Daten zu reiern. Das ist natürlich mitunter etwas hakelig. Den logischen Laufwerken kann man z.B. dadurch aus dem Weg gehen, dass man halt die Partitionstabelle auswertet. Ein MBR-Partitionierungsschema ist ja immer da, sonst hätte man keine MBR-Lücke, also lohnt es sich, diese Logik zu implementieren. Aber dann alle anderen denkbaren Programme (und nun offenbar auch noch BIOSe) und deren Ansprüche an die MBR-Lücke kennen, das wird halt schnell aufwendig.

Bei GRUB z.B. habe ich es schon erlebt, dass er bei der Installation den Kopierschutz einer Windows-Software erkannte und dann diesen Bereich vermieden hat.

[Nobbi Habogs]

Wieso Unding? Ungewöhnlich, aber kein Unding.

Das war auch extra übertrieben ausgedrückt, künstliche Empörung.
Ein Frevel!

...

Sehr aufschlussreich, danke