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.
> 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_CUSTOM_DSDT_INITRD), jinak se nic nestane, protože ve výchozím configu jádra je ta volba vypnutá, je to tak?
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.
„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 :-)