AM5 Mainboard-Empfehlung für Linux

Krakadil schrieb:
Das stimmt nicht. Da kannst auf jedem AM5 Linux ohne Probleme nutzen.

Das war die eigentliche Frage.
Ich glaub das bringt nix zu diskutieren. Ich glaub der mike78sbg versteht das Problem grundsätzlich nicht. Deswegen die falsche Tatsachenbehauptung, ich würde Gigabyte nicht mögen und es deswegen schlecht reden.
 
  • Gefällt mir
Reaktionen: Krakadil
Ich vermute mal er trollt bzw. ich hoffe es für Ihn.
 
Ich sage, das viele Hersteller mit Linux können und das es mehr an einen Model liegen kann, wenn es nicht klappt.

Benutze in meinen zweit PC ein billig Asrock A620M Board und das funktioniert mit einem 7600X. Kombiniert noch mit einer Intel ARC A750 und habe damit für Linux einen komplett Exoten PC. Dann benutze ich für Linux keinen typischen Desktop, sondern mit Hyprland ein Fenstermanager.
 
Also zwei Dinge die ich mit Mainboards unter Linux gemerkt hab: 1. Sollte RGB für dich wichtig sein, wird Asus recht gut unterstützt. https://openrgb.org/devices.html
2. Ich hatte meine Freude mit dem Intel I225-V. Vielleicht bin ich da einfach das gebrannte Kind, aber der kommt mir nicht mehr ins Haus. Meinen Eindruck nach hatte der unter Linux sogar mehr Probleme gemacht als unter Windows - kann aber natürlich rein subjektiv sein in Abhängigkeit mit meinem Heimnetz (Mikrotik). Entsprechend empfehle ich Freunden eher den Realtek 2,5Gbit.
Insgesamt ist es so wie meine Vorredner sagen, das Meiste würd über den SoC realisiert und exotische Zusatzchips gibt es eher selten. Glaub bei Asus gibts Energieüberwachung über einen eigenen Chip, das könnte ich mir auch auf anderen Boards vorstellen, aber da gehts eher um zusätzliche Sensoren. In den großen Kernel-Versionssprüngen und den dazugehörigen Patchnotes lese ich jedenfalls regelmäßig von Asus, MSI, Asrock und Gigabyte die dort einziehen.
Denke heutzutage kann man da nicht viel falsch machen, egal mit welchem Board.
 
Asus hatte ich vor 20 Jahren mal auf meiner schwarzen Liste wegen deren linuxfeindlicher Firmenpolitik.

Mittlerweile wird Asus recht gut unterstützt, was ich allerdings noch immer nicht der Einstellung bei Asus zuschreibe. Gerade Asus-Produkte kaufe ich nicht blind sondern recherchier vorher ausgiebig, ob es irgendwelche Probleme gibt. Support von Asus gibt's nur und ausschließlich für Windows.

Beispiel 1 - Motherboard: Asus x670e Plus Wifi
Hatte ich mir geholt, da der Preis für die gebotene Ausstattung mir sehr günstig erschien. Ich hab's mittlerweile auch bei meinem Sohn eingebaut. Es wird unter Linux auch sehr gut unterstützt.

Anfangsproblem beim Motherboard der Hardwaresensor: Asus verwendete eine spezielle Version des NCT6796D. Zum Laufen bekommt man das Ding nur über eine Modeprobe-Option (nct6775.force_id=0xd420).

Beispiel 2 - Monitor: Asus PG42UQ
Ich hatte das Problem, dass die variable Refreshrate (Freesync) sich nicht aktivieren lassen wollte. Wayland bot mir Adaptive Sync nicht an, Xorg schrieb mir bei vrr_capable eine 0.

Also schrieb ich den Asus-Support an. Der meldete dann zurück (siehe mein erster Satz), dass nur Windows unterstützt wird. Sie fragten mich, ob ich im von Asus angepassten Adrenalin-Treiber für Windows das VRR aktivieren kann.

Die tatsächliche Lösung bestand dann darin, dass im OSD-Menü des Monitors das Bild auf Vollbild gestellt werden muss. Ich hatte bis dahin 1:1 benutzt. Bei letzterem ging ich davon aus, dass das Monitorformat komplett von der Graka gesteuert wird. Nach der Umstellung auf Vollbild klappte alles problemlos. Ich hatte die Lösung dann auch dem Asus-Support zurückgemeldet in der Hoffnung, dass sie beim nächsten Kunden eine kompetentere Antwort geben (können oder wollen). In der Monitoranleitung stand zu dem Problem übrigens auch nichts.

Firmware-Updates des Monitors kann man übrigens auch nur über ein Windows vornehmen. Zum Glück kommen die Updates nicht allzu oft vor.
 
@barmbekersurfer ist die Frage was genau kompatibel sein soll. Wenn du so mutig bist und das Gigabyte kaufst (meine Erfahrungen sind negativ bis sehr negativ), berichte mal bitte was bei "systemctl suspend" passiert ;)
 
someoneElse666 schrieb:
(meine Erfahrungen sind negativ bis sehr negativ)
Ich schaue ganz gern in die c't. Die bringt ja in schöner Regelmäßigkeit "optimale" PC-Bauvorschläge und betont, die Hardware auch mit Linux überprüft zu haben. Da waren in letzter Zeit gelegentlich Gigabyte-Mainboards dabei.
 
Quelle? Hab auf die schnelle nur das hier gefunden: https://www.heise.de/ratgeber/FAQ-z...native-Bauteile-und-Grafikkarten-7485320.html
Kein Wort von ACPI, und ich bin mir recht sicher, das funktioniert auch dort nicht. Wäre vielleicht cool, wenn ein c't Leser das denen mal sagen würde, dass die doch bitte auch wirklich alles testen sollen ;)
Die werden nicht für jedes Board grossartig neue Entwicklungen bauen und das meiste wiederverwenden. Von dem her gehe ich davon aus, dass bei vermutlich allen AM5-Gigabyte Boards ACPI nicht sauber funktioniert.
 
someoneElse666 schrieb:
Mein Gedächtnis. ;)

Ich kann jetzt gar nicht mal meine Hand dafür ins Feuer legen, dass es wirklich AM5 war. Ich bin nur Gelegenheitsleser und kaufe nicht jedes Heft. Online sind ja die spannenden Sachen meistens hinter der Paywall.

Aber ich kann mich noch gut daran erinnern, dass vor einigen Monaten eine Gigabyte-Platine empfohlen wurde.

Gilt das von Dir beschriebene Problem nur für AM5 oder spielt der Sockel keine Rolle?
 
  • Gefällt mir
Reaktionen: barmbekersurfer
Genau der Fehler, nur leider funktioniert der Fix nicht mehr bei AM5 (mindestens beim B650). Ich hab alle möglichen trigger deaktiviert, ist trotzdem sofort aufgewacht. Habe mehrere Stunden versucht zu debuggen, u.a. auch in #debian-next im OFTC sowie in #linux im liberachat, hab sogar irgendwann einen Kernel Dev (in Matrix) dran bekommen der mir bisschen geholfen hat zu debuggen, aber der hatte irgendwann auch die Schnauze voll ;D er hat den Fehler auch nicht genau finden können. Hab dann das Board getauscht (auf ASRock) und es lief sofort alles. Das Gigabyte war nur ein "Ausrutscher", weil der Händler das Asrock gerade nicht da hatte. Hätte warten sollen und bei bewährtem bleiben..
 
  • Gefällt mir
Reaktionen: barmbekersurfer und Tevur
barmbekersurfer schrieb:
Manche AM5-Mainboards sollen ja im Schneckentempo booten.
Im BIOS "Memory Context Restore" aktivieren (nicht auto), dann gibts auch kein Schneckentempo.
 
  • Gefällt mir
Reaktionen: Pummeluff, barmbekersurfer und rarp
barmbekersurfer schrieb:
Manche AM5-Mainboards sollen ja im Schneckentempo booten. Ist das bei dem Gigabyte auch so?
Was heißt denn Schneckentempo bei Dir konkret?
Ich hab jetzt keine Zeit gestoppt oder so. Aber der Rechner ist nach dem einschalten in deutlich unter einer Minute auf dem Desktop.
 
@someoneElse666 @Tevur
Nun habe ich mich ein wenig in die "suspend"-Thematik eingelesen. Ich hatte da überhaupt keinen Plan. Ich bin zwar mit Debian bookworm unterwegs, aber wirklich nur als überzeugter Linux-User ohne jeglichen IT-Hintergrund.

Also geht es um den "Bereitschaftszustand"? Wenn ich unter Gnome in den "Energieeinstellungen" "Automatisch in Bereitschaft gehen" eine "Verzögerung" in Minuten anklicke, dann geht ein Gigabyte-Board eben nicht in Bereitschaft, sondern läuft einfach normal weiter? Wenn dem so ist, finde ich das auch nicht gerade prickelnd. Oder gibt es ein anderes Problem?

andy_m4 schrieb:
Was heißt denn Schneckentempo bei Dir konkret?
Mein ASRock-AM4 bootet mit Debian in 20 Sekunden. In mehreren Rezensionen habe ich von ca. 2 Minuten bei AM5 gelesen. Das würde ich dann nicht so toll finden.

Kuristina schrieb:
Im BIOS "Memory Context Restore" aktivieren ...
Wenn ich es richtig verstanden habe, muss der Rechner aber durchgehend am Stromnetz bleiben. Netzleiste mit Power-Schalter hebelt die Funktion wohl aus.
 
@barmbekersurfer ich nutze kein Gnome, vermute aber, das führt im Hintergrund einfach ein "systemctl suspend" aus. Das kannst du auch von der Kommandozeile selbst starten. Und genau, es geht darum, dass das System dann in den Standby geht und auf Eingaben reagiert indem es aufwacht. Wenn man oft an PC geht, dann wieder weg für 30 Minuten, dann wieder hin, und das mehrmals am Tag, dann rentiert das zum Strom sparen. Das Problem bei dem Board das ich hatte war, es ging in den suspend und ist nach weniger als 1 Sekunde wieder aufgewacht aufgrund irgend eines Triggers (vermutlich ein Bug).
Ich hab noch nie gesehen, dass ein System 2 Minuten zum booten bräuchte. Vielleicht wenn RAM-learning gerade läuft (weis den Fachbegriff nicht, wenn das UEFI den ram testet bei zb. Frequenzänderung).
 
Kuristina schrieb:
Im BIOS "Memory Context Restore" aktivieren (nicht auto), dann gibts auch kein Schneckentempo.
Sollte man aber nicht tun?
 
Weil? 🙂 Das war gleich das Erste, was ich bei meinem neuen System gemacht habe. Würde ich auch jedem mit AM5 raten. Bootet dann genauso schnell, wie vorher mit AM4.
 
  • Gefällt mir
Reaktionen: D.S.i.u.S. und Krakadil
Zurück
Oben