[Sammelthread] Gigabyte MC12-LE0 (AM4, B550, servertauglich: IPMI, Dual Lan, ECC)

eehm · 21.08.2024

Gemütlich4S schrieb:
Mehr Sorgen würde ich mir machen, dass die allermeisten SATA-SSDs noch mit alter, nicht ganz so langlebiger Speichertechnik arbeiten, von daher dürften sie nicht so lange halten. Und sie sind insofern einfach sehr teuer im Vergleich.

Wenn es geht, würde ich NVMe bevorzugen.

Danke euch zwei. Dann wäre das auch eine Option auf dem Board.
Ja bei ZFS in einem Mirror hab ich schon Erfahrung mit Consumer SSDs.
Wegen den Sync-Writes war das am Ende eine Katastrophe.
Hier gibt es für mich nur noch hochwertige Enterprise mit PLP.

Beitrag automatisch zusammengeführt: 21.08.2024

Ob es durch die heute viele schnelleren Consumer SSDs besser ist weiß ich nicht. Test ist gut 3 Jahre her.

BobbyD · 21.08.2024

Gemütlich4S schrieb:
und das brauchen wir von einer 990 Pro oder eine 760NM nicht gegen eine MX500 vergleichen.

Gemütlich4S schrieb:
dass die allermeisten SATA-SSDs noch mit alter, nicht ganz so langlebiger Speichertechnik arbeiten, von daher dürften sie nicht so lange halten.

Wie kommst Du auf so was, einfach mal ausgedacht?

eehm · 21.08.2024

Ich habe jetzt gestern Mal die weiteren Teile für meinen neuen Server in einer Tabelle erfasst.
Erschreckend war, dass RAM, CPU doch ordentlich zu Buche schlagen für eine „alte“ Plattform.

Hat sich jemand ggf. auch überlegt gleich auf AM5 mit z.B. dem Asus Pro B650M-CT-CSM zu gehen.
ECC RAM ist nicht viel teuere und CPUs (APU) mit mehr als 6 Kernen viel günstiger.
Sind hier am Ende mehr Nachteile als nur kein IPMI?

Haldi · 21.08.2024

Scheiss auf IPMI wenn du für 30$ NanoKVM bekommst...

MrWahoo · 21.08.2024

eehm schrieb:
Hat sich jemand ggf. auch überlegt gleich auf AM5 mit z.B. dem Asus Pro B650M-CT-CSM zu gehen.

Ja, das Board hatte ich auch schon angeschaut. Finde ich auch eine spannende Variante, muss ich sagen.

c0l0 · 21.08.2024

Haldi schrieb:
Scheiss auf IPMI wenn du für 30$ NanoKVM bekommst...

IPMI und OOB-Management via BMC ist halt doch nochmal deutlich mehr als iKVM.

BobbyD · 21.08.2024

Haldi schrieb:
Scheiss auf IPMI wenn du für 30$ NanoKVM bekommst...

Verbrauch wäre interessant.

Gemütlich4S · 21.08.2024

BobbyD schrieb:
Wie kommst Du auf so was, einfach mal ausgedacht?

Natürlich nicht. Natürlich bekommt man auch halbwegs aktuelle Technik, da schrieb ich ja: "relativ teuer".

Modelle wie die MX500 haben bereits 7-8 Jahre auf dem Buckel. Ja, ich weiß, davon hat es auch ein refreshtes 4TB-Modell im Programm. Kostet aber wie eine 990 Pro mit 4TB knapp 300 Euro. IOPS ist der relevanteste Aspekt - ich kenne kein SATA-Produkt, was konkurrenzfähig zur guten NVMe-Palette wäre.

Man muss auch bedenken: Kontext dieses Threads ist ein Board für knapp 40 Euro inkl. Versand. Von daher habe ich auch industrial SATA-SSDs nicht betrachtet.

eehm · 21.08.2024

MrWahoo schrieb:
Ja, das Board hatte ich auch schon angeschaut. Finde ich auch eine spannende Variante, muss ich sagen.

Du hast dich am Ende dann für AM4 entschieden, weil du wahrscheinlich noch alte HW hattest die du weiterverwenden konntest?
Hast wahrscheinlich nicht alles neu gekauft, wie wahrscheinlich die meisten hier?

pwnbert · 21.08.2024

eehm schrieb:
Hat hier jemand seinen Storage für die VMs aus SATA-SSDs realisiert und kann was zur Performance sagen.
Die maximale Datenrate im Vergleich zu NVME ist natürlich viel schlechter, aber in der Praxis kleine Dateien sollten genauso schnell sein. Somit als VM Storage ggf. in Ordnung.
Richtig oder seht ihr das anders und für VM Storage nur NVME?

"VM" ist ein dehnbarer Begriff.
Du solltest deine Frage schon geanuer formulieren, sonst bekommst auch entsprechend ungenaue Antworten.

Meine ungenaue Antwort: SATA wird allemal reichen.

MrWahoo · 21.08.2024

eehm schrieb:
Du hast dich am Ende dann für AM4 entschieden, weil du wahrscheinlich noch alte HW hattest die du weiterverwenden konntest?
Hast wahrscheinlich nicht alles neu gekauft, wie wahrscheinlich die meisten hier?

Nein, weder noch.
Für mich ist das sinnigste, das Gigabyte MJ11-EC1 zu verwenden, denn da habe ich alles da - inklusive sehr günstigem RAM und passendes Gehäuse. Einzig was mich etwas ärgert sind die geringen Erweiterungsmöglichkeiten. Ein AM5-System wäre da sehr reizvoll, aber realistisch eher in der Kategorie "Spielerei" für mich zu sehen.
Ende des Jahres steht ein Umzug an und vielleicht auch eine Erweiterung des HomeServers, vielleicht wird's dann nochmal spannend :xmas:

BobbyD · 21.08.2024

Neues BIOS F15:

1) Updated to AGESA 1.2.0.Ca.
2) Fixed LogoFAIL Vulnerability.
3) Fixed PixieFAIL Vulnerability.

Edit: Hab den Eindruck, dass unter Windows SecureBoot nicht mehr funktioniert. Vielleicht habe ich es auch nur nicht hart genug versucht. 😉

Gemütlich4S · 21.08.2024

pwnbert schrieb:
Meine ungenaue Antwort: SATA wird allemal reichen.

falls mein eigenes Geschrieb zu Verwirrung geführt haben sollte - der Meinung würde ich mich anschließen, wenn das SATA-Zeugs schon da ist oder günstig kommen kann.

BoredOperator · 21.08.2024

BobbyD schrieb:
Neues BIOS F15:

Haben dadurch die APUs nun "offiziellen" Support?

ebniv · 21.08.2024

BobbyD schrieb:
Neues BIOS F15:

Edit: Hab den Eindruck, dass unter Windows SecureBoot nicht mehr funktioniert. Vielleicht habe ich es auch nur nicht hart genug versucht. 😉

Ich fühle mich schon wie ein Fanboy, so wie ich mich freue

BoredOperator schrieb:
Haben dadurch die APUs nun "offiziellen" Support?

Laut den Releasenotes war da schon etwas seit F8, aber ob das gleichzusetzen mit "offzieller Support" ist? Nach Lesart würde ich eigentlich sagen, dass ja. Wie denkt ihr dazu?

Haldi · 21.08.2024

c0l0 schrieb:
IPMI und OOB-Management via BMC ist halt doch nochmal deutlich mehr als iKVM.

Joa... Aber benötigt der HomeUser hier der sich ein Board für 35-100€ kauft das unbedingt? Welche Features sind denn da so wichtig?
Ist das nicht eher Enterprise level für 500-700€ baords?

BobbyD schrieb:
Verbrauch wäre interessant.

0.2A bei 5V via USB... Also 1W oder weniger.
Sag ich dir wenn ich ihn hab

USB Power Meter ist bereits vorhanden.

besterino · 21.08.2024

Ich hab ja gerade mal das dritte MC12-LE0-System mit nem 5600G zusammen gestöpselt und liege da im idle bei insgesamt 18W (430W ATX Power Supply, eine SATA-SSD, ein Ram-Riegel - sonst nüschts drin&dran). OS ist allerdings Windows 11.

c0l0 · 22.08.2024

Haldi schrieb:
Joa... Aber benötigt der HomeUser hier der sich ein Board für 35-100€ kauft das unbedingt? Welche Features sind denn da so wichtig?
Ist das nicht eher Enterprise level für 500-700€ baords?

Was einem wichtig ist, ist glaube ich ziemlich individuell

Ich wollte nur das Gleichsetzen von iKVM und IPMI torpedieren, weil das "ich kann den PC bedienen, als wuerde ich gerade vor ihm sitzen"-Feature vielleicht fuer viele Leute den obersten, offensichtlichsten Nutzen von OOB-Management via IPMI darstellt, aber es damit halt nicht getan ist. Ich finde es z. B. sehr Hilfreich ein System Event Log (SEL) zu haben, das mir unabhaengig vom Host-OS ein Tagebuch ueber ggf. bedenkliche Ereignisse (Komponenten-Fehler im Betrieb, unerwartete Reboots/Power Cuts, etc.) bietet. Auch dass ich die gesamte Sensorik des Hosts via IPMI auslesen kann, das Host-BIOS-ROM flashen, die Host-POST-Codes interpretieren... das sind alles Features, die schnell einmal wichtig (oder zumindest sehr praktisch) werden koennen, die man mit so einer PiKVM-artigen Dranstoepsel-Loesung prinzipbedingt kaum kriegen kann.

wddn · 22.08.2024

pwnbert schrieb:
Bin mir nicht sicher, ob die 16 wirklich reichen, und Raid 1 ist schon recht paranoid für TNS boot ...

Reicht 😁

Muss mal von F14 auf F15 updaten

ebniv · 22.08.2024

wddn schrieb:
Muss mal von F14 auf F15 updaten

Ich habe es noch nicht einmal auf F14 geschafft

Auf F14 soll das mit der APU/iGPU ja angeblich bereits besser laufen. Falls jemand das nochmal auf F15 testet:
Gerne berichten!

besterino · 22.08.2024

Ach cool, F15 ist ja sogar eine offizielle Version (vom 20. August 2024).

wddn · 22.08.2024

ebniv schrieb:
Ich habe es noch nicht einmal auf F14 geschafft

Auf F14 soll das mit der APU/iGPU ja angeblich bereits besser laufen. Falls jemand das nochmal auf F15 testet:
Gerne berichten!

Nur mit F14 hat die iGPU bisher ueberhaupt funktioniert...

BobbyD · 22.08.2024

Die Optionen dafür sind auf jeden Fall noch da, konnte es aber wegen mangelnder iGPU nicht testen.

besterino · 22.08.2024

Wie testet man denn überhaupt die Funktion? Bildausgabe bekommste ja eh nur über die AST-Grafik.

ebniv · 22.08.2024

wddn schrieb:
Nur mit F14 hat die iGPU bisher ueberhaupt funktioniert...

"Überhaupt" ist doch besser als "nicht" :fresse2:

wddn · 22.08.2024

Gerade F15 installiert:

iGPU meines 4650G wird unter Linux (TrueNAS Scale) erkannt (UMA AUTO unter GFX configuration)
ansonsten nicht wirklich Neues im BIOS gefunden

ebniv · 22.08.2024

Gerade drüber gestolpert: Da verkauft einer neben RDIMM auch UDIMM ECC (2666) für 20€/16GB, ich denke ganz akzeptabler Preis aktuell:

Alle Anzeigen von Alex Veenhuis | Kleinanzeigen

Hier findest du alle Anzeigen von Alex Veenhuis

www.kleinanzeigen.de

Keine Garantie! Das Risiko ob das ein zuverlässiger Verkäufer ist muss jeder selbst wissen! Ich habe das in der Vergangenheit immer so gehandhabt meist "zu PayPalen" und nachgefragt ob die einen Memtest laufen lassen können. Und wenn nicht, wie es aussieht wenn bei meinem Test Fehler auftauchen.

c0l0 · 22.08.2024

Heute muss ich mir mal ein bisschen Frust von der Seele tippen hier :')

Wie sich manche erinnern, arbeite ich ja (ja, immer noch! bzw. in den letzten Tagen mit wiedererstarktem Eifer

) am Port von OpenBMC auf dieses Board. Die letzten paar Abende waren eigentlich gepraegt von schoenen Fortschritten. Ich hab mich auf die DeviceTree-/Kernel-Seite der OpenBMC-Firmware konzentriert und Userspace-Sachen (d. h. die Integration der Kernel-seitigen Features in das, was man via IPMI, Webinterace etc. ansprechen und so via OpenBMC als "User" bzw. Admin nutzen kann) auf die lange Bank geschoben. Das hat zu einigen kleinen Durchbruechen gefuehrt: Die I2C-Configs sind jetzt ofenbar soweit korrekt, dass ich fuer die Spannungs- und Temperatursensoren am Board nun (bei manchen mehr, bei manchen aber auch weniger

) sinnvolle Werte auslesen kann. Ich kann die PWM-Werte aller Fan-Header am Board via sysfs regeln. Ich kann die ID-LED des Board per sysfs an- und ausschalten. Alles notwendige Vorarbeit, um OpenBMC-Userspace so konfigurieren zu koennen, dass eine funktionstuechtige OpenBMC-Distro entstehen kann.

Dabei hat mich immer wieder geaergert, dass ich die Ethernet-Konfiguration weder in u-boot, noch in Linux 100% korrekt hinbekommen hatte - das hatte nervige Auswirkungen auf meinen Arbeitskomfort, weil die Bandbreite des Ethernet-Links durch irgendeine Unstimmigkeit in der Initialisierung des MII (oder vielleicht auch von NCSI - ich verstehe das alles leider nur zu ~10-20% ) ziemlich im Eimer - effektiv bei wenigen zig KByte/s - war. Also wollte ich das durch Trial und Error (mangels Board Schematics kenne ich keinen anderen Weg) fixen, und hab begonnen, unterschiedliche denkbare Kombinationen durchzuprobieren. Das hatte u. a. mal den Effekt, dass ich sowohl dem BMC als auch dem Host saemliches Ethernet-Schnittstellen permanent deaktiviert hatte - und mich lernen lassen, wie ich via XMODEM (den Namen/das Protokoll kannte ich zuvor nur aus Heldengeschichten von mir bekannten BBS-Altvorderen

) fette BLOBs mit viel Geduld ueber meine Debug-Konsole auf das BMC-Filesystem bekomme

Die letzte Kombination aus PHY-Configs, die ich gerade vorhin probiert habe, hat mich und meinen armen BMC aber leider in ein neues Gefaengnis gestubst, aus dem wir offenbar nicht mehr rauskommen koennen... u-boot initialisiert jetzt den AST2500 bis zum ersten Netzwerkinterface, und dann haengt sich die CPU in einem busy loop auf. Sieht so aus:

Code:

U-Boot 2019.04 (Jul 26 2024 - 07:18:46 +0000)

SOC : AST2500-A2
RST : WDT3 - Boot
RST : Power On
LPC Mode : SIO:Enable : SuperIO-2e
Eth : MAC0: RMII/NCSI, , MAC1: RGMII,
Model: Gigabyte MC12-LE0 u-boot
DRAM:  496 MiB (capacity:512 MiB, VGA:16 MiB, ECC:off)
MMC:
Loading Environment from SPI Flash... SF: Detected n25q512ax3 with page size 256 Bytes, erase size 4 KiB, total 64 MiB
*** Warning - bad CRC, using default environment

In:    serial@1e784000
Out:   serial@1e784000
Err:   serial@1e784000
Net:   ftgmac100_probe - NCSI detected

Dort haengt der BMC also ewig und tut nix mehr. Bloederweise ist das, NACHDEM u-boot die Mitigations fuer die Schwachstellen in der Host-BMC-Kommunikation durchgefuehrt hat - was bedeutet, dass ich den Chip mit der BMC-Firmware auch nicht via Host flashen kann.

Bleibt mir wohl nichts anderes uebrig, als zu versuchen, den n25q512ax3 mit der BMC-Firmware drauf per Flash-Programmer zu wipen (davon kann ich recovern, das hatte ich ja schon mal versehentlich geschafft :fresse2:

) bzw. den Chip gleich mit einem nicht-brickenden Image neu zu flashen.

Tja... und jetzt bin ich hier, und starre auf das Datenblatt des Chips, meine Debug-Klemme fuer den 16-Pin-Sockel, und male mir aus, was beim Rettungsversuch noch alles schiefgehen koennte. Sollte das alles nicht zu einem toedlichen Zimmerbrand fuehren, lest ihr vielleicht mal, wie (oder ob) es ausgegangen ist!

c0l0 · 22.08.2024

HAHAHAHA LEUTE, I SURE WAS DOWN, BUT I WAS NOT OUT!!!!

Kurzmoral von der Geschicht: Rumweinen bei Paul hilft, er hat einfach immer die besten Ideen

Langfassung: Stellt sich raus dass dem n25q512ax3 man durch Shorten der Pins #10 (VSS/Ground) und #15 (DQ0) verhindern kann, dass der Inhalt durch den BMC gelesen werden kann. Das hab ich nach ein bisschen Ratlosigkeit im Umgang mit der 16er-Klemme recht schnell geschaft gehabt, was dazu gefuehrt hat, dass der UART-Debug-Port trotz Power still geblieben ist. Das ist gut, weil so kann der AST2500 nicht die Instruktionen aus dem Flash lesen, die ihn unverwundbar gegenueber Angriff aus dem Hostsystem machen. Ein paar Minuten spaeter verliert der Host die Geduld beim Warten auf den BMC (das ist auch bei voellig zerstoertem Flash-Inhalt, also ohne BMC-Firmware, so der Fall) und faehrt auch hoch.

Leider hat sich schnell gezeigt, dass der BMC periodisch immer wieder versucht, vom Flash seine Firmware zu laden und zu booten - es war also nicht damit getan, ihn ein Mal am Beginn der Uptime am Booten zu hindern, sondern ich musste die Klemme mit den geshorteten Pins dranlassen.

In meinem so am Host gebooteten grml konnte ich aber immerhin mit culvert taetig werden. Ohne die Mitigations, die u-boot mitbringt, kann man da viel anstellen - mit `culvert probe` war klar, dass der AST2500 am Leben (und offen wie ein Scheunentor) ist:

Code:

root@grml /tmp # ./culvert probe
[*] failed to initialise devmem bridge: -1
[*] Accessing the BMC's AHB via the p2a bridge
debug:  Permissive
        Debug UART port: UART5
xdma:   Restricted
        BMC: Disabled
        VGA: Enabled
        XDMA on VGA: Enabled
        XDMA is constrained: Yes
p2a:    Permissive
        BMC: Disabled
        VGA: Enabled
        MMIO on VGA: Enabled
        [0x00000000 - 0x0fffffff]   Firmware: Writable
        [0x10000000 - 0x1fffffff]     SoC IO: Writable
        [0x20000000 - 0x2fffffff]  BMC Flash: Writable
        [0x30000000 - 0x3fffffff] Host Flash: Writable
        [0x40000000 - 0x5fffffff]   Reserved: Writable
        [0x60000000 - 0x7fffffff]   LPC Host: Writable
        [0x80000000 - 0xffffffff]       DRAM: Writable
ilpc:   Permissive
        SuperIO address: 0x2e

... aber das Flashen eines korrigierten OpenBMC-Images sollte (wegen des Pin-Short-Tricks, mit dem ich den Zugriff auf den Flash verhindert hatte) ein Problem darstellen. In diesem Zustand konnte die von culvert verwendete libflash nicht einmal ermitteln, welcher Baustein da am SPI sitzt und gelesen oder beschrieben werden koennte.

Die Theorie war nun, dass ich mit einem schnellen Loop aus `culvert firmware write < myimagefile` vielleicht nach Abziehen der Bruecke ueber die Pins eine vermutete Race Condition zwischen dem AST2500-Reboot-Timer und dem Beschreiben des Flashs gewinnen koennte. Und... naja, fast:

Code:

# while :; do ./culvert write firmware < /tmp/image-bmc && break; done
[*] Accessing the BMC's AHB via the p2a bridge
[*] Preventing system reset
[*] Gating ARM clock
[*] Configuring VUART for host Tx discard
[*] Initialising flash subsystem
[*] Writing firmware image
.
................................................................................................................................................................................................................................................................
................................................................................................................................................................................................................................................................
.
................................................................................................................................................................................................................................................................
................................................................................................................................................................................................................................................................
.
................................................................................................................................................................................................................................................................
[*] LIBFLASH: Miscompare at 0x00020000
.
................................................................................................................................................................................................................................................................
[*] LIBFLASH: Miscompare at 0x00020000

Da war culvert nach ein paar Bytes die Luft ausgegangen. Aber ich witterte dennoch Morgenluft, denn die geschrieben Bloecke haben ausgereicht, um den Bootloader im Flash effektiv zu zerstoeren, und den BMC schon etwas VOR dem frueheren Stillstandszeitpunkt zu bricken. Sah so aus:

Code:

[...picocom init...]
Type [C-a] [C-h] to see available commands
Terminal ready

DRAM Init-V12-DDR4
0abc1-4Gb-Done
Read margin-DL:0.3784/DH:0.3823 CK (min:0.30)

Ende Gelaende. Quasi der selbe Zustand, wie wenn ALLES im Flash kaputtgeschlagen wurde. Ihr seht vielleicht schon, wohin das fuehrt :banana:

u-boot versucht in diesem Zustand nicht mehr, weiter Daten vom Flash zu laden - ich spare mir also den Clamp-Trick. Das bedeutet auch, dass ich den BMC in diesen kaputten Zustand booten lassen kann, waehrend ich ueber AHB via culvert aus dem Host ganz bequem und ungestoert alle Operationen durchfuehren kann - auch das bereits erprobte `firmware write`. Und tatsaechlich, einen Power Cut (mit einem geeigneten OpenBMC-Image am Host paratgelegt) spaeter:

Code:

root@grml /tmp # ./culvert write firmware < /tmp/image-bmc
[...]
................................................................................................................................................................................................................................................................
................................................................................................................................................................................................................................................................
[*] Performing SoC reset
./culvert write firmware < /tmp/image-bmc  405.86s user 0.88s system 98% cpu 6:52.77 total

... der BMC so:

Code:

DRAM Init-V12-DDR4
0abc1-4Gb-Done
Read margin-DL:0.3784/DH:0.3823 CK (min:0.30)


U-Boot 2019.04 (Jul 26 2024 - 07:18:46 +0000)

SOC : AST2500-A2
RST : WDT2 - 2nd Boot
default boot
RST : WDT3 - Boot
RST : Power On
LPC Mode : SIO:Enable : SuperIO-2e
Eth : MAC0: RMII/NCSI, , MAC1: RGMII,
Model: Gigabyte MC12-LE0 u-boot
DRAM:  496 MiB (capacity:512 MiB, VGA:16 MiB, ECC:off)
MMC: 
Loading Environment from SPI Flash... SF: Detected n25q512ax3 with page size 256 Bytes, erase size 4 KiB, total 64 MiB
*** Warning - bad CRC, using default environment

In:    serial@1e784000
Out:   serial@1e784000
Err:   serial@1e784000
Net:   Invalid PHY interface '<NULL>'
eth-1: ethernet@1e660000Invalid PHY interface '<NULL>'
, eth-1: ethernet@1e680000
Hit any key to stop autoboot:  0
## Loading kernel from FIT Image at 20100000 ...
   Using 'conf-gigabyte-mc12-le0.dtb' configuration
   Trying 'kernel-1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x20100118
     Data Size:    3279824 Bytes = 3.1 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x80001000
     Entry Point:  0x80001000
     Hash algo:    sha256
     Hash value:   ac104186382035da31caec0dd5b32fc612acf419ae5bcfa15226f7d15556c5d0
   Verifying Hash Integrity ... sha256+ OK
## Loading ramdisk from FIT Image at 20100000 ...

BOOM!!! Back. In. The. Game!! :angel:

Danke fuers Lesen, und vielleicht auch Mitfiebern

Was fuer ein Abend! Ich liebe diesen Sche*ß! :wut:

techsolo12 · 23.08.2024

Update lief auf meinen beiden System (PRO 5650; 3600) erfolgreich durch.
Achtung: Das UEFI Update zieht einen nicht verhinderbaren restore der default settings nach sich.

Nur Mainboard MC12-LE0	ebay Piospartslap	Piospartslap	geizhals
Mit Gelid Kühler	eBay Piospartslap	Piospartslap

CPU	Passmark multicore	Passmark singlecore	Support?	APU	ECC (+/Nein)	iGPU
Intel N100	5504	1943	Nein
i5-8500	9581	2452	Nein
3100	11598	2420	QVL	-	+
4650G Pro	16166	2653	QVL	APU	+	+
3600	17748	2567	QVL	-	+
3600x	18919	2652	QVL	-	+
i5-12400	19363	3519	Nein
E5-2690v4	19470	2074	Nein
5500 (kein ECC)	19398	3058	APU	APU	Nein	N
5600G (kein ECC)	19874	3190	APU	APU	Nein	+
5650G Pro	20771	3252	y	APU	+	+
5600	21576	3258	y	-	+
5600x	21888	3361	QVL	-	+
3700x	22542	2660	QVL	-	+
5700 (kein ECC)	24268	3250	?	APU	Nein	N
5700x	26658	3382	y	-	+
5800X3D	28304	3233	siehe #2.893 @JVN	-
i5-13500	31854	3884	Nein
3900x	32620	2706	y	-	+
5950x	45599	3468	QVL, *Kühlung beachten	-	+

[Sammelthread] Gigabyte MC12-LE0 (AM4, B550, servertauglich: IPMI, Dual Lan, ECC)

Inhaltsverzeichnis​

1. Das Angebot Nach oben​

2. Technische DatenNach oben​

3. Prozessor SupportNach oben​

4. Anleitungen / GuideNach oben​

4.1 UpdatesNach oben​

4.2 Reset BMC PasswortNach oben​

5. Problembehandlung Nach oben​

6. FAQsNach oben​

7. VerbrauchswerteNach oben​

8. LinksammlungNach oben​

9. Früherer StartbeitragNach oben​

Gigabyte Mainboard MC12-LE0​

Enthusiast

Experte

Enthusiast

Enthusiast

Redakteur Motivator

Semiprofi

Experte

Neuling

Enthusiast

Urgestein

Redakteur Motivator

Experte

Neuling

Neuling

Experte

Enthusiast

Legende

Semiprofi

Enthusiast

Experte

Legende

Enthusiast

Experte

Legende

Experte

Enthusiast

Experte

Semiprofi

Semiprofi

Experte

Ähnliche Themen

Inhaltsverzeichnis

1. Das Angebot Nach oben

2. Technische DatenNach oben

3. Prozessor SupportNach oben

4. Anleitungen / GuideNach oben

4.1 UpdatesNach oben

4.2 Reset BMC PasswortNach oben

5. Problembehandlung Nach oben

6. FAQsNach oben

7. VerbrauchswerteNach oben

8. LinksammlungNach oben

9. Früherer StartbeitragNach oben

Gigabyte Mainboard MC12-LE0