Egy friss telepitesu Arch Linux-os laptoppal van olyan problemam, hogy nem akar lealudni. Eljutunk a kepernyo elfeketiteseig, a billzet nem is reagal, de az ACPI alvas nem kapcsol be.
Annyival probalkoztam csak eddig, hogy felpattintottam az LTS kernelt, mert a wiki azt irta, az ilyesmit az megoldja. Hat nekem nem.
Elkepzelheto, hogy valamit meg pluszban engedelyeznem kell a SystemD-ben (vagy mashol) h ez mukodjon? Ubuntu, openSUSE, Gentoo alatt ez nem volt gond.
A gep egy Lenovo B50-es laptop, Pentium N3540-es procival meg 8G RAM-mal szerelve. Jelenleg nincs hibernalos particio konfiguralva, az most nem is kell, nekem egyelore eleg lenne, ha a suspend-to-RAM mukodne.
Update: Korbeprobalkoztam par dologgal, es fura dolgok ugrottak ki. Pl. nem megy a gepnek a reboot se nagyon, legalabbis leallni leall, el is fekedetik a kepernyo, de ujra nem bootol. Es ez is csak Arch-specifikus problema. Valami mintha nem lenne koser az ACPI korul, de nem birok rajonni, micsoda, ilyen allatot meg sose lattam. Eleg sok disztro megfordult mar a gepen, volt mindegyikkel kisebb-nagyobb bajom, de az alapveto dolgok minddel mukodtek. Tenyleg, sracok, segitsetek, biztos valamit en nezek el, de mit?! Ez a nyuves SystemD szomoritja meg az eletemet? Vagy mi a rak?
Hozzászólások
Szia! Próbáld meg az /etc/default/grub-ba a GRUB_CMDLINE_LINUX="" közé beírni, hogy resume=/dev/sdXX. Gondolom az XX helyére tudod, hogy mi kerül.
Tudom, de az a suspend-to-disk-hez kell, és jelenleg nincs olyan diszkem, amit a sdXX helyére beírhatnék, ahhoz még kell egy takarítás. De a suspend-to-ram -nak ettől független mennie kellene...
--
Blog | @hron84
Üzemeltető macik
Ok, figyelmetlenül olvastam el, bocs. Akkor csak a wikit tudom ajánlani. https://wiki.archlinux.org/index.php/Uswsusp
90%-ban ez is a hibernációról ír, a suspendről csak annyit, hogy ha nem működik, akkor próbálgassak opciókat. Ezzel csak két bajom van: 1) ötletem sincs, hogy mit használ a MATE, én konzolból még sose akartam sleepelni 2) és ötletem sincs, hogy lehetne ezt konfigurálni a MATE-ban és 3) nem akarok konzolrol sleepelni soha.
--
Blog | @hron84
Üzemeltető macik
En N2940-et hasznalok, nem szoktam altatni a gepet, igy ez nekem nem is volt szempont, csak a hibernalas, bar azt sem hasznalom. Viszont most kiprobaltam, nekem elpakolja aludni a gepet, es szepen vissza is jon.
Az acpi csomag telepitve van, tovabba az Arch Wiki ajanlasai alapjan szoktam telepiteni, azon kivul nem csinaltam semmit extrat.
En megprobalnek egy BIOS update-et, ha van ra frissebb.
Szerk: nalam XFCE4 megy.
--
http://www.lulu.com/shop/search.ep?contributorId=1386424
BIOS nincs frissebb, ezt mar akkor megneztem, mikor vettem a gepet...
En az arch-chroot csomagbol szoktam osszepakolni a rendszert, de mivel a telepitesnek resze egy komplett rendszer-reinstall is (bar ezt en mar az elo rendszerbe valo atbootolas utan intezem), ezert nem gondolom, h ez gond lenne. Meg a suspend elegge kernel-dolog, azt meg en rakom fel ujonnan mindig.
--
Blog | @hron84
Üzemeltető macik
az ilyenekkel kell kezdeni, hogy echo mem > /sys/power/state, ha ez megy, akkor a kernel rendben van, lehet keresgelni tovabb
Ezt nem kapja el a systemd, egybol le kell neki aludnia?
Szerk: nuh, kiprobaltam ezt a cuccost, nem mukod. Hogy tovabb?
--
Blog | @hron84
Üzemeltető macik
Hali,
én sem állítottam be semmi extrát, minden a legfrissebb (nemrégiben telepítettem) és egyből ment. Ha valami check kell, szólj és megnézem nálam, de ötletem sincs, hogy mi lehet.
Plasma-t használok.
Szerdai telepites, szoval eleg friss.
--
Blog | @hron84
Üzemeltető macik
Miért írok én blogot, ha nem olvasod? ;)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Ize. Eloszor is, koszi a tippet, megnezem majd ezt is, de megprobalom elismetelni: jelenleg a suspend-to-disk is mukodeskeptelen, espediglen okkal, ugyanis meg nincs elokeszitve a hibernacio szamara a resume particio (ezt passzolnam le a resume= parameternek), ez egy ismert problema, amin majd dolgozni fogok. Azonban nekem a suspend-to-RAM se mukodik, ami - legalabbis tudtommal - egy ettol fuggetlen alrendszer, a s2ram -nak attol fuggetlenul mukodnie kellene, hogy a s2disk nem megy.
--
Blog | @hron84
Üzemeltető macik
Tudom, el szoktam olvasni a bevezetőt. Viszont a blogban említett manual page-ben van szó suspend-ről is, nem csak a hibernálásról.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Updateltem a bevezetot, alapvetobb bajok lesznek errefele. Illetve megneztem, h a /sys/power/state milyen ertekeket vehet fel (mem, freeze, disk), es egyikkel se mukodik a dolog (a disk-et ertheto okokbol nem is probaltam). Az a baj, hogy ez az egesz annyira meggebed, hogy ne lehessen debuggolni, de annyira nem, hogy legalabb leloje magat a picsaba.
Teljesen ertetlenul allok a problema elott, olyan disztro meg nem volt a kezem alatt, ami legalabb ujra ne tudta volna rugni a gepet. Es mondom, mas oprendszerrel, mas disztroval nincs ilyen bajom, par napja rugtam ki az openSUSE-t, azzal se volt ilyen gond, de elotte a Gentoo se nyavalygott ilyen aprosagon. Tuti valami alapvetot bokok el, de otletem sincs mit.
--
Blog | @hron84
Üzemeltető macik
A kernelparamétereket nézd még meg, illetve a kernel dokumentációjában azt, hogy milyen paraméterek, s azok milyen értékei lehetnek relevánsak.
Szerk.: tölts le egy kernel forrást, majd például a linux-4.2.6/Documentation/kernel-parameters.txt érdekes lehet. Úgy látom, még az sem kizárt, hogy induláskor az első 64 k RAM-ot széttúrja a BIOS, persze a kernellel ebben az esetben is lehet egyezkedni. :)
memory_corruption_check=0/1 [X86]
Some BIOSes seem to corrupt the first 64k of
memory when doing things like suspend/resume.
Setting this option will scan the memory
looking for corruption. Enabling this will
both detect corruption and prevent the kernel
from using the memory being corrupted.
However, its intended as a diagnostic tool; if
repeatable BIOS-originated corruption always
affects the same memory, you can use memmap=
to prevent the kernel from using that memory.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE