Suspend to ram vs Debian Etch

Előszőr valami 2.6.22.x-es default cuccal PaX , nvidia nélkül. persze nem műxött. s2ram -f -re elkapcsolt rendesen de már nem tért magához. video jel nem volt (-p -m - f.sz.m opciók sem segítettek). bill. mintha lett volna, de ha beírtam vakon reboot és enter nem csinált semmit. úgyhogy mégiscsak volt valami baja. log persze üres volt. mert az úgy jó. minek az ?

Következő kiszemelt, akkor az agyonpacsált "házilag barkácsolt" kernel, merthogy nekem úgy nagy általában ez "vált be".

A vanilla kernelek a "régi" debeccsel már nemigen békültek ki, lehet hogy 2.6.22 is ezért nem ment, mindegy. Pl. sysfs deprecated, meg hasonlók.

Meg hát a minőségük sem az igazi, ölég bugosak. Meg a PaX sem tud mindig rendesen elkészülni vanilla kernelhez, mert mire kiforrna mindig kijön egy új vanilla kernel "új bugforrásokkal". És akkor a 2.6.24 féle i386-x64 fúzióból is hogy mi lesz..ppff. na mindegy. ez off...

Szóval , mint kiderült a debecs kernel / agyonpacsált cucc erre épül / sem igen bír el az ilyen APCI S3 féle nyalánkságokkal. De legalább viszonylag gyorsan lehet hegeszteni.

Elsőre le se ment S3 kikapcsba, mint kiderült a PaX zavarja (agyonpacsáltban ez is van). A KERNEXEC miatt nem megy át a PM entering mem sleep ig sem. csodásan elfagyta magát, sysrq-ra sem reagált.- (s2ram -f force opció kell ugye, mert persze osconsfortress nem holmi márkás brand kész cuccos, hanem ilyen házi összevásárolt-tákolt)

/ ejj basszameg most látom írás közbe, rajtahagytam a töltőn a 700 mAh-os 2 tölthetős cuccot. még jó hogy nem füstöl /reggel kellett volna lekapni, de hát ki emléxik arra hajnali 3kor ?/. na mindegy közjáték vége. /bazmeg itt ülök mellette 4 órán keresztül és nem tűnik fel, ekkora vadbarom legyek hihetetlen/ /

Érdekes, hogy ACPI S1-be (normál standby) még elmegy az S3 (suspend to ram) már sok (itt már ugye kvázi kikapcsol a gép). S5öt nem próbáltam, mert egyrészt ehhez valami helyet kéne varázsolni, másrészt meg a mai 1 giga ramokkal szerelt kasztnikon nem látom értelmét, mert gyorsabban bebootol normálisan mintha 1 gigát vissza kell töltsön. bocs. :)

Az S3 viszont érdekesnek tűnik, noha ezt sem minden hw alkatrész támogatja / pl. a jó kis tunerkártyám ami még ACPI 1.0 korszak előtt ;-) /, meg hát vannak olyan szervízek daemonok, amelyek huzamosabb leállás után simán timeoutolnak, ezeket feléledés után újra kell indítani. Úgyhogy az össz "helyreállítás" nem biztos hogy sokkal gyorsabb mint egy normál boot, de mondjuk. (meg ugye itt a ram azért áramot is fogyaszt, bár ezt csak ki tudom hóvégén köhögni :)).

-----

Szóval akkor néztem egy kernexec (+uderef+sanitize) nélküli kernelt. egyelőre.

Nos igen, kitaláltátok szépen elfagyta magát meg minden, grafikusan sem tért magához a kis rohadék.
egy kb. 3 msp-ig ment a szekér, aztán vinyóreszelés, és sysrq-ra sem reagál. maradt a reset gomb. Log persze üres, mert ilyenkor az a baromi jó. (igen debug opciók voltak, ki is törölhettem velük.)

Akkor marad a józan vodkatoniccal terhelt paraszti ész, úgyhogy bevettem magam a túrkálóba (git), patchek után kotorva, nyílván nem én vagyok az első szerencsés bugnyertes.

Előszőr mindjárt kipécéztem a vinyó (IDE) körüli dógokat, mert a vinyó igen lassan tért magához , mindjárt szemet is szúrt hogy bekerült 2.6.18 után valamikor egy / * / IDE ACPI Support azzal a jeligével hogy modern gépekhez S3hoz ez kell. HOgy mi kell ahhoz hogy modern legyen azt a patchkészítő nem részletezte, mindenki képzelje el magának. Úgyhogy beképzeltem, hogy modern gépem van és gyorsan backportoltam a motyót. És akkor megnézzük így hogy fest a jószág. meg pakoltam pár egyéb sleep bugfixes backportot is hozzá ami első olvasatra jónak tűnt.

Igen eltaláltátok, most is ugyanúgy reszelt, bár nem annyira "meredeken" hogy abszolút szaxerűtlenül fogalmazzak, most is elfagyott, b....tt működni, de már legalább grafikusan is feléledt, így már láttam valami log jellegű dolgot. A reszeléssel párhuzamosan az MCE is működésbe lépett hogy rohadjon meg, és lelőtte a kernelt. anyád. ponthu. google mit mond? hardverhiba. na persze...

reboot mce nélkül...ill. athlon/duron MCE nélkül, mert ugye athlon64 van. :) / ennyi elkurás részemről belefért ;-) / és milyen érdekes, a "normál" nemspéci MCE most már szerette.

Kezdtem örülni, hogy akkor most majd végre ha lassan is , de MCE nélkül magához tér az S3ból.

Hát a kernel nem így gondolta, úgyanúgy elfagyott csak hagyott ügyködni 3 msp*-ig, De hogy legyen elég bajom, még ebbe a bugba is beletaknyolt, és mivel vinyó nincs, így nem írt logot, maradt a "bámuld a screent te marha" c. műsor, ami ezzel a jó kis "atkbd-s" buggal párosítva nagyon élvezetes volt, fél perc alatt teleírta a képernyőt a spurious baromságával. úgyhogy éppen ki tudtam venni egy pillanatra, hogy a vinyónak dma timeout baja van, meg az i2c szekció sem tért magához (-error 201 ha jól emléxem).

Úgyhogy vissza a turkálóba, és akkor folytattuk a backportolást, jöttek a Fix MSI-X crash, meg IDE csipszet frissítés, meg ide io fixek, meg i2c suspend/resume support (nem fix, support!), és akkor nekilódultam mégeccer. más baja már csak nem lesz.

És láss csodát ez a móka már szépen műxik. most e sorok írásakor is kipróbáltam másodszor. mert ugye van amikor elsőre magához tér a kaszni, aztán többet már le sem hibernol... de most már ment másodjára is.

már csak a PAX_KERNEXEC-el kéne valamit csinálni... :)))

Amúgy a tunerkártyát kivéve minden macera nélkül működik. (igen a forcedeth meg az ALSA is!) a bttv-re aszongya hogy Can't enable device... ugye ő még őskori lelet, acpi-t nem ismeri. lirc_gpio -t lirc_dev-et és bttv modulokat ki+visszatöltve már jó volt.

meg ad egy darab fals (?!) üzenetet hogy nem tudja az egyik "cooling device-"-t bekapcsolni, de a sensor, meg a "ricsaj" szerint viszont gond nélkül műxenek a ventik. bár a sensor mindig keresi a fan2-s cuccot, de olyan itt nincsen. lehet ez a baja (meg nem mondom a hexa kódból). meg hát ez nem lop-stop hátizsák, hanem mezei desktop kaszni.

Na ennyi lett volna. :)