nah, 2.6.18->2.6.24.5re haladtam a korral. :)

Csupa "Spéci" dolog, de hát nekem erre van szükségem. Mindannyiunknál picit máshova tehető a "használat súlypontja". Más egy új disk_io / network driver /wireless drivernek örül, én meg ezeknek:

- acpi_pm helyett a hpet clocksource -t /rendszeridő "meghajtó"-t váltottam kb. csúnya szóval, hpet pontosabb, mint acpi_pm / :-) használom.
- Működik a PaX UDEREF funkció a suspend_to_ram-mal.
- Ha úgy adódik akkor nem csak ACPI_S3ból (szundi) hanem ACPI_S5ből (kikapcsolt) is bekapcsol megadott időre a gép (BIOS hackelés nélkül persze)

A következő problémákba/regressziókba/elintéznivalókba futottam bele a "frissítés" során:

- mindenáron tsc időzítőt akart a kernel rám erőltetni, csak az a "dinamikus" cpufrekvencia váltás miatt nem megy (cpufreq_conservative), viszont a notsc opciót ignorálta 2.6.24 kernel regresszió miatt. (?).
- ha wakealarmből tért vissza a rendszer, akkor az acpi vezérelt kikapcsológomb nem működött (nem megfelelő acpi_button kezelés, erre nem találtam megoldást egyik kernelben sem, úgyhogy itt kézzel gányoltam bele a kernelbe, lehet nem túl szépen, viszont műxik) a következő "normál" (tehát nem wakealarmos) indulásig. Gyakorlatilag csak ACPI_S3ból visszatérésnél (szundi) probléma.
- ha létezik a rtc-cmos (wakealarm), akkor nem engedi a kernel a proc/acpi/alarm-ot használni. Ez olyannyira regresszió, hogy még szándékos is, külön így került bele a kernelbe a patch. Sőt nem is kell hogy létezzen, elég ha kernelconfignál kiválasztottad, már repül is a proc/acpi/alarm. Ha pedig rtc-cmos nálad valamiért nem megy (pl. mert enhanched rtc-t használsz hehe), akkor buktad mindakettőt, mert rtc-cmos és a rtc enhanched timer ütköznek. :D

Az proc/acpi/alarm féle megoldás "ÉÉÉÉ-MM-NN ÓÓ:PP:MP" formátumot szereti, ahol 00-t is elfogadja "dzsóker" :D karakterként. Tehát ha minden nap vissza akarunk térni szundiból akkor az így megy szerintem egyszerűen és felhasználóbarát módon. :), a wakealarm ezzel szemben a sz'tem rendkívül antifelhasználóbarát date +%s formátumot fogadja el, de ezt is 7200-as csúszással (gondolom GMT +**H miatt). A proc/acpi/alarm-ot eredetileg - amikor még rtc-cmos nem létezett - szundiból suspendből való visszatérésre használták.

A rtc-cmos segítségével a rendszer képes kikapcsolt állapotból is BIOS állítgatás nélkül visszatérni. csak a sys/class/rtc/rtc0/since_epoch alapján kell egy jól irányzott

echo "UTC form. idő" > /sys/class/rtc/rtc0/wakealarm

-al

megadni, és kikapcsolás után a megadott időben a gép bekapcsol/felébred a szundiból, attól függően milyen típusú volt a rendszerleállás.

A patchnek azt a részét ami rtc-cmos esetén elrejti a proc/acpi/alarmot azt "visszaszedtem". Külön érdekesség, hogy proc/acpi/alarm írás esetén, a megadott időt a kernel beállítja wakealarm-ra is (tehát megint nem tudom proc/acpi/alarm kinek volt útban ha kötést/hookot megcsinálták hozzá).

Mégis csak jobb emberi fogyasztásra alkalmas időformátumot megadni :))

Külön öröm a kernelben a proc/acpi/-fájlok deprecatedként történő megjelentetése, az "alternatív" sysfs féle meg "Future" jelzővel, hát kösz...Ez afféle jelentéktelen közjáték de akkor is, döntsük már el hogy mit akarunk, nem (?). ;-)

Ez az automata bekapcsolós téma ilyen magamfajta tunerkártyás őrülteknek való, amikor a gépnek muszáj kicsit "öneállátónak" lennie. :D

- UTF8 erőltetés. Erre nagyon mérges voltam. Nem azért mert UTF8 a jövő, meg beteszi alapértelmezésként, hanem azért mert akkor is alapból erőlteti, amikor nem kéne. Pl. ha NLS_DEFAULTként nem UTF8at hanem valamilyen ISO-t adok meg mert nekem ez jó, akkor legyen már annyi intelligencia, hogy nem erőlteti feleslegesen. Ilyenkor nem kellene a VT_Terminal defaultot utf8ra állítani. (ugyanis ilyenkor tty1 még iso-val jelenik meg, de az összes többi újonnan nyitott terminal már utf8as). tökjó. egy vt_default_utf8=0 kernelparaméter 1ébként segített. De most így őszintén ezt 2.6.18 után nem szoptam ki a kisujjamból gugli nélkül látatlanban első blikkre. Az is kisebb "házi nyomozást" igényelt hogy egyáltalán bill. vezérlési, VT_terminálkezelési, fb buffer megjelenítési problémáról van e szó. Mert a tünetek alapján bármelyik lehetett.

/valaki küldött bele 2.6.24 rc valahányas fejlesztés során egy patchet ami egy kern config során választható opcióként adta meg a VT_TERMINAL_DEFAULTot asszem, vagy 3 nap után kidobták, de ha már belenyúltak akkor vt_default_utf8=1 et állíottak be alapértelmezésként./

Ez egyébként visszafele is probléma, tehát ha az nls_default a kernelben mondjuk iso8859-2 pl, a vt_default meg utf8 akkor tty1 iso kódolású az összes többi VT_terminal meg utf. tiszta jó logika, máris itt vannak a kezdő linuxosok számára "megmagyarázhatatlan" konzol nemzeti/ékezetes konzolos karaktermegjelenítési problémák forrásai, ha jól sejtem. ;-)

Mert most így nem néztem bele a "nagydisztrók" alap kernelconfigurációjába de nem hiszem hogy mindenhol nls_default_utf8at adtak meg a .configban (?)...

Ugyanehhez az "ótómata paraméterállítgatáshoz" kapcsolódik, hogy cpufreq használat esetén meg a tsc "clocksource"-ot erőlteti a kernel teljesen feleslegesen. Ezért kellett a notsc opció.

////

- LIRC. A bttv alrendszer ismételt átvariálása miatt ismét nem működött a lirc kernel patch. lirc ék honlapján elérhető a hiányzó/nem megfelelő definíciók pótlására szolgáló patch. Előbb ezzel a kernelt kell patchelni a bttv kódban, utána lehet a lircet külön patchelni. tök jó ez is :)

- PaX al kapcsolatosan is volt egy kisebb PAX_SEGMEXEC memóriakezelési probléma (a kernelben bekövetkezett változások miatt a segmexec szigorúbbra sikerült egy picit speciális esetben).PaXTeam a 2.6.24.5-test43-as patchben megoldotta az anomáliát (már van újabb test45ös is). Még egyszer köszönöm ezúton IS.

Sajnos a külső patchkészítőkre, akiket nem "engednek be" vanilla kernelbe, azokra rájár a rúd. :(((

////

- sensor sysfs útvonal módosítás. Apróság de meg kell említeni. A sys/devices/platform/i2c-isa/9290-9191 helyett sys/devices/platform/it87.656 lett. Inkább nem fűzök hozzá kommentárt. Igazi musthave & értelmes kategória ;-) (mégsenem tudtam megállni)

Pozitívum hogy legalább az itt található értékek sorrendjét nem piszkálták meg, csak az útvonalat. ;-)

- Oscon bootup logo. mercsak, olyan ronda vagyok hogy bootolás közbe mutogatni kell . ez van. :D

- openbsd-ből csórt hálózati randomizációs kiegészítés. mercsak. Pl. : jól nézek ki tőle szkennelésügyileg adott esetben. :D

Úgy gondolom megérte szenvedni vele, de lehet hogy utoljára :-). 2.6.18 is kiszolgált bő 1,5 évig asszem. És ha gond van, még mindig elővehetem, bár ez a 2.6.24 hivatalosan hosszú karbantartású cucc, és Ubuntu LTS is ez alapján polcolódott össze, tehát jobbak a "support lehetőségek".

Ebből a 2.6.24.y-ból is kinézek legalább 1,5-2 évet. Aztán lehet hogy véget ér a linuxos korszakom, és valami ablakos téma lesz majd utána megint, mert mást úm. nem ismerek, és nem is érzek motivációt más rendszer alaposabb megismerésére.

Sz'al a jövőben ki tudja (?). Mikor 2.4.27ről álltam át 2.6.18ra az sem ment finoman szólva simán, ahhoz képest most több bugba/regresszióba futottam bele, a tendencia egyértelműen a "linux bughalmazzá" válása felé tart - Nálam okosabb emberek (geekek, programozók, hackerek (?)) szerint már most is az. Az idézet sem saját "találmány".

Lehet mégegyszer ennek a "házi bugtakarításnak" már nem fogok nekiállni, ha alapból megy akkor jó, ha melózni kell vele, akkor gyalu...

Lehet most is hamarabb végeztem volna ezekkel, ha a magánéleti "zűrők" , problémák elkerültek volna, és nem kötötték volna le azok a szabadiőm jórészét. Lehet ezért érzem azt, hogy ez most így sok volt. Lehet azért mert se geek, se programozó , se hacker nem vagyok. nem'tom...

Öröm az ürömben hogy etch-> lenny váltásnál kernel frissítésre valószínűleg már nem lesz szükség.