StefanB
Vice Admiral Special
★ Themenstarter ★
Hallo Leute,
ich stehe vor einem Riesenproblem. Hoffentlich kann mir jemand helfen.
Nach Einbau eines neuen T-Bred 2400+ (mit Drahtmethode für kleinere Multis als 15.0 freigeschaltet) in mein Asus A7N8X Deluxe 1.04 mit Bios 1002.A bootete der PC zunächst normal. Die CPU wurde mit dem Multi 7.0 und FSB100 initialisiert, was mich nicht weiter verwunderte, da 7.0 und 15.0 bei diesem Bios identisch sind und eine unbekannte CPU immer mit FSB100 startet (man entschuldige diese laienhafte Darstellung).
Da ich mein System neu aufsetzen wollte, habe ich die Bios-Defaults geladen und ein paar Kleinigkeiten geändert und wollte anschließend die Multis mal der Reihe nach durchtesten.
Doch schon beim ersten Abspeichern (F10) erfreute mich der Monitor mit einem Zahlensalat-Bild.
Nun bootet der Rechner gar nicht mehr. Der Monitor schaltet sich kurz an und gleich wieder aus. CMOS-Clear mit Entfernen der Batterie nutzt gar nichts.
Das Problem scheint auch andere nForce2-Boards zu betreffen. HardTecs4U schreibt hier:
Einfrieren von nForce2 Platinen nach Speichern im BIOS
Abschließend müssen wir noch eine Eigenart der nForce2 Platinen ansprechen. Offenbar, wie wir erst zum Ende des Tests herausfiltern konnten, kommt es bei zu schnellen Speichervorgängen im BIOS zu einem Systemfreeze. Erst vermuteten wir, dass es mit groben Sprüngen bei FSB Änderungen zusammenhing, was sich aber als falsch herausstellte. Dort trat das Problem eben nur gehäuft auf, da wir bei den Übertaktungstests am häufigsten Änderungen im BIOS vornehmen mussten.
Das BIOS beendet dabei in der Regel zwar den Speichervorgang und resettet das System, jedoch wacht das Board danach nicht mehr auf. Es hat den Anschein, als würde der Prozessor nicht mehr initialisiert werden, wie uns Post Code Karten belegten. Wir trafen dieses Problem auf insgesamt 5 der 6 Testkandidaten an und konnten bis zum Schluss keine Erklärung zur Ursache dieses Phänomen finden. Insgesamt 8 mal während der Tests fror uns das System beim Speichern auf diese Weise ein und wollte nicht mehr aufwachen.
Während es uns möglich war, das MSI Mainboard durch Stecken des 100 MHz FSB SAFE Mode Jumpers wieder zum Leben zu erwecken, funtkionierte diese Methode auf keinem der anderen Mainboards (dort findet sich lediglich der reguläre FSB Jumper). Bei ASUS half der Austausch des BIOS Chips, wie der Hersteller uns mitteilte, dies funktionierte bei ABIT und EPoX allerdings nicht. Zu guter Letzt fanden wir eine Möglichkeit, die offenbar in diesem Fall immer funktioniert: Der Einsatz einer CPU mit 100 MHz FSB veranlasste die "schlafenden" Systeme dann endlich wieder zum Neustart.
Eventuell stellt der AOpen Kandidat hier eine Ausnahme dar, denn wir glauben einmal dort auf dieses Phänomen gestoßen zu sein, konnten aber mittels zweifachen ClearCMOS einen Neustart erreichen, was sonst nirgends gelang. Auch das zur Zeit im Test befindliche Barebone System mit Shuttle nForce2 Platine darf sich in die Reihen der Betroffenen einordnen, dazu aber dann in dem folgenden Test mehr.
Das hört sich alles nicht gut an. Andererseits mußte das Problem bei einigen von Euch aufgetreten sein.
Ich habe zwar noch einen T-Bird mit 100 MHz FSB, der steckt aber in einem anderen PC (von dem ich gerade schreibe) und das ist mir (noch) zu viel Arbeit. Auf den Asus-Support setzt ich keine großen Hoffnungen, gibt es den überhaupt für Kunden in Deutschland?
Hat jemand von Euch selbiges schon beobachtet und weiß Rat?
edit:
das Verlinken von Bildern scheint nicht zu klappen, sorry dafür.
edit2:
Bild ist wieder Online.
ich stehe vor einem Riesenproblem. Hoffentlich kann mir jemand helfen.
Nach Einbau eines neuen T-Bred 2400+ (mit Drahtmethode für kleinere Multis als 15.0 freigeschaltet) in mein Asus A7N8X Deluxe 1.04 mit Bios 1002.A bootete der PC zunächst normal. Die CPU wurde mit dem Multi 7.0 und FSB100 initialisiert, was mich nicht weiter verwunderte, da 7.0 und 15.0 bei diesem Bios identisch sind und eine unbekannte CPU immer mit FSB100 startet (man entschuldige diese laienhafte Darstellung).
Da ich mein System neu aufsetzen wollte, habe ich die Bios-Defaults geladen und ein paar Kleinigkeiten geändert und wollte anschließend die Multis mal der Reihe nach durchtesten.
Doch schon beim ersten Abspeichern (F10) erfreute mich der Monitor mit einem Zahlensalat-Bild.
Nun bootet der Rechner gar nicht mehr. Der Monitor schaltet sich kurz an und gleich wieder aus. CMOS-Clear mit Entfernen der Batterie nutzt gar nichts.
Das Problem scheint auch andere nForce2-Boards zu betreffen. HardTecs4U schreibt hier:
Einfrieren von nForce2 Platinen nach Speichern im BIOS
Abschließend müssen wir noch eine Eigenart der nForce2 Platinen ansprechen. Offenbar, wie wir erst zum Ende des Tests herausfiltern konnten, kommt es bei zu schnellen Speichervorgängen im BIOS zu einem Systemfreeze. Erst vermuteten wir, dass es mit groben Sprüngen bei FSB Änderungen zusammenhing, was sich aber als falsch herausstellte. Dort trat das Problem eben nur gehäuft auf, da wir bei den Übertaktungstests am häufigsten Änderungen im BIOS vornehmen mussten.
Das BIOS beendet dabei in der Regel zwar den Speichervorgang und resettet das System, jedoch wacht das Board danach nicht mehr auf. Es hat den Anschein, als würde der Prozessor nicht mehr initialisiert werden, wie uns Post Code Karten belegten. Wir trafen dieses Problem auf insgesamt 5 der 6 Testkandidaten an und konnten bis zum Schluss keine Erklärung zur Ursache dieses Phänomen finden. Insgesamt 8 mal während der Tests fror uns das System beim Speichern auf diese Weise ein und wollte nicht mehr aufwachen.
Während es uns möglich war, das MSI Mainboard durch Stecken des 100 MHz FSB SAFE Mode Jumpers wieder zum Leben zu erwecken, funtkionierte diese Methode auf keinem der anderen Mainboards (dort findet sich lediglich der reguläre FSB Jumper). Bei ASUS half der Austausch des BIOS Chips, wie der Hersteller uns mitteilte, dies funktionierte bei ABIT und EPoX allerdings nicht. Zu guter Letzt fanden wir eine Möglichkeit, die offenbar in diesem Fall immer funktioniert: Der Einsatz einer CPU mit 100 MHz FSB veranlasste die "schlafenden" Systeme dann endlich wieder zum Neustart.
Eventuell stellt der AOpen Kandidat hier eine Ausnahme dar, denn wir glauben einmal dort auf dieses Phänomen gestoßen zu sein, konnten aber mittels zweifachen ClearCMOS einen Neustart erreichen, was sonst nirgends gelang. Auch das zur Zeit im Test befindliche Barebone System mit Shuttle nForce2 Platine darf sich in die Reihen der Betroffenen einordnen, dazu aber dann in dem folgenden Test mehr.
Das hört sich alles nicht gut an. Andererseits mußte das Problem bei einigen von Euch aufgetreten sein.
Ich habe zwar noch einen T-Bird mit 100 MHz FSB, der steckt aber in einem anderen PC (von dem ich gerade schreibe) und das ist mir (noch) zu viel Arbeit. Auf den Asus-Support setzt ich keine großen Hoffnungen, gibt es den überhaupt für Kunden in Deutschland?
Hat jemand von Euch selbiges schon beobachtet und weiß Rat?
edit:
das Verlinken von Bildern scheint nicht zu klappen, sorry dafür.
edit2:
Bild ist wieder Online.
Zuletzt bearbeitet:
![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
)
