Îmi place CachyOS atât de mult încât mă gândesc serios să „parchez” Mac-ul și să trec complet pe acest distro. Deocamdată sunt în perioada de testare intensivă, în care îl folosesc pentru absolut tot, inclusiv redactarea articolelor de blog și editare foto, activități pe care până acum o lună le făceam exclusiv pe macOS.
Totuși, în acest scenariu de utilizare reală, am observat un comportament eratic pe Dell-ul Latitude 5490: la intrarea în sleep, laptopul refuza să își mai revină. Simptomele erau clasice pentru o eroare critică la nivel hardware pe Dell: led-ul de pe tasta Caps Lock pâlpâia intermitent, butonul de pornire rămânea aprins, dar ecranul era complet negru.
Înainte de a căuta o soluție tehnică, am testat toate metodele empirice pentru a verifica dacă sistemul mai este viu, de la verificarea log-ului, la comenzi ping și monitorizarea consumului de energie prin priza Shelly. Rezultatul a fost mereu același: sistemul era complet blocat, necesitând o repornire forțată.
❯ sudo journalctl -b -1 -u systemd-suspend -u systemd-logind -u systemd-hibernate Attempting facial authentication dic 06 22:36:36 lat systemd[1]: Starting User Login Management... dic 06 22:36:36 lat systemd-logind[583]: New seat seat0. dic 06 22:36:36 lat systemd-logind[583]: Watching system buttons on /dev/input/event3 (Power Button) dic 06 22:36:36 lat systemd-logind[583]: Watching system buttons on /dev/input/event1 (Power Button) dic 06 22:36:36 lat systemd-logind[583]: Watching system buttons on /dev/input/event0 (Lid Switch) dic 06 22:36:36 lat systemd-logind[583]: Watching system buttons on /dev/input/event2 (Sleep Button) dic 06 22:36:36 lat systemd-logind[583]: Watching system buttons on /dev/input/event6 (Intel HID events) dic 06 22:36:36 lat systemd-logind[583]: Watching system buttons on /dev/input/event7 (Intel HID 5 button array) dic 06 22:36:36 lat systemd-logind[583]: Watching system buttons on /dev/input/event4 (AT Translated Set 2 keyboard) dic 06 22:36:36 lat systemd[1]: Started User Login Management. dic 06 22:36:41 lat systemd-logind[583]: New session 'c1' of user 'sddm' with class 'greeter' and type 'wayland'. dic 06 22:36:41 lat systemd-logind[583]: New session '1' of user 'sddm' with class 'manager-early' and type 'unspecified'. dic 06 22:36:55 lat systemd-logind[583]: New session '2' of user 'cls' with class 'user' and type 'wayland'. dic 06 22:36:55 lat systemd-logind[583]: New session '3' of user 'cls' with class 'manager' and type 'unspecified'. dic 06 22:36:55 lat systemd-logind[583]: Session c1 logged out. Waiting for processes to exit. dic 06 22:36:55 lat systemd-logind[583]: Removed session c1. dic 06 22:37:06 lat systemd-logind[583]: Removed session 1. dic 06 23:11:31 lat systemd-logind[583]: The system will suspend now! dic 06 23:11:32 lat systemd[1]: Starting System Suspend...
Doar că, la o analiză mai atentă după un alt sleep provocat, jurnalul arăta că sistemul îngheața în timp ce încearcă să adormă, nu la trezire:
[...] dic 06 23:53:18.339587 lat systemd[1]: Reached target Sleep. dic 06 23:53:18.341258 lat systemd[1]: Starting System Suspend... dic 06 23:53:18.378332 lat systemd[1]: user@1000.service: Unit now frozen-by-parent.
Oare de ce?
Intel inside behind
Investigând problema, am aflat că nu este vorba doar de o inginerie defectuoasă din partea Dell, ci despre un cumul de factori care afectează întreaga industrie. Este vorba despre un lanț al slăbiciunilor creat de o tranziție majoră în arhitectura hardware, petrecută exact în perioada lansării generației a 8-a de procesoare Intel (Kaby Lake-R / Whiskey Lake).
Această generație specifică (2017-2019) este un adevărat punct nevralgic pentru Linux. Indiferent dacă pe carcasă scrie Dell, HP sau Lenovo (pot confirma personal că ThinkPad T480 suferă de exact aceleași probleme), cauzele sunt comune și țin de standarde implementate agresiv.
Cei patru „vinovați” tehnici
Pentru a înțelege de ce laptopul nu se trezește, trebuie să ne uităm sub capotă, la modul în care hardware-ul comunică (sau nu) cu sistemul de operare.
1. Războiul ACPI: S3 vs. S0ix
Aceasta este, probabil, cauza rădăcină a majorității problemelor de sleep. Până la generația a 7-a, standardul de aur era S3 (Suspend-to-RAM): hardware-ul oprea aproape tot, păstrând curent doar în memoria RAM. Odată cu generația a 8-a, Intel și Microsoft au forțat trecerea la S0ix/InstantGo (Modern Standby), cu scopul ca laptopul să se comporte ca un telefon și să primească notificări în timp ce „doarme” (sursa – document PDF).
Producătorii au rescris BIOS-urile pentru a favoriza Modern Standby, lăsând vechiul standard S3 netestat sau cu bug-uri. Kernel-ul Linux încearcă să negocieze S0ix, dar hardware-ul nu este pregătit 100%, rezultând un crash. Soluția este forțarea modului vechi prin parametrul mem_sleep_default=deep.
2. TPM 2.0 și furtuna de întreruperi
Generația a 8-a a marcat momentul în care cipurile TPM 2.0 au devenit standard hardware. Problema este că driverul generic de Linux (tpm_tis) se așteaptă ca cipul să respecte standardele, în timp ce multe implementări fizice (Nuvoton, Infineon) aveau comportamente eratice la semnalele de întrerupere (IRQ) în timpul tranzițiilor de putere.
Windows rezolvă asta prin drivere specifice care „peticesc” eroarea, dar pe Linux, sistemul primește o rafală de întreruperi care blochează procesorul. Parametrul tpm_tis.interrupts=0 rezolvă problema ignorând aceste semnale.
3. Intel UHD Graphics și Panel Self Refresh (PSR)
Placa video integrată Intel UHD 620 este capabilă, dar vine cu funcții agresive de economisire a energiei, precum PSR (Panel Self Refresh). Aceasta permite GPU-ului să adoarmă complet când imaginea e statică, panoul LCD folosind propria memorie.
Implementarea depinde enorm de calitatea ecranului (LG, AUO, BOE). Dacă panoul nu răspunde la timp la comanda de trezire, driverul video intră în panică sau ecranul rămâne negru.
4. SSD-urile NVMe și stările de putere (APST)
Controlerele NVMe din acea perioadă (în special cele mid-range, cum ar fi WD Black) au probleme cu APST (Autonomous Power State Transition). Practic, SSD-ul intră într-o stare de somn prea adâncă și nu mai răspunde la timp, cauzând blocarea sistemului. Parametrul nvme_core.default_ps_max_latency_us=0 dezactivează aceste stări problematice pe Linux.
Soluția tehnică: Parametrii de kernel
Vestea bună este că putem transforma un sistem instabil într-unul extrem de solid („rock-solid”) aplicând o serie de parametri care dezactivează exact aceste „inovații” imature ale epocii 2018. Această combinație a devenit un fel de „Gold Standard” pentru posesorii de laptopuri cu Intel Gen 8.
Pe CachyOS (sau orice distribuție care folosește systemd-boot), trebuie să edităm fișierele de configurare din loader.
Atenție: Editați cu grijă fișierele de boot. O greșeală de sintaxă poate împiedica pornirea sistemului.
Deschideți terminalul și editați configurația kernel-ului curent:
sudo nano /boot/loader/entries/linux-cachyos.conf
Abia după ce confirmați că sistemul este stabil timp de câteva zile, repetați procedura și pentru fișierul linux-cachyos-lts.conf. Astfel, veți avea o soluție de rezervă funcțională prin kernelul LTS, pe care îl puteți selecta din meniul de boot în cazul în care apar probleme cu versiunea principală.
La linia care începe cu options, adăugați la final, pe același rând, următorul șir de parametri:
mem_sleep_default=deep tpm_tis.interrupts=0 nvme_core.default_ps_max_latency_us=0
Salvați fișierul (Ctrl+O, Enter) și ieșiți (Ctrl+X), apoi reporniți laptopul.
Concluzie: De ce pe Windows merge „din prima”?
Răspunsul e simplu și pragmatic: Microsoft lucrează direct cu Intel și producătorii hardware. Driverele de Windows (Chipset, Management Engine) conțin mii de linii de cod care sunt efectiv soluții de ocolire („hacks”) pentru aceste defecte hardware. Linux, în schimb, încearcă să respecte standardele stricte; când BIOS-ul sau firmware-ul deviază de la standard, apare eroarea.
Cu acești parametri adăugați, laptopul se comportă acum impecabil, iar sleep mode funcționează exact așa cum ar trebui.
