buster + xen + ryzen 5 5600x: 0.5-1.5 nap utan BUG SOFT LOCKUP

Debian GNU/Linux

ryzen 2200g-n jol mukodik

ryzen 4350g-n jol mukodik

minden ugyanaz csak cpu van kicserelve 4650g-re jol mukodik

memtest ok

csak ryzen 5600x-en nem mukodik, 2 ilyen procin is kiprobaltam

kernel 4.19.181

xen 4.11.4

valaki lepett mar bele ilyenbe?

tesztbol kiprobaltam es buster->bullseye upgrade utan 5600x is mukodik, csak mas problemak jonnek elo: https://hup.hu/node/173737

illetve kicsit korainak tartom elesben hasznalni a bullseye-t :)

koszi!

  • 657 megtekintés

( Ice | 2021. 05. 03., h – 15:49 )

Szerkesztve: 2021. 05. 03., h – 17:05

Hello,

Milyen alaplap/BIOS/UEFI/AGESA verzió?

Kevés az input, nem kicsit!

5.8-as kernelt is csak teszt szerveren használok, ennél újabbat még nem raknék sehova.

ASUS PRIME B550M-K

https://www.asus.com/Motherboards-Components/Motherboards/PRIME/PRIME-B…

BIOSOK kozul ezeket probaltam:

-----------------

Version 1803

2021/02/23 19.76 MBytes

PRIME B550M-K BIOS 1803
1. Update AMD AM4 AGESA V2 PI 1.2.0.0
2. Update AMD RAID UEFI driver
3. Update AURA firmware
4. Improve system stability

-----------------

Version 2003

2021/03/15 19.78 MBytes

Prime B550M-K BIOS 2003
- Update AMD AM4 AGESA V2 PI 1.2.0.1
- Support Smart Access Memory for Ryzen 3000 Series Processors
- Fix the L3 cache performance in AIDA64
- Improved system performance
- Improved system compatibility
- Improved memory performance

----------------

Version 2007

2021/03/23 19.79 MBytes

Prime B550M-K BIOS 2007
"- Update AMD AM4 AGESA V2 PI 1.2.0.1 Patch A
- Fix USB connectivity issue

"

--------------

Version 2201 Beta Version

2021/04/09 19.79 MBytes

PRIME B550M-K BIOS 2201
"- Update AMD AM4 AGESA V2 PI 1.2.0.2
- Fix USB connectivity issue

--------------

a 4.19-es stabillal nem megy, 5.10 van debian testingben ezert ezzel probaltam

neked aztan fura humorod van...

( st3v3 v | 2021. 05. 03., h – 15:50 )

Szerkesztve: 2021. 05. 03., h – 15:51

illetve kicsit korainak tartom elesben hasznalni a bullseye-t

csak nézz rá a RC bug listára :)

ha ez a hiba nem jott volna elo eszembe sem jutott volna bullseye-al kiprobalni utolso utani probalkozaskent

most ujratelepitettem busterrel es az 5.10 backport kernelt tettem fel ra, asztali gepem is ezzel a kernellel megy, ott enelkul nincs grafika

neked aztan fura humorod van...

( Ice | 2021. 05. 03., h – 18:00 )

Szerkesztve: 2021. 05. 03., h – 18:01

Itt a legnagyobb próbléma az, hogy még nem 100%-os a proci támogatás szerintem, se Linux kernel és AMD AGESA oldalról, ASUS-ról nem is beszélve.

Én egy évet kihagytam, vártam mire szerintem stabil lett az AGESA+Linux kernel kombó(1600AF/2600) ezért nem vettem annó egy éve AMD Ryzen 5 3600-at, csak AMD Ryzen 5 1600AF-et.(A legjobb döntésem volt)

VRM hűtés gyakorlatilag nincs az alaplapon és a Realtek ALC887 Audio CODEC se mai gyerek már. Nagyon "TESCO gazdaságos" az alaplapod!
A DELL Szerverek jól mennek az AMD EPIC II-es procikkal nálunk Ubuntun 18.04.5/20.04.2.(5.4-es kernellel).
Azokkal nincs gond.
 

koszi hogy ezt megirtad bar beljebb nem vagyok vele.

"Itt a legnagyobb próbléma az, hogy még nem 100%-os a proci támogatás szerintem, se Linux kernel és AMD AGESA oldalról, ASUS-ról nem is beszélve."

igen en is azt vettem eszre hogy a 4.19-es stabil kernellel nem jo, a par honapos 5.10 LTS kernellel megy csak jol

"Én egy évet kihagytam, vártam mire szerintem stabil lett az AGESA+Linux kernel kombó(1600AF/2600) ezért nem vettem annó egy éve AMD Ryzen 5 3600-at, csak AMD Ryzen 5 1600AF-et.(A legjobb döntésem volt)"

en most eloszor futottam bele olyanba hogy a processzor SOFT LOCKUP bugot ir ki egy regebbi kernelre

lassuk be hogy teszt vagy egy iparilag elfogadott "mennyire stabil" meroszam nelkul ezt eleg nehez pontosan beloni hogy mikortol stabil melyik processzor melyik agesaval es kernellel es csak akkor megvenni ha mar "sok9-es", eddig nem futottam bele ilyenekbe.

"VRM hűtés gyakorlatilag nincs az alaplapon"

ez az asus hibaja, nem tamogatom az RGB-s dolgokat penzzel, meg azt a kovetkeztetest vonnak le belole hogy szukseg van ra (az RGB-s alaplapjukon van VRM hutes)

de mivel minden eddigi alaplapom is ilyen es stabilan mukodik, en azt feltetelezem hogy nem a VRM hutes hianya lesz az amiert a regebbi kernel bugzik.

"és a Realtek ALC887 Audio CODEC se mai gyerek már. "

ami semmilyen korulmenyek kozott nem lesz hasznalva, szoval irrelevans

"Nagyon "TESCO gazdaságos" az alaplapod!"

amire hasznalva lesz teljesen optimalis

"A DELL Szerverek jól mennek az AMD EPIC II-es procikkal nálunk Ubuntun 18.04.5/20.04.2.(5.4-es kernellel).
Azokkal nincs gond."

ez mondjuk zen2-es maggal van ha jol latom, akkor lenne relevans ha zen3-as maggal es 4.19-es kernellel is jol mennenek.

neked aztan fura humorod van...

ezért nem vettem annó egy éve AMD Ryzen 5 3600-at

Hetzneréknél van konkrétan ilyen cpu-val szerelt bérelhető gép, már tavaly januárban is volt az árlista szerint. Most épp nincsen ilyen gépre accountom, a múlt héten volt, nem volt vele semmi gond, folyamatosan használják amúgy linuxos remote desktopok futtatására (most épp Ubuntu 20.04 LTS megy rajta, 5.4.0-47 kernel package).

nem ismerem a Microcode Update Driver mukodeset, kepes ilyenre?

asztali gepemen ryzen 3200g van 2807-es biossal (utolso elotti) ott ezt irja ki:

# dmesg|grep microcode
[    1.093446] microcode: CPU0: patch_level=0x08108109
[    1.093451] microcode: CPU1: patch_level=0x08108109
[    1.093453] microcode: CPU2: patch_level=0x08108109
[    1.093457] microcode: CPU3: patch_level=0x08108109
[    1.093460] microcode: Microcode Update Driver: v2.2.

 

mibol kellene latszania hogy csinalt-e valamit?

neked aztan fura humorod van...

Nem, nem lesz downgrade-elve. A microcode-betöltő modul betöltéskor megnézi, hogy a BIOS alapján mi a proci microcode-verziója, és ha újabb, mint a betöltendő csomag, akkor inkább nem tölti be a régebbi verziót microcode-ot.

Egyébként én sejtem a megoldást: Debian helyett valami frissebb disztrón kéne nézni, pl. Arch, Fedora, ahol nem ilyen dinoszauruszok korabeli 4.19-es kernel van, hanem 5.12-es, és azzal valószínűleg el fog hárulni a probléma. A Debian nem való túl modern hardverre, ezzel mindig belegázolok a debianosok lelki világába, de nem értik meg, hogy ez nem bántás kérdése, hogy valami valahová nem való. Állandóan jönnek nekem ilyen érzelmi alapon, hogy de jajj, a Debil lány a legstabilabbabbabbabb. Nem, nem az, mert ha az lenne, akkor nem nyílna sok ehhez hasonló topik. Nem, nem mindig a legjobb, legtöbben azért ragaszkodnak hozzá, mert azt ismerik.

Meg ezért szoktam röhögni, mikor ilyen konzervatív userek indokolgatják, hogy nem fontos a csomagok frissessége. Dehogynem. Ha valaki új hardvert hajt, ha játékokhoz kell neki a legújabb GPU driver, mesa, vulkan, DXVK Proton, vagy OpenCL/CUDA, VAAPI/VDPAU dekódolás újabb codecekhez, stb., ha valami nagyon új git projektet kell forráskódból forgatni, amihez dependencynek a legújabb verziós dev-csomagok kellenek, stb-stb.. Nem a fenét nem fontos. Az, hogy valakinek nem fontos, mert egy 10-15 éves hardveren nyomja vele ugyanazokat a programokat 20 éve, az nem jelenti azt, hogy másnak se lesz fontos. Ilyenkor persze szeretik mindig oda sarkítani, hogy csak nekem fontos, de megint: pont az ilyen topikok bizonyítják, hogy másnak is fontos lehet.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

amugy van nekem olyan broadwell pentiumos nucom amin anno xen ment (most a polcon pihen, ezt valtottam ryzen 2200g-re), ha jol remlik release elotti 4.9.25-os kernellel meg mukodott, a release utani 4.9.30 es kesobbi kernelekkel nem, indulaskor mar megfagyott. feltettem a 4.9.25-os kernelt, letiltottam a frissiteset es azzal hasznaltam. xen nelkul ment amugy a 4.9.30-as kernellel is de nem az volt a feladata. szoval nem mindig az ujabb a jobb. majd egyszer kiprobalom ujbol de mostmar debian 11-el

neked aztan fura humorod van...

Nem, az új sem mindig jobb, de szükséges, ha olyan dolgot művel valaki a gépen, ahol fontos a frissesség, vagy új hardvert hajt. Nálam 2020 végéig egy nagyon régi ThinkPad X220-ment, ez még Sandy Bridge, őskőkorszaki Intel HD3000-es integrált lassítóval, már 9 éves gép. Mindig minden működött rajta, Arch alatt, legújabb kernelek. A Broadwell ehhez képest újabb, mert viszi az Iris driver a benne lévő GPU-t, meg már Vulkan támogatás meg minden van benne. Nem nagyon kéne új kerneleknek problémát okozniuk. És itt most nem a 4.9.x-ről beszélek, hanem a legújabb 5.11-5.12-ről.

Az is igaz, hogy én Xent sose használtam, amikor virtuális gép kell, akkor QEMU+KVM.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

grafikus gyorsitasnal vagy uj halozati vezerlonel vagy mas drivereknel teljesen egyetertek veled.

de a mostani esetben ahol egy headless, audioless, mindenless gepet csinalok ahol csak a programot kellene futtatnia, annyira azert kompatibilisnek kellene lennie 2 ryzen - egymas utan kovetkezo zen2 es zen3 architekturaju - processzornak hogy ehhez ne kelljen ujabb szoftver.

termeszetesen ha az ujabb processzor tobbet tud lehet olyan kodot forditani ami csak azon megy, de egy x86-64-baseline architekturara forditott programnak mennie kell.

ha majd x86-64-v3-ra forditjak a programokat el lehet mondani hogy milyen minimum cpu kell hozza de az megint mas kerdes.

neked aztan fura humorod van...

( hairless | 2021. 05. 05., sze – 13:21 )

Hello,

  En is belefutottam, C6 statebol nem jott fel rendesen 1-2 mag, amiatt volt (nekem) a lock.
Erdemes megnezni, amik feljonnek erre a keresesre:
https://www.google.com/search?q=amd+ryzen+c6+state+linux

En ezeket raktam a kernel boot parameterbe, azota nem jott elo a dolog:

processor.max_cstate=5 idle=nomwait rcu_nocbs=0-11 iommu=soft

Ui.: Az en altalam hasznalt alaplaphoz 1-2 havonta jonnek/jottek frissitesek, de ez volt az, ami segitett. Az OS Debian 10.

Global C states -t keresd az Advanced \ AMD CBS menü alatt:

Here's AMD talking C-States setting in BIOS https://youtu.be/NRSUYBjlBXw?t=5085

They should be enabled by default. But sometimes mobos have them on 'auto' which actually means disabled, and sometimes they just completely forget to enable.

----------------

Nézd meg Linux alatt hogy jelenleg milyen C állapotok vannak engedélyezve (valami majd megírja milyen tool tudja ezeket kilistázni)

----------------

Global C-state might be disabled by default for better stability when resuming from standby.

I also sort of oversimplified the C-states thing as just relating to standby. The C1 state is just the idle state - operating systems have traditionally sent a 'HLT' instruction to the processor any time it runs out of work to do - the idle % would essentially be how often the CPU was 'executing' the 'HLT' instruction (this execution would occur on the fetch circuitry while the main execution units of the core were idled). There was an enhanced version of this that also reduced voltage at the same time.

C2 is something of a 'deep idle" or 'light sleep' state where hardware was used to cut the clock signal instead of software - this is the 'Standby' from the Windows 95/98 era.

C3 is a more proper sleep mode where the CPU is almost completely off and external hardware (chipset) would need to wake the system back up - usually by pressing the power button or some other interrupter. How far C3 goes depends on the hardware - with some systems turning off nearly everything.

C4, C5, C6 are deeper sleep states that are basically ever lower amounts of voltage and active circuits.

What "Global" means in this context isn't entirely clear to me, but it could mean shutting down the entire CPU during standby/sleep.

-------

jahogy igy ertetted, akkor nem azt lehet allitani hogy max C5-ig engedje. :(

powertopban az latszik az uresjarat statisztikanal hogy

a bios auto (alapertelmezett) es enabled eseten POLL, C1, C2 van ennel tobb C allapotot nem mutat

a bios disabled eseten nincs semmi kiirva

neked aztan fura humorod van...

vegigneztem a osszes beallitast, (kiveve ha egy teljes kepernyos figyelmeztetes utani accept-re jon elo, pl. valami turbo, mert ilyeneket nem szoktam elfogadni) de nem talaltam C state vagy cool&quiet allitast, ez utobbi remlik hogy AM2 vagy AM3 alaplapokon a cpu-nal volt

kerestem azt is amit itt irnak, hogy "enable OS-controlled frequency scaling and Turbo mode in the BIOS" de ezt sem talaltam.

https://support.citrix.com/article/CTX200390

egyebkent meg azt feltetelezem hogy az alaplap gyartok valamennyire konzervativak az ilyen beallitasokkal, es alapertelmezetten probalnak olyat beallitani hogy ne faggyon szet mindenkinek a gepe, de ha akarja akkor tudja atallitani.

neked aztan fura humorod van...

( thuthu | 2021. 05. 05., sze – 15:37 )

Szerkesztve: 2021. 05. 05., sze – 15:38

Xen -nél:

xenpm set-max-cstate 1

vagy valami hasonló.

És legközelebb talán egyszerűbb backportolt kernellel próbát tenni dist-upgrade helyett.

( debtamas88 | 2021. 05. 05., sze – 18:58 )

Szerkesztve: 2021. 05. 05., sze – 19:00

Szia!

Próbáld meg Proxmox-PVE kernellel:
 

wget http://download.proxmox.com/debian/proxmox-ve-release-6.x.gpg -O - | apt-key add -
deb http://download.proxmox.com/debian buster pve-no-subscription

apt-get install pve-kernel-5.11 pve-headers-5.11

PVE-kernel -be alapból van ZFS nem kell fordítani hozzá, KVM-hez van kigyúrva, de szerintem működik XEN-hez is.