Érdekesen működik mostanság a Fedora, nvidia driver, stb... inkább csak azt szeretném tudni, hogy ezek általánosak, vagy itt van valami nagyon elrontva.
Fedora 41 alatt, az aktuális nvidia driverrel kifagyogatott a suspend, nem sikerült deep sleep-be mennie a gépnek, vagy nem tért vissza belőle. - Korábban mint ha nem lett volna ilyen probléma.
Rájöttem, hogy friss boot után, ha waylanddal lépek be, akkor működik tökéletesen a deep sleep-be lépés is, és a visszatérés is onnan. Ha használok pár programot (pl brave), és utána próbálom meg a suspend-et, akkor deep sleep-be téréskor elmegy a kép, majd felzúgnak a ventillátorok, és 20-40 másodperc után lesz valami timeout a journalctl-ben. (bluetoothd-vel kapcsolatban is, és az nvidia driverrel kapcsolatban is).
Ha átmegyek X11-re, akkor minden működik, működik a suspend: a deep sleep, és a felébredés is. Kivéve, hogy itt elkezdődött az az idegesítő dolog, hogy a monitor kb 10 másodperc után lekapcsol, néha elmegy a kép, majd visszajön. Eddig ilyen probléma nem volt X11 alatt.
Az alaplap: Gigabyte B650, a videókártya: nvidia rtx 4060
Tapasztalt valaki esetleg hasonlót? Köszi szépen.
Hozzászólások
Saját történet, nem kifejezetten erre vonatkozik.
4-5 évente veszek új gépet, a mardék a házon, tápon kívül megy tovább a családban.
Régi gép: B450-3800X-32GB-NVME+SATAIII-NVidia1060
Új: B650-9900X-64GB-NVME-AMD7600
Átlag felhasználás mellett bőven elég volt a régi is, DE az nvme max sebesség miatt jóval gyorsabb minden az új gépen. 4-5GB-os thunderbird fiókon a részletes keresés a ~25sec helyett ~5sec lett.
Ezekből arra következtetek, hogy a háttértár még mindig a legnagyobb hátráltató tényező általános felhasználás mellett.
Az nvidia-amd GPU váltás elvitt a Kánaánba. Minden megy rögtön és gyorsan AMD vonalon. Eddig nVidia felhasználó voltam tudatosan, már sosem leszek az (legalábbis linux alatt).
Igen, ez már eszembe jutott, hogy nekem nem biztos, hogy nvidia lesz legközelebb. :)
Az X képernyő lekapcsolásra úgy tűnik, hogy ez lesz a megoldás:
https://wiki.archlinux.org/title/Display_Power_Management_Signaling
Majd vissza:
Én úgy vettem észre, hogy 180 másodperc után nem történt semmi, a képernyő ugyanúgy bekapcsolva maradt. 5 perc után lekapcsolt a monitor. 15 perc után jött a gép suspend, amit beállítottam. <- ez most így működik.
A beállításokat le lehet kérdezni, de itt valamit nagyon nem értek:
Miután visszajött a gép, szerintem lekérdeztem a beállításokat (ezt a terminálból copy paste-ezem):
Majd hirtelen elment megint a monitor képe, és utána:
---
Wayland alatt minden oké ezzel. Ott a deep sleep nem működik. :D
Közben megtaláltam, nekem már volt egyszer a deep sleep-pel egyszer problémám: https://hup.hu/comment/3045712#comment-3045712 csak az sajnos más volt. Akkor működött minden, miután rájöttem, hogy mi van.
Wayland alatt ez kerül bele a logba, mint probléma: (journalctl)
Újratelepítettem az nvidia drivert is, nem segített.
Van a naplóban még egy ilyen is:
de ennek az átállítása sem segít. Mármint ezt sikeresen true-ra állítottam: SYSTEMD_SLEEP_FREEZE_USER_SESSIONS, de nem oldotta meg a kérdést.
Ezt a driver beállítást találtam még meg: NVreg_PreserveVideoMemoryAllocations=1 - de ez nem segít.
És úgy tűnik, hogy ez többeknek is problémája: https://discussion.fedoraproject.org/t/fedora-41-kde-nvidia-not-working… és ha jól értem AMD alatt is jelentkezik...
És furcsa, hogy Wayland alatt csak az esetek 70%-ban nem működik a suspend, a maradék 30%-ban igen.
X11 alatt működik minden, csak a resume egy kicsit lassabb: megjelenik egy egér kurzor (szinte azonnal), és onnantól kb 10 másodpercet kell várni, hogy történjen valami. Wayland alatt ha működik éppen, akkor ott nincs várakozás.
Zseniális, X11 alatt pedig valami elállítja a timeout-okat, de csak egy idő után:
xset q
...
DPMS (Display Power Management Signaling):
Standby: 0 Suspend: 0 Off: 0
DPMS is Enabled
Monitor is On
xset dpms 300 360 420
xset q
...
DPMS (Display Power Management Signaling):
Standby: 300 Suspend: 360 Off: 420
DPMS is Enabled
Monitor is On
hiába vettem fel a /etc/X11/xorg.conf.d/ alá is
Ez az, ami miatt nem használok Fedora-t: a folyamatos regressziók (általában véve is, de az ACPI S3 a leglátványosabb képviselője ennek a problémának, ugyanis ahhoz tökéletesen együtt kell működnie mindennek a rendszerben).
Fedora-val először 2010 vége felé hozott össze a sors, akkor munkahelyi gépre Fedora 13-at telepítettem. Néhány upgrade után (amelyek ismételten regressziókat hoztak be) feladtam, és áttértem RHEL6-ra; azóta RHEL7, RHEL8, RHEL9 futott nálam (most éppen RHEL9). Időközben rendszeresen olvastam a Fedora-t érintő ACPI S3 regressziókról. Érdekes látni, hogy a Fedora még most is esik-kel.
https://docs.fedoraproject.org/en-US/project/#_first
Ezért törik el mindig az ACPI S3, és ezért nem jön nálam szóba a Fedora.
Nem volt még lelkierőm, de gondolkodom rajta, hogy kipróbálom egy Debiannal, vagy Arch linuxxal. A deep sleep-et szeretném ha rendesen működne a gépemen. De pont a deep sleep arch linuxos fórumok alapján ott sem tökéletes (vagy nem volt az korábban).
A helyzet lehet összetett is, nem tudom, hogy mit gondoljak a Fedora-ról, mert az ilyen jellegű problémáknál szokott az lenni, hogy a probléma nem teljesen a Fedora-ban van, hanem félig valaki más cuccában, jelen esetben pl az nvidia driverben. Vagy akár a Wayland-ben. Ilyenkor persze senki nem érzi, hogy neki kellene javítania. Itt pont találkoznak a problémás területek: ACPI S3, Wayland, Nvidia driver. :)
Most szerintem ezt konfig fájlokkal, beállításokkal nem tudom megoldani, valószínűleg ez egy javítandó bug. És az is lehet, hogy csak az én alaplapommal jön elő, ezért már a biosban is megpróbáltam állítgatni.
Külön jó a Fedora-ban, hogy az Nvidia driver telepítés akmods-szal már nincs úgy kitesztelve, hogy mi van, ha titkosítottad a partíciót. Bootoláskor pár másodperc után feljön egy képernyő, hogy írd be a jelszavad, és ha nincs az initramfs-be bemásolva a driver, akkor szétfagy minden. Driver, vagy kernel frissítés után kézzel szoktam dracut-ot indítani, mert szerintem lefut egy initramfs generálás automatikusan is, de még azelőtt, mielőtt a driver lefordulna. Ez a fordítás is a háttérben történik, a futó processeket kell nézni, hogy mikor ért véget. :) (a secure boot is bekapcsolva van). - Na egy ilyen eset már nem működik alapból, hanem kézzel kell belepiszkálni. - Lehet, hogy ez más linux distróval is így van.
Erre a problémára: Megpróbáltam az open source drivert is, úgy sem működött. Visszatérhetek a nouveau-ra, de szerintem nem ez a megoldás. A videókártyát nem játékra, és csak képmegjelenítésre szeretném használni, hanem programozáshoz is. Szerintem ez a nouveau-val nem fog menni, inkább csak a zárt driverrel.
A technikai hiba szinte biztosan nem a Fedora-ban van. A Fedora-val sokkal inkább az a baj, hogy ha Fedora N-ben működik az ACPI S3 (esetleg miután napok alatt összereszeltél mindent), akkor majd a Fedora (N+1)-ben jól elrontják, azzal a felkiáltással, hogy "haladás" (és kezdheted előről összereszelni). Ha pedig nem akarsz frissíteni N+1-re, a regresszióktól tartva, akkor hamarosan nem fogsz bugfixeket / security fixeket sem kapni.
Stabil disztróban ez úgy néz ki, hogy a suspend vagy nem megy, vagy megy, de ha megy, akkor szinte biztos, hogy nem fogják évekig elrontani, miközben bugfixeket és security fixeket rendszeresen kapsz.
A Fedora-val nyilván nem specifikus probléma van. Ha tudnánk úgy feature-öket fejleszteni, hogy nem csinálunk bugokat, az lenne a Szent Grál. Ilyen persze nincs. Tehát a kérdés az, hogy folyamatosan az új feature-öket választjuk-e (amelyekkel megállás nélkül jönnek a bug-ok is), vagy azt, hogy a major release után lényegében csak bugfix-eket fogadunk be. Én az élet minden területén az utóbbi táborban vagyok (szinte sosem érdekelnek újdonságok; csak annyi kell, hogy amitől már függök, az ne romoljon el); a Fedora ennek a szöges ellenkezője. Ha valaki tudatosan vállaja a hullámvasutat, az rendben van persze.
Megkérdezhetem, hogy melyik disztribúciót használod? A debian talán ilyen (stabilabb) lehet, amit írtál. Én azt régebben használtam, és szerettem is. Először szerveren, de desktopon is keveset.
Ahogy fentebb írtam, most RHEL9-et (az asztali gépemen, amit csak magáncélra használok).
Igen, bocsi. :) félreértettem. Pont az RHEL-re is gondoltam, hogy egy próbát megérne, otthoni felhasználásra ha ingyen lehet használni, ha jól tudom, csak regisztrálni kell.
Szerintem a hétvégén ki is próbálom.
Ha nem akarsz licenckérdésekkel foglalkozni, akkor RHEL->Alma, és jónapot :)
Köszi. Tegnap addig jutottam az RHEL-lel, hogy regisztráltam, letöltöttem, és nincs benne BTRFS (a telepítő nem ajánlja fel). (Eddig azt használtam, de mondjuk lehet, hogy nem is kell nekem BTRFS).
Ekkor gondoltam, hogy teszek egy próbát az Arch linuxxal, hogy az működik-e. Kétféle módon tettem fel, esőre telepítő nélkül: Na ez fájdalmas volt. Ugye úgy könnyebb, hogy egy másik gépről, ahol van Internet, és tudod nézni az egyes lépéseket, onnan lépsz be SSH-val, és úgy teszed fel. De nekem ez a másik gép egy Mac-book volt, aminek hülyét kapok a billentyűzetétől, nem áll kézre.
Majd miután az első install-t szétcsesztem (secure boot beállítással, és hogy a Luks titkosításhoz a kulcsót TPM2-ből szedje) már a telepítővel (archinstall) húztam újra. Ez már simán olyan egyszerű, mint más disztribúció telepítője.
Végül arch alatt a secure boot bekapcsolása nagyon könnyű, az sbctl-t érdemes használni. Az nvidia driver is működik pöccre, és a deep sleep is. Csak itt meg úgy látom, hogy jobban járok a systemd-bootloaderrel, mint a grubbal, ez meg új nekem még.
Ha az Arch linux nem válik be valamiért (használat közben derül majd ki), akkor kipróbálgatok még párat, ahogy majd az időm engedi, a Debiant is megnézem majd, és az Alma linux is eszembe jutott már. (Alma linux helyett még Centos-t használtam korábban).