Oprava uspávání notebooků s AMD bude v jádře 5.15

Nutno podotknout, že AMD trvalo snad tři roky rozjet s2idle, což se nakonec stalo v 5.14 a v 5.15 na to možná bude i spoleh.

Spolu s prokletým AMD Sensor Fusion Hubem jsou to dvě vady na kráse jinak velmi solidních APU a notebooků.

U notebooků s Ryzeny první generace (Zen a Zen+) jde ještě upravit ACPI tabulku (dekompilovat, přepsat pár flagů, rekompilovat) a tím zapnout plně funkční podporu klasického S3 sleepu, ale na novějších tam ta funkcionalita prostě není. S2idle je jediná možnost, a konečně se to blíží.

Driver pro sensor fusion hub po skoro dvou letech odkladů dorazil v 5.11, ale implementace driverů pro čidla za ním (např. akcelerometry, luxmetry) stále vázne.

Ten sensor fusion hub mě zas tak netrápil, ale chybějící s2idle vyloženě degradovalo UX toho notebooku.

Já mám Envy (convertible), a u těch je aspoň otáčení obrazovky dost nutnost (např. otočit o 180° v "tent mode")... ale žít se bez toho dá.

> U notebooků s Ryzeny první generace (Zen a Zen+) jde ještě upravit
> ACPI tabulku (dekompilovat, přepsat pár flagů, rekompilovat) a tím
> zapnout plně funkční podporu klasického S3 sleepu, ale na novějších
> tam ta funkcionalita prostě není.

Máš k tomu někde podrobnosti, případně postup? To by mě zajímalo... obecně jde vidět, zvlášť na těch prvních řadách, že ta jejich platforma v laptopech má ještě mezery.

Dali jsme to dohromady po nocích s lidma na gentoo IRC, ve zkratce:

1) extrahuješ a dekompiluješ tabulky DSDT a FACP

acpidump -b
iasl -d dsdt.dat
iasl -d facp.dat

2) v souboru dsdt.dsl je definice všech S* states, všechny začínají podtržítkem (_S0, _S4, ...), jenom S3 začíná X:

Name (_S0, Package (0x04)  // _S0_: S0 System State
(...)
Name (XS3, Package (0x04)
(...)
Name (_S4, Package (0x04)  // _S4_: S4 System State
(...)

takže jediná změna v tomto souboru je, že Name (XS3, Package (0x04) přepíšeš na Name (_S3, Package (0x04). Na jednom z prvních řádků ještě číslo revize (řádek s DefinitionBlock inkrementuješ z (např.) 0x01072009 na 0x0107200A.

3) v souboru facp.dsl vypneš (změníš 1 na 0) redukci funkcí a vypneš s2idle (i když to možná není nutné) a opět inkrementuješ číslo revize z 0x01072009 na 0x0107200A:

Hardware Reduced (V5) : 0
Low Power S0 Idle (V5) : 0

4) oba soubory zase přeložíš do nativního formátu a vytvoříš cpio archiv, kterým při startu bootloader přepíše ACPI tabulky původně načtené z firmwaru (proto se inkrementuje ta revize, aby to ACPI runtime neignoroval):

iasl -sa dsdt.dsl
iasl -sa facp.dsl
mkdir -p kernel/firmware/acpi
mv {dsdt,facp}.aml kernel/firmware/acpi
find kernel | cpio --format newc --create > /boot/envy-suspend-fix-F20.cpio

5) a pak už to jen stačí přidat do bootloaderu jako další initramfs a restartovat. V Grubu něco ve stylu

menuentry "Něco" {
    search --label boot
    linux /vmlinuz-latest xxx xxx
    initrd /envy-suspend-fix-F20.cpio /amd-uc.img /muj-normalni-initramfs
    boot
}

Výhoda je, že to nic trvale nemění - stačí v Grubu před bootem spustit editor a odstranit to z toho řádku, kdyby něco zlobilo.

10. 9. 2021, 18:12 editováno autorem komentáře

Řeším podobný problém u Dellu 5520 s Intelem (kde S3 vypnuli údajně kvůli BSOD ve Windows a přepínač v UEFI BIOSu nezakazující S3 tam tak nemá žádný význam - S3 je trvale vypnuto), ale co jsem tak studoval, tak je třeba stejně sestavit v distribucích jako je Ubuntu novou verzi jádra s povolením načítání toho custom initrd s DSDT (CONFIG_ACPI_CUS­TOM_DSDT_INIT­RD), jinak se nic nestane, protože ve výchozím configu jádra je ta volba vypnutá, je to tak?

super. konečně, po 30, letech se naučil linux uspávat a probouze na AMD

Hmm, mne "tuhne" wakeup na desktope s Ryzenom 3200G / Gigabyte B450M ... Dufajme ze to "soudruzi z AMD" konecne opravili ;-)

Mě funguje wakeup na desktopu s Ryzenem 2400G / MSI B450M MORTAR MAX bezvadně (a na hromadě dalších strojů s AMD taky). Tipuji, že to nebude problém na straně AMD.

Jasnost displeje je zase krásný obrat. Pěkně jste to napsal, velectěnájasnosti :-D

Bohužel jsem právě nainstaloval Ubuntu 21.04 s kernelem 5.11.0 na stolní počítač s Ryzenem 5900X a deskou s X570 řadiči. Výsledek je ten, že sleep nefunguje - počítač se kompletně vypne. Po necelé hodině snažení se jsem tak nějak rozchodil hibernaci, ale přijde mi, že někdy se počítač zasekne ve stavu těsně před vypnutím a zůstane běžet a znovu se dá zapnout jedině restartem.
Je to docela smutná záležitost, protože stejný problém jsem míval na notebooku s Core 2 Duo, na notebooku s Atomem, na stolním počítači s Athlonem 64 X2 a do určité míry i na stolním i5-3xxx. Vlastně by mě zajímalo, jestli jsem nějaká výjimka z pravidla nebo to taky nikdy nikomu pořádně nefungovalo. Vždycky jsem musel sáhnout buď po řešení pomocí hibernace nebo přes shutdown + obnovení oken po startu.

„Vlastně by mě zajímalo, jestli jsem nějaká výjimka z pravidla nebo to taky nikdy nikomu pořádně nefungovalo.“

Jestli myslíte konkrétně s vaším HW, tak tento příspěvek ignorujte. Pokud myslíte více obecně - jakožto dlouholetý uživatel Xubuntu (dříve Ubuntu, to bylo před Unity) (aktuálně na stroji se starší AMD kartou) je pro mě funkční uspání do RAM / na disk (a samozřejmě následně i funkční probuzení) na Linuxu něco jako Yetti - čtu o tom různá svědectví, já jsem to ale v životě neviděl. Tohle je jedna z věcí, co mi asi chybí nejvíce z dob, kdy jsem opustil tehdejší Win XP. (Tou druhou byla výdrž baterky, ale už před lety jsem přesedlal na desktop, takže už to neřeším.)

ta ma bezproblemova zkusenost je s Xubuntu, od verze 12.04, teda mozna na 1000 uspesnejch hibernaci/probuzeni je 1 neuspesna ;-)

Xubuntu jsem měl celkem rád. Bohužel mi na notebooku blbnulo Xfce po probuzení ze sleepu. Typicky zůstal černý displej. Někdy fungovalo poslepu se přihlásit. Někdy jenom shodit Xka a znova nahodit, takže pak spousta aplikací běžela dvakrát...
Tak jsem přešel na MATE, kde mi tak nějak prostě uspávání fungovalo. Nevím proč, prostě fungovalo. Jenže s Compiz, které používám, protože má dobrou feature umožňující přizoomovat obrazovku, zase občas blbne zobrazení - monitory začnou blikat jako světluška v říji. Typicky pomáhá na každém monitoru minimalizovat / maximalizovat nějaké okno.

v Xfce je nativni priblizeni take ;-) ALT+ScrollMouse

Já mám opačnou zkušenost. Nefunkční uspávání je z mé zkušenosti výjimka nikoli pravidlo, hromadu let.

Někdo má, někdo nemá. To je daň za diverzifikaci Linuxu jako takového. My Woknaři to prostě moc neznáme. Tedy jestli zmíněný příspěvek byl cílen na Linux platformu :-D

kazdej ma neco, my linuxari treba nezname ze by nam pulrocni aktualizace smazala data, ovladace, programy, zastupce, zmenila asociace, atd ;-)

„To je daň za diverzifikaci Linuxu jako takového.“

Já bych spíš řekl, že je to daň za to, že pro mnohé výrobce HW není nijak prioritní a) implementovat ovladače pro systém, který má tak relativně malé rozšíření desktopu (takže nemluvím o serverech!) nebo b) zveřejnit dokumentaci dostačující k implementaci takových ovladačů.

Koneckonců na většinu mých problémů (pomalejší rendering (než ve Win), nefunkční scanner (používám VirtualBox+WinXP), atd.) dostávám na Linuxových fórech jednotnou odpověď: kup si podporovaný HW. Jenže já jsem ten typ člověka, co opravdu nerad vyhazuje HW, který ještě slouží. Koneckonců můj desktop je vyřazený PC, který si před víc, jak 10ti lety, pořídil jeden hráč, kterému už dávno nedostačuje, ale mně slouží už roky k plné spokojenosti. (Jen jsem jej trošku urychlil SSD a kvůli Firefoxu, Dockeru a jedné electron-like aplikaci přidal RAM.)

Daní za diverzifikaci Linuxu spíš vidím jinde, např. existuje jedna pěkná aplikace na komunikaci s Androidem, jenže je dost vázaná na KDE.

sice vse NB, ale ja na PentiumM, CoreDuo, asi 5 generaci Atomu, i5-2xxxM, i5-3xxxM, i7-2xxxM, i7-3xxxM sem problem s hibernaci nemel a nemam, aktualni i7-3520M hibernuju/probouzim i nekolikrat denne a kdybych nerestartoval obcas kvuli aktualizaci jadra tak to vydrzi mesice bez poweroff/reboot...

resp. u CoreDuo s AMD FirePro po probuzeni nebyl videt kurzor mysi, coz sem resil pustenim programku co ji schova pri necinosti a zobrazi pri pohnuti :)

Myslím, že v 5.11 (nebo v 5.10) vývoj s2idle rozbil i uspávání přes S3, takže jádra vanilla 5.11, 5.12 a 5.13 se nedají uspat vůbec (pokud si to nějak nevyřešilo distro). 5.14 přidala poslední patche pro s2idle a tam to funguje - alespoň na mym Ryzenu, Fedora třeba ty opravy backporovala i do 5.13 ale jak na tom jsou ostatní netuším. U Ubuntu bych zkusil OEM kernel, ten měl s2idle pro AMD snad jako první. Jinak je možnost build vlastního kernelu, což s configem z distribuce není nějak složitý.

u *buntu lze https://wiki.ubuntu.com/Kernel/MainlineBuilds
tam je nove jadro chvili po tom co vyjde, dokonce obcas i driv nez v ArchLinuxu... aktualne mam v Xubuntu 20.04 jadro 5.14.3 ze vcera a v Archu je zatim 5.14.2 :-)