Skip to content

Meine AMD Ryzen 5 8600G Story

Linux
  • Ok, die AMD Ryzen 5 8600G APU ist seit 31.01.2024 verfügbar. Bei Linux sollte man es eigentlich lassen, neuere Hardware einzusetzen. Da AMD und auch Intel Hardware sehr gut im Kernel gepflegt wird, machte ich mir darüber nicht so wirklich Gedanken.

    Ich hatte ja schon mal meine Versuche, eine AMD5 Plattform zu nutzen, hier aufgeschrieben. Dieser Versuch war ziemlich kläglich gescheitert. Eine Woche später, war ich nahe am Nervenzusammenbruch 😉

    Aber, man lässt sich ja nicht lumpen, AM5 Boards sind ja echte Schnapper - also schnell ein Neues bestellt.

    ASUS ROG STRIX B650E-F GAMING WIFI

    Erste Versuche, selbes Problem. 😈 Aufgeben, ist keine Option.

    Ich hatte wirklich viele BIOS Optionen durch, manchmal startete das Board gar nicht mehr. Also wieder Clear CMOS usw. Das ganze zerrt ganz schön an den Nerven. Einer meiner bekannten Sys Admins meinte, ich soll jetzt auch noch neuen DDR Ram kaufen. NEIN - keine Option. Schon genug Kohle verbrannt. Also, Rechner aus! Abschalten, Kopf frei machen...

    Das Board hatte ich übrigens auf das letzte verfügbare BIOS, Version 2613, geflasht.

    20240513_172149.jpg

    Am Sonntag Morgen mit ganz viel Kopfschmerzen wach geworden, lag bestimmt am Suspend to RAM (STR) Problem? Also, erst mal ☕

    Danach alle meine Gedankengänge resettet, manchmal hilft das. Ich habe dann beim Durchsehen des BIOS nochmal über zwei Funktionen nachgedacht. Einmal die EXPO Funktion. Wer nicht weiß was das ist, wusste ich auch nicht, bekommt jetzt die Kurzerklärung.

    Im DDR Ram sind irgendwo die Speicher-Settings versteckt, die kann man auslesen und so das BIOS entsprechend einstellen. Das hatte gestern nicht so wirklich was gebracht. Ich hatte immer das erste Profil gewählt, die Werte sollten den Speicher dann vernünftig einstellen. Warum so viel Augenmerk auf den DDR Speicher? Mir war bei den STR-Problemen mehrmals aufgefallen, dass die gelbe Diagnose-LED auf dem Board an war, das deutet auf ein RAM Problem hin.

    20240513_165847.jpg

    Somit habe ich mir die Profile noch mal angeschaut und bin auf ein Profil "Tweaked" gestoßen. Da ist eine Einstellung anders.

    DDR5-5200 40-40-77-2N
    

    Das 2N ist anders, zu den anderen Profilen. Ok, dann wählen wir das mal aus.

    Ein Setting erregte noch meine Aufmerksamkeit. Mir war aufgefallen, das folgende Funktion eingeschaltet war.

    Resize BAR
    

    Gute Erklärung was das ist und macht, habe ich hier gefunden -> https://www.howtogeek.com/819578/what-is-resizable-bar-on-a-gpu/

    Da ich die Probleme des STR auf die GPU im Prozessor schob, AMD Radeon™ 760M, habe ich das einfach mal abgeschaltet. Danach neu gestartet, getestet ging nicht richtig. Bäh 😞

    Zu dem Zeitpunkt war ich auf Kernel 6.9, irgendeine RC Version. Ok, also mal alle Kernel runter geschmissen, die ich testweise installiert hatte. Das waren die Kernel 6.8 & 6.9. Mein Betriebssystem ist ein Manjaro im Testing Stage. Desktop KDE Plasma 6 auf einer Wayland-Session.

    Dann wieder starten und schauen ob es funktioniert. Und Zack, der STR geht wieder JUHU "Never give up" 🤓

    Welcher der beiden Einstellungen jetzt DIE Lösung war, muss ich noch ausprobieren. Ich tippe auf RAM Settings. Da ich aber jetzt fast 1 1/2 Wochen da dran bin, gibt es jetzt erst mal eine ausgiebige Pause. Ich kann keinen Reboot mehr sehen 😀

    13.05.2024

    Mittlerweile habe ich Kontakt zum Support und man wurde über evtl. RAM-Probleme informiert. Jo, das wusste ich mittlerweile auch. Da mich jetzt aber noch die Frage umtrieb, welche der beiden Einstellungen die Richtige war, habe ich Resize BAR mal wieder aktiviert. Und siehe da, STR funktionierte wieder ohne Probleme.

    Aktiver Kernel

    uname -a
    Linux frank-manjaro 6.6.30-2-MANJARO #1 SMP PREEMPT_DYNAMIC Wed May  8 17:46:43 UTC 2024 x86_64 GNU/Linux
    

    Dann trieb mich noch die Frage herum, wofür steht dieses 2N ?

    Eine Erklärung für das 2N in den DDR Settings von ChatGPT
    https://chat.openai.com/share/79841b8b-ceb7-4f58-945e-3f097ccb0976

    Somit kann ich das Problem ziemlich eindeutig auf den Speicher schieben und somit hätte das auch alles auf dem MSI Board gelaufen.

    Ich stehe noch im Kontakt mit dem Support, mal schauen ob wir den RAM noch austauschen. Wird fortgesetzt...

  • Ich habe nun ein 64GB G.Skill Ripjaws S5 schwaru DDR5-5200DIMM CL36 Dual Kit verbaut.

    Beim ersten Einschalten im BIOS die Einstellungen kontrolliert. Speicher mit korrekter Geschwindigkeit (Auto) erkannt. Neu gestartet und erster Test Standby. Scheint zu Laufen. Dann werde ich das mal die nächsten Tage beobachten.

    Kann mir jemand erklären, warum AM5 Boards so furchtbar langsam sind? Also z.B. das Erwachen aus dem Standby, BIOS aufrufen usw. Da sind AM4 Boards ja geradezu Formel1 Boliden.

  • OpenSource - Donations 2024

    Allgemeine Diskussionen
    1
    0 Stimmen
    1 Beiträge
    118 Aufrufe
    Niemand hat geantwortet
  • Update 1.32.1 released

    Vaultwarden
    1
    0 Stimmen
    1 Beiträge
    107 Aufrufe
    Niemand hat geantwortet
  • Missing npm on debian 12

    NodeBB
    1
    0 Stimmen
    1 Beiträge
    203 Aufrufe
    Niemand hat geantwortet
  • Crowdsec - Ein fail2ban Ersatz?

    Linux
    2
    +0
    0 Stimmen
    2 Beiträge
    820 Aufrufe
    FrankMF
    Ich kann jetzt hier von meiner ersten Erfahrung berichten und wie CrowdSec mich gebannt hat Was war passiert? Ich war gestern sehr intensiv mit der Konfiguration von Nextcloud <-> Collabora Online beschäftigt. Nachdem ich irgendwie nicht weiterkam habe ich mich der Erstellung eines Dokumentes gewidmet. Nach einiger Zeit war die Nextcloud nicht mehr erreichbar. Ok, hatte ich bei der Konfiguration auch schon mal, den Server einmal neugestartet und fertig. Doch jetzt kam es, Server neugestartet - hilft nicht. Gut, schauen wir mal nach, Der SSH Login ging auch nicht Jetzt war guter Rat gefragt. Zu diesem Zeitpunkt ging ich noch davon aus, das auf diesem Server kein CrowdSec installiert war, sondern fail2ban. Und fail2ban hatte eine sehr kurze Bantime vom 10M. Also blieb wohl nur noch das Rescue System von Hetzner. [image: 1694411392066-488866bc-3dcf-4abc-9e98-6107d65aa4c7-grafik.png] Da hatte ich ja so gut wie gar keine Erfahrung mit. Also mal kurz den Nico angetriggert und es kam folgender Link. https://docs.hetzner.com/de/robot/dedicated-server/troubleshooting/hetzner-rescue-system/ Das Laufwerk war schnell bestimmt und schnell nach /tmp gemountet. Danach musste man sich noch mit chroot in diese Umgebung anmelden. chroot-prepare /mnt chroot /mnt Nachdem das klappte, habe ich eben fail2ban disabled. sysmctl disable fail2ban Danach das Rescue beendet. Der Server startete wieder und ich kam wieder per SSH drauf. Puuh. Bei meiner ersten Kontrolle fiel mir was auf root@:~# pstree systemd─┬─2*[agetty] ├─atd ├─cron ├─crowdsec─┬─journalctl │ └─8*[{crowdsec}] ├─crowdsec-firewa───9*[{crowdsec-firewa}] Wie? Da läuft CrowdSec? Da ich dabei bin die Server auf CrowdSec umzustellen, war das wohl hier schon gemacht, aber leider nicht vernünftig. fail2ban hätte mindestens disabled werden müssen und in meiner Dokumentation war das auch nicht enthalten. 6 setzen! CrowdSec besteht ja aus zwei Diensten, CrowdSec und dem Firewall-Bouncer. Der CrowdSec Dienst lief aber nicht, der war irgendwie failed. Ok, starten wir ihn und schauen was passiert. Nachdem er gestarte war mal die Banliste angeschaut. cscli decisions list ergab diesen Eintrag. 2551501 │ crowdsec │ Ip:5.146.xxx.xxx │ crowdsecurity/http-crawl-non_statics │ ban │ │ │ 53 │ 1h5m55.391864693s │ 1671 Meine IP war gebannt. Dann wissen wir ja , woher die Probleme kamen. cscli decisions delete --id 2551501 Nach Eingabe war der Ban entfernt. Na gut, aber da ich aktuell immer noch an der richtigen Konfiguration von NC <-> CODE bastel, könnte das ja wieder passieren. Was machen? Kurz gegoogelt. Es gibt eine Whitelist. Aha! /etc/crowdsec/parsers/s02-enrich/whitelists.yaml name: crowdsecurity/whitelists description: "Whitelist events from private ipv4 addresses" whitelist: reason: "private ipv4/ipv6 ip/ranges" ip: - "127.0.0.1" - "::1" - "5.146.XXX.XXX" cidr: - "192.168.0.0/16" - "10.0.0.0/8" - "172.16.0.0/12" # expression: # - "'foo.com' in evt.Meta.source_ip.reverse" Danach den Dienst neustarten. Jetzt hoffen wir mal, das es hilft. Zum Schluss noch was, was mir aufgefallen war und was mich auch sehr verwirrt hatte. CrowdSec hatte wegen einem crowdsecurity/http-crawl-non_statics gebannt. Dadurch konnte ich meine subdomain.<DOMAIN> nicht erreichen. Ok, logisch, wenn der Ban von da ausgeht. Ich konnte aber gleichzeitig eine andere subdomain mit derselben <DOMAIN> auch nicht erreichen. Komplett verwirrte es mich dann, als ich eine andere <DOMAIN> auf dem selben Server erreichen konnte. Und zum Schluss ging auch der SSH nicht. Also, wieder viel gelernt..
  • Debian Buster 10.9 released

    Linux
    1
    0 Stimmen
    1 Beiträge
    207 Aufrufe
    Niemand hat geantwortet
  • LUKS verschlüsselte Platte mounten

    Linux
    2
    +0
    0 Stimmen
    2 Beiträge
    1k Aufrufe
    FrankMF
    So, jetzt das ganze noch einen Ticken komplizierter Ich habe ja heute, für eine Neuinstallation von Ubuntu 20.04 Focal eine zweite NVMe SSD eingebaut. Meinen Bericht zu dem Thema findet ihr hier. Aber, darum soll es jetzt hier nicht gehen. Wir haben jetzt zwei verschlüsselte Ubuntu NVMe SSD Riegel im System. Jetzt klappt die ganze Sache da oben nicht mehr. Es kommt immer einen Fehlermeldung. unbekannter Dateisystemtyp „LVM2_member“. Ok, kurz googlen und dann findet man heraus, das es nicht klappen kann, weil beide LVM Gruppen, den selben Namen benutzen. root@frank-MS-7C37:/mnt/crypthome/root# vgdisplay --- Volume group --- VG Name vgubuntu2 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 4 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 1 Max PV 0 Cur PV 1 Act PV 1 VG Size <464,53 GiB PE Size 4,00 MiB Total PE 118919 Alloc PE / Size 118919 / <464,53 GiB Free PE / Size 0 / 0 VG UUID lpZxyv-cNOS-ld2L-XgvG-QILa-caHS-AaIC3A --- Volume group --- VG Name vgubuntu System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VG Size <475,71 GiB PE Size 4,00 MiB Total PE 121781 Alloc PE / Size 121781 / <475,71 GiB Free PE / Size 0 / 0 VG UUID jRYTXL-zjpY-lYr6-KODT-u0LJ-9fYf-YVDna7 Hier oben sieht man das schon mit geändertem Namen. Der VG Name muss unterschiedlich sein. Auch dafür gibt es ein Tool. root@frank-MS-7C37:/mnt/crypthome/root# vgrename --help vgrename - Rename a volume group Rename a VG. vgrename VG VG_new [ COMMON_OPTIONS ] Rename a VG by specifying the VG UUID. vgrename String VG_new [ COMMON_OPTIONS ] Common options for command: [ -A|--autobackup y|n ] [ -f|--force ] [ --reportformat basic|json ] Common options for lvm: [ -d|--debug ] [ -h|--help ] [ -q|--quiet ] [ -v|--verbose ] [ -y|--yes ] [ -t|--test ] [ --commandprofile String ] [ --config String ] [ --driverloaded y|n ] [ --nolocking ] [ --lockopt String ] [ --longhelp ] [ --profile String ] [ --version ] Use --longhelp to show all options and advanced commands. Das muss dann so aussehen! vgrename lpZxyv-cNOS-ld2L-XgvG-QILa-caHS-AaIC3A vgubuntu2 ACHTUNG Es kann zu Datenverlust kommen, also wie immer, Hirn einschalten! Ich weiß, das die erste eingebaute Platte mit der Nummer /dev/nvme0n1 geführt wird. Die zweite, heute verbaute, hört dann auf den Namen /dev/nvme1n1. Die darf ich nicht anpacken, weil sonst das System nicht mehr startet. /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> /dev/mapper/vgubuntu-root / ext4 errors=remount-ro 0 1 # /boot was on /dev/nvme1n1p2 during installation UUID=178c7e51-a1d7-4ead-bbdf-a956eb7b754f /boot ext4 defaults 0 2 # /boot/efi was on /dev/nvme0n1p1 during installation UUID=7416-4553 /boot/efi vfat umask=0077 0 1 /dev/mapper/vgubuntu-swap_1 none swap sw 0 0 Jo, wenn jetzt die Partition /dev/mapper/vgubuntu2-root / anstatt /dev/mapper/vgubuntu-root / heißt läuft nichts mehr. Nur um das zu verdeutlichen, auch das könnte man problemlos reparieren. Aber, ich möchte nur warnen!! Nachdem die Änderung durchgeführt wurde, habe ich den Rechner neugestartet. Puuh, Glück gehabt, richtige NVMe SSD erwischt Festplatte /dev/mapper/vgubuntu2-root: 463,58 GiB, 497754832896 Bytes, 972177408 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes Nun können wir die Platte ganz normal, wie oben beschrieben, mounten. Nun kann ich noch ein paar Dinge kopieren
  • IPTables Logging

    Linux
    1
    0 Stimmen
    1 Beiträge
    290 Aufrufe
    Niemand hat geantwortet
  • NGINX - Installation

    NGINX
    1
    +1
    0 Stimmen
    1 Beiträge
    320 Aufrufe
    Niemand hat geantwortet