PC läuft stabil trotz Beep-Codes nach Aktivierung von ResizableBAR

[Hobby-Bastler]

1. Nenne uns bitte deine aktuelle Hardware:
(Bitte tatsächlich hier auflisten und nicht auf Signatur verweisen, da diese von einigen nicht gesehen wird und Hardware sich ändert)

• Prozessor (CPU): Ryzen 7 5800X3D
• Arbeitsspeicher (RAM): 2x 16GB Corsair Vengeance LPX 3200MHz CL16
• Mainboard: Asus ROG Strix B450-F Gaming (AMI BIOS, aktuelle Version 5003)
• Netzteil: bequiet! Straight Power 11 850W Gold
• Gehäuse: Fractal Design Define R5
• Grafikkarte: EVGA RTX 3080 FTW3 Ultra (526.98)
• HDD / SSD: SanDisk SSD Plus 240GB (keine M.2, normal SATA)

2. Beschreibe dein Problem. Je genauer und besser du dein Problem beschreibst, desto besser kann dir geholfen werden (zusätzliche Bilder könnten z. B. hilfreich sein):

Nach Aktivierung von ResizableBAR im BIOS erhalte ich bei jedem Starten den Standard POST-Beep und danach einen Beep-Code 1x lang 3x kurz. Das kuriose ist, dass der Computer nach dem vermeintlichen Fehler normal startet und auch absolut stabil und problemlos läuft. ResizableBAR ist laut GPU-Z aktiviert. Laut Beep-Code Tabelle wird ein Problem mit der Grafikkarte angezeigt.

3. Welche Schritte hast du bereits unternommen/versucht, um das Problem zu lösen und was hat es gebracht?

Naja im Grunde löst das Deaktivieren von ResizableBAR das Problem, aber das kann ja nicht des Rätsels Lösung sein. Derselbe Beep-Code wird auch gemeldet, wenn die Stromversorgung der Graka nicht angeschlossen ist.

Ich habe so eine Theorie: Durch aktivieren von rBAR wird auch der CSM-Support deaktiviert. Wenn ich rBAR deaktiviere, wird CSM-Support wieder aktiviert. Kann es sein, dass durch die Aktivierung von rBAR und somit die Deaktivierung des CSM-Supports der ganze Bootvorgang einfach "zu schnell" abläuft? Ich spinne mal rum und sage, dass das MB schon "durchbooten" will, aber die Stromversorgung für die Graka seitens Netzteil noch gar nicht voll da ist.

 

[Termy]

Deaktiviere doch testweise sowohl rBAR als auch CSM?
Wenn du eh im UEFI-Mode bootest macht CSM ja sowieso keinen Sinn und verlängert nur den Bootvorgang

 

[Alexander2]

verwirrtes Bios? hast du denn das aktuelle?

Ansonsten, wenn das halt sagt, es wäre ein problem mit der grafikkarte, du da aber keines hast also ICH würde das ggf. ignorieren. ist mir dann egal wenn die gpu mal was falsch rechnet, ich nutze die für keinerlei wichtige Berechnung, das mach die CPU bei mir. die GPU ist in der hauptsache bei spielen dann mehr beschäftigt, aber da wäre nen abschmierer nicht so schlimm. wenn der käme, dann würde ich mcih darum kümmern.

Ergänzung (25. März 2023)

für die Graka seitens Netzteil noch gar nicht voll da ist.

Das hört sich nciht besonders warscheinlich an, das Netzteil dürfte dann auch für das Meinboard noch probleme haben die spanmnunf bereit zu stellen. beim cpu sinds ja auch 12v, die da anstehen an dem 4 oder 8 pin.

machen graka einen selbstchek? bestimmt ... vielleicht dauert der in einem der modi länger.

Edit:
und csm will man heute iegentlich nicht mehr nutzen, jedes halbwegs aktuelle os ist auf uefi ausgelegt. Und mir sind schon bugs untergekommen, die nur csm betreffen. ist halt eigentlich out of service

 

[Tatortreiniger]

Ich spinne mal rum und sage, dass das MB schon "durchbooten" will, aber die Stromversorgung für die Graka seitens Netzteil noch gar nicht voll da ist.

Nee, dann schon eher:
Die 3080 hat aber ein vbios update bekommen, damit rbar funktioniert? Das braucht sie nämlich lt nvidia, updates gibts beim Hersteller. (Und ist auch bei anderen Herstellen so). Bzw. kommt vermutlich auf das Produktionsdatum an, ob es konkret bei Deiner Karte nötig ist. Der rbar support wurde nachgereicht.

 

[joel]

Sieht das bei dir so aus?

 

[Hobby-Bastler]

Deaktiviere doch testweise sowohl rBAR als auch CSM?

Mit deaktiviertem CSM und deaktiviertem rBAR keine Beep-Codes mehr. Wobei mir aufgefallen ist, dass das Mainboard beim Deaktivieren von rBAR nur eine Sache explizit deaktiviert und das ist "Above 4G Decode".

hast du denn das aktuelle?

Jawohl, kürzlich erst die aktuellste Version (Februar 2023) aufgespielt.

machen graka einen selbstchek? bestimmt ... vielleicht dauert der in einem der modi länger.

Kann schon sein. Würde dazu passen, dass das UEFI bootet, die Beep-Codes kommen und der PC eigentlich schon hochgefahren ist, aber der Monitor noch gar kein Bild zeigt. Wenn der Monitor angeht (verbunden über DP1.2) sehe ich schon den Anmeldebildschirm von Windows. Also Windows ist schneller da als das Bild.

kommt vermutlich auf das Produktionsdatum an, ob es konkret bei Deiner Karte nötig ist

Ich habe die Karte vor nicht allzu langer Zeit direkt von EVGA geliefert bekommen, mit aktuellem bzw. für rBAR passenden VBIOS. Das zeigt mir PrecisionX auch an. Ein neueres VBIOS gibt es nicht.

Sieht das bei dir so aus?

Sieht bei mir genauso aus, nur werden andere BAR Sizes angezeigt:
BAR0 = 16MB
BAR1 = 16384MB
BAR2 = 32MB

ein problem mit der grafikkarte, du da aber keines hast also ICH würde das ggf. ignorieren

Mache ich momentan so. Aber sollte doch eine Ursache haben.

Wenn ich mir die konkreten BIOS Einstellungen anschaue, kann es ja nur mit diesem "Above 4G Decode" zusammenhängen. Zumindest hängt es nicht am CSM.

 

[Alexander2]

Also Windows ist schneller da als das Bild.

Das ist jedenfalls normal und kein grund zum Piepen, ist bei mir auch so mit Linux, erst sehe ich das Bios (wenn/falls der Monitor zu passenden Zeit eingeschaltet wurde - sonst auch nicht) , dann schaltet der Monitor um ist erstmal dunkel, bis der countdown vom Linux Startmenü schon fast abgelaufen ist wird erst wieder das Bild gezeigt.

Das hängt auch mit vom Monitor ab. Manche sind Flinker bei solchen Auflösungswecheln oder umstellungen.

 

[Luftgucker]

Bringts denn was bei Benchmarks z.B. im 3DMark, FH5, AC Valhalla?. Vermutlich schlägt der erste INIT fehl und es geht dann nur weiter mit (langsameren?) Kompatibilitätseinstellungen.

 

[Hobby-Bastler]

Das hängt auch mit vom Monitor ab. Manche sind Flinker bei solchen Auflösungswecheln oder umstellungen.

Wobei es mit deaktiviertem rBAR nicht zu diesem Phänomen kommt. Kann aber einfach daran liegen, dass die GPU dann später "reinkommt".

Bringts denn was bei Benchmarks

Guter Tipp, danke! Liegt zwar auf der Hand aber gebencht hab ich das noch gar nicht. Habs mal eben in Cyberpunk gemacht.

Avg. FPS = 92,94 OHNE vs 97,68 MIT
Min. FPS = 17,33 OHNE vs 16,63 MIT
Max. FPS = 114,37 OHNE vs 121,22 MIT
Berechnete Bilder = 5971 OHNE vs 6276 MIT

Da ist definitiv ein Unterschied messbar, also scheint es zu funktionieren.

Wenn ich mir die konkreten BIOS Einstellungen anschaue, kann es ja nur mit diesem "Above 4G Decode" zusammenhängen.

Das muss ich revidieren. Es hängt definitiv nur am rBAR. Wenn ich rBAR abschalte, aber diese 4G anlasse, gehts auch ohne Beep-Codes.

Wird wohl darauf hinauslaufen, dass ich mich damit abfinden muss, oder rBAR eben abschalte. Mal sehen, ob hier jemand eine zündende Idee hat.

 

[Luftgucker]

Clear CMOS schon gemacht?

 

[Alexander2]

hattest du denn jetzt auch mit dem genannten Tool macl geschaut ob die Karte eine der ist, die das schon kann?
Bei Nvidia gabs ja doch welche, die das nicht ab Händlerregal konnten. #5

 

[Hobby-Bastler]

Clear CMOS schon gemacht?

Ja zweimal. Einmal nach der Umstellung auf rBAR und dann im Zuge eines CPU Upgrades musste ich ohnehin ein neues BIOS flashen. Beides mal ohne Verbesserung.

hattest du denn jetzt auch mit dem genannten Tool macl geschaut ob die Karte eine der ist, die das schon kann?

Siehe Post #6: Karte kam von EVGA mit aktuellstem, rBAR tauglichen VBIOS; es gibt auch kein aktuelleres.

Ich habe aber andere Neuigkeiten: Mehr durch Zufall habe ich festgestellt, dass das Phänomen nur auftritt, wenn die Karte via DisplayPort Kabel verbunden ist. Ich hatte den PC die Tage mal via HDMI am TV angeschlossen und siehe da, keine BeepCodes mehr.

Hilft mir jetzt auch nicht weiter, aber grenzt das ganze noch weiter ein.

Edith: Wenn ich den Monitor (Asus PG329Q) via HDMI verbinde, ist der Fehler auch weg. Schalte ich dann den PC ein, geht der Monitor sofort an und ich sehe den POST, der Monitor bleibt an und der PC bootet ganz normal. Bei Verbindung via DP geht der Monitor an, und kurz danach in den Standby-Modus, dann kommt der BeepCode und nach ca. 5 Sekunden bekommt der Monitor wieder ein Eingangssignal; bis dahin ist Windows aber schon durchgebootet.

 

[cryps5]

Evtl hast du ein billiges DP-Kabel erwischt (teilweise legen das die Hersteller auch bei, leider)? Pin-20 Problem

Du könntest mal testweise eins mit VESA Zertifizierung kaufen, oder die Pins testen, wenn du dafür das Werkzeug zur Hand hast