Absturz beim Speichern der Einstellungen in der UEFI-Firmware?

[Marc Haber]

Hallo,

mein neues Mainboard ist ein Asrock B450 Pro 4 mit aktueller Firmware
3.60. Sobald ich im Setup der UEFI-Firmware ("BIOS-Setup") die
Einstellungen speichere, wird der Bildschirm schwarz, die Lüfter
drehen hoch und es tut sich nichts mehr. Ich habe das System auch mal
in diesem Zustand eine halbe Stunde stehen lassen, da tut sich nichts.

In diesem Zustand wird auch der Reset-Knopf ignoriert, erst ein langer
Druck auf den Powerbutton wird honoriert, und wenn ich im UEFI
irgendwelche Änderungen gemacht habe, sind sie nur teilweise erhalten.

Woran kann das liegen? Möchte die UEFI-Firmware ihre Settings irgendwo
auf der Festplatte ablegen und findet diese Stelle nicht (weil kein
Windows installiert ist)? Oder ist das ein Fall für den
Asrock-Support?

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Thomas Krenzel .]

On 21.09.2019 17:01, Marc Haber wrote:
> Hallo,
>
> mein neues Mainboard ist ein Asrock B450 Pro 4 mit aktueller Firmware
> 3.60. Sobald ich im Setup der UEFI-Firmware ("BIOS-Setup") die
> Einstellungen speichere, wird der Bildschirm schwarz, die Lüfter
> drehen hoch und es tut sich nichts mehr. Ich habe das System auch mal
> in diesem Zustand eine halbe Stunde stehen lassen, da tut sich nichts.

Hast Du RTFM und dort wie auf Seite 27 Punkt 2.5 beschrieben das BIOS
gecleart?

> In diesem Zustand wird auch der Reset-Knopf ignoriert, erst ein langer
> Druck auf den Powerbutton wird honoriert, und wenn ich im UEFI
> irgendwelche Änderungen gemacht habe, sind sie nur teilweise erhalten.

Alle Speicher bis auf ein RAM raus, alle HDD/SSD abgezogen?
Alle Steckverbindungen auf korregden Sitz überprüft?
Alle Stromanschlüsse sicher angeschlossen? Und richtig?
DAs Netzteil hat ausreichend Leistung um den Prozessor zu betreiben?

> Woran kann das liegen? Möchte die UEFI-Firmware ihre Settings irgendwo
> auf der Festplatte ablegen und findet diese Stelle nicht (weil kein
> Windows installiert ist)? Oder ist das ein Fall für den
> Asrock-Support?

Ich vermute eher Assembly-Fail oder NT. ODer RAM.

Da könnte man strukturiert vorgehen, um den Fehler einzugrenzen. Mach
das mal.

Da ist keine Zauberei, sondern Handwerk mit notwendig sauberer
Arbeitsweise vonnöten.

Viel Erfolg
Thomas

[Thomas Krenzel .]

On 21.09.2019 17:01, Marc Haber wrote:

> mein neues Mainboard ist ein Asrock B450 Pro 4 mit aktueller Firmware
> 3.60.

Selbst geflasht?

Hast Du hier:
https://www.asrock.com/MB/AMD/B450%20Pro4/index.asp#BIOS

das gelesen:


BIOS 3.60
1. Update AMD AGESA Combo-AM4 1.0.0.3 ABB
2. Improve Destiny2 gaming experience with Matisse CPU.

*ASRock do NOT recommend updating this BIOS if Pinnacle, Raven, Summit
or Bristol Ridge CPU is being used on your system.
*Before updating this BIOS, please also read the description in previous
BIOS version.


BIOS 3.50 2
* Please install "AMD all in 1 with VGA driver ver:18.50.16.01_WHQL" or
a later version before updating to this BIOS.
** If you updated the BIOS before updating the AMD all in one driver,
please refer to the Display recovery SOP to recover your system.
*** User will not able to flash previous BIOS once upgrading to this
BIOS version.
**** If the current BIOS version is older than P1.80, please update BIOS
to P1.80(PinnaclePI-AM4_1.0.0.6) before updating this version.



Örks ;)


Viel Erfolg
Thomas

[Rainer Knaepper]

mh+usene...@zugschl.us (Marc Haber) am 21.09.19 um 17:01:

> Woran kann das liegen?

Übertakten? Oder passiert das auch bei unkritischen Änderungen?

Rainer

--
Die Ente bleibt draußen...

[Marc Haber]

"Thomas Krenzel ." <thurga...@gmx.de> wrote:
>On 21.09.2019 17:01, Marc Haber wrote:
>> mein neues Mainboard ist ein Asrock B450 Pro 4 mit aktueller Firmware
>> 3.60. Sobald ich im Setup der UEFI-Firmware ("BIOS-Setup") die
>> Einstellungen speichere, wird der Bildschirm schwarz, die Lüfter
>> drehen hoch und es tut sich nichts mehr. Ich habe das System auch mal
>> in diesem Zustand eine halbe Stunde stehen lassen, da tut sich nichts.
>
>Hast Du RTFM und dort wie auf Seite 27 Punkt 2.5 beschrieben das BIOS
>gecleart?

In meinem Handbuch steht dort, dass man nach einem selbst
durchgeführten Firmware-Update nicht das BIOS direkt clearen darf,
sondern das System erst einmal booten soll, wenn man das BIOS clearen
möchte.

Weder habe ich ein Firmware-Update selbst durchgeführt (die 3.60 war
schon drauf als ich das Board gekauft habe), noch habe ich das
Bedürfnis gespürt, ein BIOS clear durchzuführen

Was möchtest Du mir sagen?

>> In diesem Zustand wird auch der Reset-Knopf ignoriert, erst ein langer
>> Druck auf den Powerbutton wird honoriert, und wenn ich im UEFI
>> irgendwelche Änderungen gemacht habe, sind sie nur teilweise erhalten.
>
>Alle Speicher bis auf ein RAM raus, alle HDD/SSD abgezogen?

Ja, das war der Zustand beim ersten Versuch.

>Alle Steckverbindungen auf korregden Sitz überprüft?
>Alle Stromanschlüsse sicher angeschlossen? Und richtig?
>DAs Netzteil hat ausreichend Leistung um den Prozessor zu betreiben?

Die Maschine läuft auch unter hoher Last anstandslos. Das einzige was
nicht geht sind Veränderungen an der UEFI-Firmware, was dummerweise
die Bootreihenfolge und die Lüftersteuerung beinhaltet.

Vor dem Umbau war in dem Rechner ein 135-W-Prozessor (jetzt 60 Watt)
und zwei weitere Steckkarten.

>Ich vermute eher Assembly-Fail oder NT. ODer RAM.
>
>Da könnte man strukturiert vorgehen, um den Fehler einzugrenzen. Mach
>das mal.
>
>Da ist keine Zauberei, sondern Handwerk mit notwendig sauberer
>Arbeitsweise vonnöten.

Etwas weniger Arroganz fände ich fein.

Grße

[Marc Haber]

Rainer Knaepper <rai...@smial.prima.de> wrote:
>mh+usene...@zugschl.us (Marc Haber) am 21.09.19 um 17:01:
>> Woran kann das liegen?
>
>Übertakten? Oder passiert das auch bei unkritischen Änderungen?

Das beschriebene Verhalten tritt auch dann auf, wen man den Menüpunkt
"Save and Exit" auswählt, ohne vorher _irgendwas_ geändert zu haben.

[Marc Haber]

"Thomas Krenzel ." <thurga...@gmx.de> wrote:

>On 21.09.2019 17:01, Marc Haber wrote:
>
>> mein neues Mainboard ist ein Asrock B450 Pro 4 mit aktueller Firmware
>> 3.60.
>
>Selbst geflasht?

Nein.

> BIOS 3.50 2
>* Please install "AMD all in 1 with VGA driver ver:18.50.16.01_WHQL" or
>a later version before updating to this BIOS.

Nicht relevant, der Rechner läuft nicht unter Windows.

>** If you updated the BIOS before updating the AMD all in one driver,
>please refer to the Display recovery SOP to recover your system.
>*** User will not able to flash previous BIOS once upgrading to this
>BIOS version.
>**** If the current BIOS version is older than P1.80, please update BIOS
>to P1.80(PinnaclePI-AM4_1.0.0.6) before updating this version.

Ebenso nicht relevant.

[Rainer Knaepper]

mh+usene...@zugschl.us (Marc Haber) am 22.09.19 um 11:22:

> Rainer Knaepper <rai...@smial.prima.de> wrote:
>> mh+usene...@zugschl.us (Marc Haber) am 21.09.19 um 17:01:
>>> Woran kann das liegen?
>>
>> Übertakten? Oder passiert das auch bei unkritischen Änderungen?

> Das beschriebene Verhalten tritt auch dann auf, wen man den
> Menüpunkt "Save and Exit" auswählt, ohne vorher _irgendwas_
> geändert zu haben.

Ups. Das sollte nicht so sein.

Der Prozessor wird vom Bios/Uefi unterstützt und steht in der
Kompatibilitätsliste? Auch der Speicher ist in der Kombination vom
Hersteller getestet?

Rainer

--
Darüber hinaus ist er Österreicher (spricht also Deutsch)
(Der Rotstift in: z-netz.alt.esoterik)

[Thomas Krenzel .]

On 22.09.2019 11:21, Marc Haber wrote:
> "Thomas Krenzel ." <thurga...@gmx.de> wrote:
>> On 21.09.2019 17:01, Marc Haber wrote:

> Was möchtest Du mir sagen?

Bleib mal bitte locker.

> Ja, das war der Zustand beim ersten Versuch.

>> Da ist keine Zauberei, sondern Handwerk mit notwendig sauberer
>> Arbeitsweise vonnöten.

> Etwas weniger Arroganz fände ich fein.

Ja alles klaro. Versuchs mal so zu verstehen: Es ist gut bei einer
Problemanalyse strukturiert vorzugehen, wenn Du das alles schon machst,
dann liegt es nicht an mir das ich das nicht weiss.

Du hast gefragt.

Thomas

[Marc Haber]

Rainer Knaepper <rai...@smial.prima.de> wrote:
>mh+usene...@zugschl.us (Marc Haber) am 22.09.19 um 11:22:
>
>> Rainer Knaepper <rai...@smial.prima.de> wrote:
>>> mh+usene...@zugschl.us (Marc Haber) am 21.09.19 um 17:01:
>>>> Woran kann das liegen?
>>>
>>> Übertakten? Oder passiert das auch bei unkritischen Änderungen?
>
>> Das beschriebene Verhalten tritt auch dann auf, wen man den
>> Menüpunkt "Save and Exit" auswählt, ohne vorher _irgendwas_
>> geändert zu haben.
>
>Ups. Das sollte nicht so sein.
>
>Der Prozessor wird vom Bios/Uefi unterstützt und steht in der
>Kompatibilitätsliste? Auch der Speicher ist in der Kombination vom
>Hersteller getestet?

Der Rechner läuft sobald das OS gestartet hat völlig unauffällig

[Rainer Knaepper]

mh+usene...@zugschl.us (Marc Haber) am 22.09.19:

> Rainer Knaepper <rai...@smial.prima.de> wrote:

>> Der Prozessor wird vom Bios/Uefi unterstützt und steht in der
>> Kompatibilitätsliste? Auch der Speicher ist in der Kombination vom
>> Hersteller getestet?

> Der Rechner läuft sobald das OS gestartet hat völlig unauffällig

Danach fragte ich nicht.

Rainer

--
>scsi hat einfach nicht das richtige preis/leistungsverhaeltnis.
Ja, das Argument kommt immer, weil es das einzige pro IDE ist,
was stimmt.
(Juergen Thorweger in de.comp.hardware.cpu+mainboard.intel)

[Frank Möller]

Marc Haber schrieb:

> Rainer Knaepper <rai...@smial.prima.de> wrote:

>> Der Prozessor wird vom Bios/Uefi unterstützt und steht in der
>> Kompatibilitätsliste? Auch der Speicher ist in der Kombination vom
>> Hersteller getestet?

> Der Rechner läuft sobald das OS gestartet hat völlig unauffällig

1. beantwortet das nicht Rainers Frage.
2. hat man schon erlebt, daß ein OS "merkwürdige" BIOS-Einstellungen
"korrigiert", sobald das OS erst einmal aktiv ist (aber vorher eben
nicht).
3. ist ein BIOS-Update Pflicht, wenn es eines gibt, weil ein BIOS-Update
Pflicht ist, denn ein BIOS-Update, das es gibt, ist Pflicht...
4. Pferde vor der Apotheke...

--

[Marc Haber]

Frank Möller <butterspiege...@protonmail.com> wrote:
>Marc Haber schrieb:
>> Rainer Knaepper <rai...@smial.prima.de> wrote:
>
>>> Der Prozessor wird vom Bios/Uefi unterstützt und steht in der
>>> Kompatibilitätsliste? Auch der Speicher ist in der Kombination vom
>>> Hersteller getestet?
>
>> Der Rechner läuft sobald das OS gestartet hat völlig unauffällig
>
>1. beantwortet das nicht Rainers Frage.

Es macht sie aber unsinnig.

>2. hat man schon erlebt, daß ein OS "merkwürdige" BIOS-Einstellungen
> "korrigiert", sobald das OS erst einmal aktiv ist (aber vorher eben
> nicht).

Linux tut das nicht.

>3. ist ein BIOS-Update Pflicht, wenn es eines gibt, weil ein BIOS-Update
> Pflicht ist, denn ein BIOS-Update, das es gibt, ist Pflicht...

Die aktuelle UEFI-Firmware ist installiert, und wenn sie das nicht
wäre, sagt der Hersteller, dass man keine Updates durchführen soll,
wenn man keine der Dinge erleidet, die das Update fixt.

>4. Pferde vor der Apotheke...

Kenne ich.

[Rainer Knaepper]

mh+usene...@zugschl.us (Marc Haber) am 23.09.19:

> Frank Möller <butterspiege...@protonmail.com> wrote:
>> Marc Haber schrieb:
>>> Rainer Knaepper <rai...@smial.prima.de> wrote:
>>
>>>> Der Prozessor wird vom Bios/Uefi unterstützt und steht in der
>>>> Kompatibilitätsliste? Auch der Speicher ist in der Kombination
>>>> vom Hersteller getestet?
>>
>>> Der Rechner läuft sobald das OS gestartet hat völlig unauffällig
>>
>> 1. beantwortet das nicht Rainers Frage.

> Es macht sie aber unsinnig.

>> 2. hat man schon erlebt, daß ein OS "merkwürdige"
>> BIOS-Einstellungen "korrigiert", sobald das OS erst einmal aktiv
>> ist (aber vorher eben nicht).

> Linux tut das nicht.

Linux unterstützt kein UEFI?

Rainer

--
Halber vier, Kaulquapp,
und die Männer haben noch keinen Strick getan.

[Marc Haber]

Rainer Knaepper <rai...@smial.prima.de> wrote:
>mh+usene...@zugschl.us (Marc Haber) am 23.09.19:

>>> 2. hat man schon erlebt, daß ein OS "merkwürdige"
>>> BIOS-Einstellungen "korrigiert", sobald das OS erst einmal aktiv
>>> ist (aber vorher eben nicht).
>
>> Linux tut das nicht.
>
>Linux unterstützt kein UEFI?

Linux korrigiert keine merkwürdigen Einstellungen der UEFI-Firmware.

Du möchtest nicht helfen, sondern nur trollen.

[Frank Möller]

Marc Haber schrieb:

> Rainer Knaepper <rai...@smial.prima.de> wrote:
>> mh+usene...@zugschl.us (Marc Haber) am 23.09.19:

>>>> 2. hat man schon erlebt, daß ein OS "merkwürdige"
>>>> BIOS-Einstellungen "korrigiert", sobald das OS erst einmal aktiv
>>>> ist (aber vorher eben nicht).

>>> Linux tut das nicht.

>> Linux unterstützt kein UEFI?

> Linux korrigiert keine merkwürdigen Einstellungen der UEFI-Firmware.

Nun ja, wir sind z. B. bei Datenträgern mittlerweile im Zeitalter von 32
TB. Sollte ein BIOS nicht in der Lage sein, so ein Volume richtig zu
erkennen, so ist es unter Windows doch meist so, daß so ein Teil dennoch
erkannt und eingebunden wird.

Und Linux weigert sich dann beharrlich, so ein Volume zu erkennen und zu
mounten, wenn das BIOS das nicht oder nicht richtig tut? Das wäre schon
eine seltsame Art von Rückständigkeit, an die ich nicht so recht glauben
mag, noch dazu vor dem Hintergrund, daß die HW-Erkennung von Linux immer
so gerühmnt wird...

--

[Rainer Knaepper]

mh+usene...@zugschl.us (Marc Haber) am 25.09.19:

> Rainer Knaepper <rai...@smial.prima.de> wrote:
>> mh+usene...@zugschl.us (Marc Haber) am 23.09.19:
>>>> 2. hat man schon erlebt, daß ein OS "merkwürdige"
>>>> BIOS-Einstellungen "korrigiert", sobald das OS erst einmal
>>>> aktiv ist (aber vorher eben nicht).
>>
>>> Linux tut das nicht.
>>
>> Linux unterstützt kein UEFI?

> Linux korrigiert keine merkwürdigen Einstellungen der
> UEFI-Firmware.

Windows ersetzt bei entsprechender Konfiguration sehr wohl Funktionen
des UEFI, insbesondere seit Win10. Das ist allgemein bekannt. Da ich
keine Ahnung von Linux habe, zielte meine Frage in diese Richtung.

> Du möchtest nicht helfen, sondern nur trollen.

Ich habe dreimal höchst konkrete Fragen gestellt und jeweils keine
zielführenden Antworten von dir bekommen. Wer genau trollt hier?


Rainer

--
> Und wenn ich erzähle, dass ich einen Seat Cordoba Vario fahre, dann
> ernte ich sowieso nur verständnislose Blicke ;-)
Kenne ich auch nicht, der Name klingt wie ein Staubsauger...
(Will Berghoff in de.rec.modelle.bahn)

[Michael Kreienberg]

Hallo,

Am 21.09.2019 um 17:01 schrieb Marc Haber:
> mein neues Mainboard ist ein Asrock B450 Pro 4 mit aktueller Firmware
> 3.60. Sobald ich im Setup der UEFI-Firmware ("BIOS-Setup") die
> Einstellungen speichere, wird der Bildschirm schwarz, die Lüfter
> drehen hoch und es tut sich nichts mehr. Ich habe das System auch mal
> in diesem Zustand eine halbe Stunde stehen lassen, da tut sich nichts.

als neugieriger Mensch: Haste für das Problem eine Lösung gefunden?

Mittlerweile gibt es für das Mainboard ASRock B450 Pro 4 die
BIOS-Version 3.90, siehe hier:
https://www.asrock.com/MB/AMD/B450%20Pro4/index.asp#BIOS .

Wenn es etwas mit Red Hat Bugzilla-Bug 1608242 zu tun hat, vgl.
https://bugzilla.redhat.com/show_bug.cgi?id=1608242 ,

dann könnte vorgenanntes Firmwareupdate die Lösung sein, vgl.
http://forum.asrock.com/forum_posts.asp?TID=13195&OB=DESC :
"And now it has returned, just successfully flashed onto board with
Ryzen 3600! I can confirm it eliminated the PSP initialization bug that
caused the CCP to get disabled in Linux."

Viel Erfolg, schöne Festtage.

Viele Grüße
Michael Kreienberg

[Marc Haber]

Michael Kreienberg <kre...@gmx.de> wrote:
>Am 21.09.2019 um 17:01 schrieb Marc Haber:
>> mein neues Mainboard ist ein Asrock B450 Pro 4 mit aktueller Firmware
>> 3.60. Sobald ich im Setup der UEFI-Firmware ("BIOS-Setup") die
>> Einstellungen speichere, wird der Bildschirm schwarz, die Lüfter
>> drehen hoch und es tut sich nichts mehr. Ich habe das System auch mal
>> in diesem Zustand eine halbe Stunde stehen lassen, da tut sich nichts.
>
>als neugieriger Mensch: Haste für das Problem eine Lösung gefunden?

Ich hab das Board zurückgegeben und durch ein Asus mit X470 Chipsatz
ersetzt.

[Michael Kreienberg]

Hallo,

Am 25.12.2019 um 17:28 schrieb Marc Haber:
> Ich hab das Board zurückgegeben und durch ein Asus mit X470 Chipsatz
> ersetzt.

alles klar, besten Dank für die Rückmeldung.

Kleine Anekdote am Rande: Ich habe mind. zwölf Jahre das Mainboard Asus
TX97-E im Rechner gehabt und war sehr zufrieden damit. Dass für dieses
Board aus dem Jahr 1997 auch heute noch das Manual, Firmware und BIOS
zur Verfügung stehen spricht für den guten Support seitens des
Herstellers Asus, vgl.
https://www.asus.com/supportonly/TX97-E/HelpDesk_BIOS/

Deswegen ist ein Asus-Board ebenfalls eine gute Entscheidung, die
häufigen BIOS-Update-Zyklen sprechen auch dafür.

Viele Grüße
Michael Kreienberg

[Marc Haber]

Michael Kreienberg <kre...@gmx.de> wrote:
>Deswegen ist ein Asus-Board ebenfalls eine gute Entscheidung, die
>häufigen BIOS-Update-Zyklen sprechen auch dafür.

Ich wollte eigentlich ECC; und Asus gibt schon seit längerer zeit
keine Informationen mehr darüber, ob deren Produkte ECC-fähig sind,
wenn CPU, Chipsatz und RAM ECC-fähig sind. Asrock tut das, dafür
scheinen aber die Produkte andere Nachteile zu haben.

[Michael Kreienberg]

Hallo,

Am 26.12.2019 um 10:01 schrieb Marc Haber:
> Ich wollte eigentlich ECC; und Asus gibt schon seit längerer zeit
> keine Informationen mehr darüber, ob deren Produkte ECC-fähig sind,
> wenn CPU, Chipsatz und RAM ECC-fähig sind. Asrock tut das, dafür
> scheinen aber die Produkte andere Nachteile zu haben.

habe ich bei Asus so noch nicht feststellen können.

Bei Asus ist die ECC-Unterstützung bei den Workstation-Mainboards (also
WS-Serie für berufliche Anwender) Teil der Produktbeschreibung, siehe z.
B. hier:
https://www.asus.com/de/search/results.aspx?SearchKey=ECC

Bei den anderen, z. B. Gaming-Mainboards, findet sich diese Information
etwas versteckter in den Specs, z. B. hier:
https://www.asus.com/de/Motherboards/PRIME-X470-PRO/specifications/

Einen guten Überblick bieten die Suchfilter-Einstellungen der
Preisvergleichsplattform geizhals.de, da kannste nach ECC filtern, siehe
hier:
https://geizhals.de/?cat=mbam4&xf=494_ECC-Unterst%FCtzung%7E544_ASUS

Im Beispiel: Hersteller Asus, Sockel AM4 und ECC-Unterstützung.

Viele Grüße
Michael Kreienberg

[Frank Möller]

Marc Haber schrieb:

> Michael Kreienberg <kre...@gmx.de> wrote:

>> Deswegen ist ein Asus-Board ebenfalls eine gute Entscheidung, die
>> häufigen BIOS-Update-Zyklen sprechen auch dafür.

> Ich wollte eigentlich ECC; und Asus gibt schon seit längerer zeit
> keine Informationen mehr darüber, ob deren Produkte ECC-fähig sind,
> wenn CPU, Chipsatz und RAM ECC-fähig sind.

Das ist - wie auch Michael schon anmerkte - ganz schlicht komplett falsch.

--

[Marc Haber]

Michael Kreienberg <kre...@gmx.de> wrote:
>Einen guten Überblick bieten die Suchfilter-Einstellungen der
>Preisvergleichsplattform geizhals.de, da kannste nach ECC filtern, siehe
>hier:
>https://geizhals.de/?cat=mbam4&xf=494_ECC-Unterst%FCtzung%7E544_ASUS
>
>Im Beispiel: Hersteller Asus, Sockel AM4 und ECC-Unterstützung.

Richtig, da kam zu dem Zeitpunkt kein passendes Board bei raus, nur
das von Asrock, das ich letztlich gekauft habe.

Außerdem gibt es da (leider) einen Unterschied zwischen "offiziell
unterstützt" und "funktioniert".

[Marc Haber]

Eine Veröffentlichung auf Papier mit Ausgang in Taipeh finde ich
leider nicht ausreichend. Ich habe gesucht und nicht gefunden.

[Kay Martinen]

Am 28.12.2019 um 09:37 schrieb Marc Haber:
> Michael Kreienberg <kre...@gmx.de> wrote:
>> Einen guten Überblick bieten die Suchfilter-Einstellungen der
>> Preisvergleichsplattform geizhals.de, da kannste nach ECC filtern, siehe
>> hier:
>> https://geizhals.de/?cat=mbam4&xf=494_ECC-Unterst%FCtzung%7E544_ASUS
>>
>> Im Beispiel: Hersteller Asus, Sockel AM4 und ECC-Unterstützung.
>
> Richtig, da kam zu dem Zeitpunkt kein passendes Board bei raus, nur
> das von Asrock, das ich letztlich gekauft habe.

Ist das Board für einen Server gedacht gewesen Marc?

Wenn nicht und es ist ein Desktop/Workstation dann zweifele ich ob das
wirklich notwendig ist. ECC schützt doch nur gegen Ein-Bit fehler im RAM
und einen Desktop kann man immer neu starten wenn diese Fehler auf
Programme treffen. Bei Daten... nun wenn es Text ist sollte es einfach
sein die zu beheben.
Was nützt es da noch wenn ein Zwei-Bit Fehler gemeldet aber nicht
korrigiert wird, man müsste eh neu Booten oder den Speicher testen/ersetzen.

> Außerdem gibt es da (leider) einen Unterschied zwischen "offiziell
> unterstützt" und "funktioniert".

Hmm...
"Offiziell"=Hersteller garantiert das es funktioniert.
"funktioniert"=Hersteller sagt es geht, garantiert aber nicht dafür.

Willst du den Hersteller des Boards in Regress nehmen wenn dir ein
Bitfehler einen Reboot aufzwingt und ggf. das Reinigen von defekten
Daten? Dann müßtest du auch vom Hersteller zugelassenen Speicher
verwenden und auch dann sehe ich da keinen Grund zur Hoffnung.

ECC um des ECC-haben-wollens wegen kann's doch wohl kaum sein, oder
Marc? Ist es doch für einen Server der lange laufen soll?

Kay

--
Sent via SN (Eisfair-1)

[Frank Möller]

Kay Martinen schrieb:

> Ist das Board für einen Server gedacht gewesen Marc?

> Wenn nicht und es ist ein Desktop/Workstation dann zweifele ich ob das
> wirklich notwendig ist. ECC schützt doch nur gegen Ein-Bit fehler im RAM

Komplett falsch. Es werden 1-Bit-Fehler, 2-Bit-Fehler und Mehr-Bit-Fehler
erkannt. 1-Bit-Fehler werden automagisch korrigiert und es erfolgt ein
Log-Eintrag. 2-Bit-Fehler werden erkannt, es erfolgt ein Log-Eintrag und
die Maschine bleibt _*geordnet*_ stehen, statt unerkannte Schäden anrichten
zu können. Mehr-Bit-Fehler werden _*mehrheitlich*_ erkannt, sofern die
Prüfsumme nicht dummerweise suggeriert, daß es angeblich keinen Fehler gab.

Jetzt sollte man auch noch wissen, daß a) 99,99 % aller RAM-Bit-Fehler
1-Bit-Fehler sind, daß b) 2-Bit-Fehler praktisch _*nie*_ auftreten, ohne
daß zuvor reichlich 1-Bit-Fehler aufgetreten sind.

Wenn man nicht komplett gaga ist, wird es c) deshalb nie dazu kommen, daß
man "plötzlich aus heiterem Himmel" Mehr-Bit-Fehler hat, weil der
betreffende RAM dann nämlich schon längst getauscht wurde.

Deswegen hat man für den Fall von Mehr-Bit-Fehlern, bei denen die Prüfsumme
dummerweise keinen Fehler erkennen läßt, keine weiteren Maßnahmen
vorgesehen, weil das in der Praxis schlicht nicht vorkommt.

> und einen Desktop kann man immer neu starten wenn diese Fehler auf
> Programme treffen.

Von dieser Borniertheit lebt z. B. Intel sehr gut (die "Desktop"-CPUs
gazielt von ECC-Fähigkeit "befreien"). Müllionen von Idioten lassen sich
davon hinter's Licht führen und schieben's am Ende auch noch auf Windows.

> Bei Daten... nun wenn es Text ist sollte es einfach sein die zu beheben.

Chlor, z. B. bei Bilddateien, die dann nur aus Pixelmatsch bestehen (BTST),
geht man mal einfach mit dem Hexeditor hin und korrigiert das ganz lustig.

Wahrscheinlich tut Dir das noch nicht mal weh...

> Was nützt es da noch wenn ein Zwei-Bit Fehler gemeldet aber nicht
> korrigiert wird, man müsste eh neu Booten oder den Speicher testen/ersetzen.

Dann _*weiß*_ man erstens, daß man ein Problem hat. Man _*weiß*_ zweitens,
welches Problem es ist. Man _*weiß*_ drittens, wo das Problem herkommt. Man
_*weiß*_ viertens, daß man den verursachenden RAMsch dem Händler auf den
Tisch knallt. Und genau _*das*_ ist dann auch der Grund dafür, daß bei
ECC-RAM erst gar kein RAMsch verkauft wird.

<Harald_Lesch>
Sind Sie noch da?
</Harald_Lesch>

> ECC um des ECC-haben-wollens wegen kann's doch wohl kaum sein, oder
> Marc?

Chlor, ECC-RAM verwendet man nicht, weil einem seine Anwendungen, seine
Daten und die Systemstabilität was wert sind; das hat man nur zum Posen vor
der Eisdiele.

Es ist doch völlig egal, daß man ohne ECC a) nicht weiß, ob man RAM-Fehler
hatte oder nicht, sondern lediglich hoffen kann, daß bitte, bitte, bitte
noch nix "ernstes" passiert ist; und es ist b) auch völlig egal, daß man
dann, wenn man weiß, daß der RAM defekt ist, aber nicht den leisesten
Schimmer hat, was für Schäden eingetreten sind.

> Ist es doch für einen Server der lange laufen soll?

Was haben RAM-Fehler mir irgendeiner Uptime zu tun, Du Extremdurchblicker?

--

[Frank Möller]

Marc Haber schrieb:

Das mit dem Subjectwechsel solltest Du nochmal üben, denn "was:" gehört
kleingeschrieben, wenn normgerechtes NUAs das automagisch erkennen sollen.

> Frank Möller <butterspiege...@protonmail.com> wrote:
>> Marc Haber schrieb:
>>> Michael Kreienberg <kre...@gmx.de> wrote:

>>>> Deswegen ist ein Asus-Board ebenfalls eine gute Entscheidung, die
>>>> häufigen BIOS-Update-Zyklen sprechen auch dafür.

>>> Ich wollte eigentlich ECC; und Asus gibt schon seit längerer zeit
>>> keine Informationen mehr darüber, ob deren Produkte ECC-fähig sind,
>>> wenn CPU, Chipsatz und RAM ECC-fähig sind.

>> Das ist - wie auch Michael schon anmerkte - ganz schlicht komplett falsch.

> Eine Veröffentlichung auf Papier mit Ausgang in Taipeh finde ich
> leider nicht ausreichend. Ich habe gesucht und nicht gefunden.

Ich verwende seit etlichen Jahren a) nur noch ECC-fähige CPUs und b) Boards
mit ECC-Unterstützung, die c) allesamt von ASUS kamen. Und immer war das d)
in den Spezifikationen der Boards angegeben. Insofern würde ich mal sagen,
Du hast wohl nicht ganz richtig gesucht. ;-)

--

[Frank Möller]

Kay Martinen schrieb:

> Ist das Board für einen Server gedacht gewesen Marc?

> Wenn nicht und es ist ein Desktop/Workstation dann zweifele ich ob das
> wirklich notwendig ist. ECC schützt doch nur gegen Ein-Bit fehler im RAM

Komplett falsch. Es werden 1-Bit-Fehler, 2-Bit-Fehler und Mehr-Bit-Fehler
erkannt. 1-Bit-Fehler werden automagisch korrigiert und es erfolgt ein
Log-Eintrag. 2-Bit-Fehler werden erkannt, es erfolgt ein Log-Eintrag und
die Maschine bleibt _*geordnet*_ stehen, statt unerkannte Schäden
anrichten zu können. Mehr-Bit-Fehler werden _*mehrheitlich*_ erkannt,

sofern es nicht einer der seltenen Fälle ist, bei denen die Prüfsumme

dummerweise suggeriert, daß es angeblich keinen Fehler gab.

Jetzt sollte man allerdings auch noch wissen, daß a) 99,99 % aller

RAM-Bit-Fehler 1-Bit-Fehler sind, daß b) 2-Bit-Fehler praktisch _*nie*_
auftreten, ohne daß zuvor reichlich 1-Bit-Fehler aufgetreten sind.

Wenn man nicht komplett gaga ist, wird es c) deshalb nie dazu kommen, daß
man "plötzlich aus heiterem Himmel" Mehr-Bit-Fehler hat, weil der
betreffende RAM dann nämlich schon längst getauscht wurde.

Deswegen hat man für den Fall von jenen Mehr-Bit-Fehlern, bei denen die

Prüfsumme dummerweise keinen Fehler erkennen läßt, keine weiteren
Maßnahmen vorgesehen, weil das in der Praxis schlicht nicht vorkommt.

> und einen Desktop kann man immer neu starten wenn diese Fehler auf
> Programme treffen.

Von dieser Borniertheit lebt z. B. Intel sehr gut (die "Desktop"-CPUs

gezielt von ECC-Fähigkeit "befreien"). Müllionen von Idioten lassen sich

davon hinter's Licht führen und schieben's am Ende auch noch auf Windows.

> Bei Daten... nun wenn es Text ist sollte es einfach sein die zu beheben.

Chlor, z. B. bei Bilddateien, die dann nur aus Pixelmatsch bestehen (BTST),
geht man mal einfach mit dem Hexeditor hin und korrigiert das ganz lustig.

Wahrscheinlich tut Dir das noch nicht mal weh...

> Was nützt es da noch wenn ein Zwei-Bit Fehler gemeldet aber nicht
> korrigiert wird, man müsste eh neu Booten oder den Speicher testen/ersetzen.

Dann _*weiß*_ man erstens, daß man ein Problem hat. Man _*weiß*_ zweitens,
welches Problem es ist. Man _*weiß*_ drittens, wo das Problem herkommt. Man
_*weiß*_ viertens, daß man den verursachenden RAMsch dem Händler auf den
Tisch knallt. Und genau _*das*_ ist dann auch der Grund dafür, daß bei
ECC-RAM erst gar kein RAMsch verkauft wird.

Ohne ECC _*weiß*_ man _*nicht*_, ob der RAM i. O. ist. Man _*weiß*_ es
_*nicht*_.

<Harald_Lesch>
Sind Sie noch da?
</Harald_Lesch>

> ECC um des ECC-haben-wollens wegen kann's doch wohl kaum sein, oder
> Marc?

Chlor, ECC-RAM verwendet man nicht, weil einem seine Anwendungen, seine
Daten und die Systemstabilität was wert sind; das hat man nur zum Posen vor
der Eisdiele.

Es ist doch völlig egal, daß man ohne ECC a) nicht weiß, ob man RAM-Fehler
hatte oder nicht, sondern lediglich hoffen kann, daß bitte, bitte, bitte
noch nix "ernstes" passiert ist; und es ist b) auch völlig egal, daß man
dann, wenn man weiß, daß der RAM defekt ist, aber nicht den leisesten
Schimmer hat, was für Schäden eingetreten sind.

> Ist es doch für einen Server der lange laufen soll?

[Hermann Riemann]

Am 28.12.19 um 11:36 schrieb Kay Martinen:

> Wenn nicht und es ist ein Desktop/Workstation dann zweifele ich ob das
> wirklich notwendig ist.

Das hängt von den Ansprüchen ab.

> ECC schützt doch nur gegen Ein-Bit Fehler im RAM

Ein bit-Fehler werden korrigiert,
mehr bit Fehler meist erkannt.

> und einen Desktop kann man immer neu starten wenn diese Fehler auf
> Programme treffen.

Das "immer" ist falsch.
Ein Fehler in den Daten, wenn z.B. ein Buchstabe oder eine Zahl
sich ändert,
wird bei nicht ECC nicht bemerkt.
Ebenso wenig, wenn im Prgoramm z.B. ein update auf die Platte oder SDD
gespeichert ( oder geladen) wird.
Und es ist ein Glücksspiel was bei einem geänderten Programm passiert.
Eine Änderung von < auf <= kann eventuell erst nach einem Jahr überraschen.

> Bei Daten... nun wenn es Text ist sollte es einfach
> sein die zu beheben.

Nur wenn man es erkennt.
Wenn Du statt 1000 € 4100 überwiesen hast ..
Und nicht jeder Text im Speicher wird sofort gelesen.

> Was nützt es da noch wenn ein Zwei-Bit Fehler gemeldet aber nicht
> korrigiert wird, man müsste eh neu Booten oder den Speicher testen/ersetzen.

Statt FORMAT D: FORMAT C: wird unvergessen bleiben.

Hermann
der lieber 100 € mehr ausgibt,
als 20 Stunden Fehler zu suchen.

--
http://www.hermann-riemann.de

[Marc Haber]

Kay Martinen <k...@martinen.de> wrote:
>Am 28.12.2019 um 09:37 schrieb Marc Haber:
>> Michael Kreienberg <kre...@gmx.de> wrote:
>>> Einen guten Überblick bieten die Suchfilter-Einstellungen der
>>> Preisvergleichsplattform geizhals.de, da kannste nach ECC filtern, siehe
>>> hier:
>>> https://geizhals.de/?cat=mbam4&xf=494_ECC-Unterst%FCtzung%7E544_ASUS
>>>
>>> Im Beispiel: Hersteller Asus, Sockel AM4 und ECC-Unterstützung.
>>
>> Richtig, da kam zu dem Zeitpunkt kein passendes Board bei raus, nur
>> das von Asrock, das ich letztlich gekauft habe.
>
>Ist das Board für einen Server gedacht gewesen Marc?
>
>Wenn nicht und es ist ein Desktop/Workstation dann zweifele ich ob das
>wirklich notwendig ist. ECC schützt doch nur gegen Ein-Bit fehler im RAM
>und einen Desktop kann man immer neu starten wenn diese Fehler auf
>Programme treffen. Bei Daten... nun wenn es Text ist sollte es einfach
>sein die zu beheben.

Ich habe einmal ein Dateisystem gesehen von einem System, das eine
kaputte Speicherseite hatte, die immer Nullen zurückgeliefert hat,
unabhängig davon was man da hineingeschrieben hatte. Diese Seite lag
dann irgendwann mal im Plattencache. Von den Daten war da nicht mehr
viel übrig.

Auch im Vorgänger des aktuellen Systems konnte ein defektes
Speichermodul erkannt, isoliert und ohne Datenverlust gewechselt
werden.

>Was nützt es da noch wenn ein Zwei-Bit Fehler gemeldet aber nicht
>korrigiert wird, man müsste eh neu Booten oder den Speicher testen/ersetzen.

Aber die Daten sind danach wenigstens noch heil.

>> Außerdem gibt es da (leider) einen Unterschied zwischen "offiziell
>> unterstützt" und "funktioniert".
>
>Hmm...
>"Offiziell"=Hersteller garantiert das es funktioniert.
>"funktioniert"=Hersteller sagt es geht, garantiert aber nicht dafür.
>
>Willst du den Hersteller des Boards in Regress nehmen wenn dir ein
>Bitfehler einen Reboot aufzwingt und ggf. das Reinigen von defekten
>Daten? Dann müßtest du auch vom Hersteller zugelassenen Speicher
>verwenden und auch dann sehe ich da keinen Grund zur Hoffnung.

Du musst mir das nicht erklären.

>ECC um des ECC-haben-wollens wegen kann's doch wohl kaum sein, oder
>Marc? Ist es doch für einen Server der lange laufen soll?

Und wenn?