Více (baterií) než jste čekali...

26.7.2008 10:39 | Přečteno: 1063× | Linux | poslední úprava: 26.7.2008 10:40

Když jsem nedávno na svém Lenovo R61 updatoval jádro a nějaké další balíčky, nestačil jsem se po již zaběhnutém po-updatovském kolotoči (spočívající v dokompilování tp_smapi a testů, jestli ještě pořád fungují oba druhy suspendů, což ještě pořád není samozřejmé) divit. KThinkBat využívající tp_smapi fungovalo opět bezvadně, zato KPowersave nějak zblblo. Přestože obě baterie (jednu mám v UltraBay) byly plně nabité, KPowersave se tvářilo, jakože celkově má k dispozici právě 36 % možné energie. Čili počítalo podle rovnice: "nabitá baterie + nabitá baterie = z pouhých 36 % nabitá kombinace baterií".

Od nějaké doby se updatů jádra bojím jako čert kříže. Zkušenosti ukazují, že kerneloví vývojáři v honbě za novými funkcemi při spravení něčeho rozbijí něco jiné. Nemám jim to za zlé, hardwaru a požadavků na user-friendly je zřejmě až příliš. Ale uživatel, který chce mít funkční stroj, si tak musel vždycky vybrat. V 2.6.23, které přišlo s Fedorou 8, fungoval wi-fi ovladač ke kartě Intel3945 podivně (a hlavně neblikal LED-kou, takže člověk netušil, co se děje). Lepší variantou byl od intelu dodávaný IPW3945, který ovšem tu a tam zpanikařil a s ním celé jádro. Výsledek: výtuh.

Jádro 2.6.24 sice přineslo funkční IWL3945, nicméně při pokusu o hotplug výměnu baterky za DVD-ROM panikaří s následným výtuhem. To v 2.6.23 fungovalo bez problémů. Takže je na výběr: buď Wifi, nebo hotplug UltraBay slot. Existuje workaround, a to sice výměna zařízení v bayi ve stavu suspend-to-disk. Ale kdo by to tak chtěl provozovat navždycky, že?

Jádro 2.6.25 stále má funkční IWL3945, dokonce funguje hotplug v UltraBay slotu. Nicméně někoho napadlo, že staré rozhraní o stavu baterie v /proc/acpi doplní novým, v /sys/class/power_supply/. Zde poznámka: tato změna prý měla nastat už v 2.6.24 jádře, kde jsem ji však nazaregistroval. Zřejmě měl v té době někdo z Fedoří komunity dost rozumu na to, aby ji do distribučního jádra nezahrnoval.

Výsledkem je, že HAL z distribuce, na nějž spolehá KPowerSave, vidí místo dvou baterií čtyři, z nichž dvě ještě navíc blbě čte. Baterie v UltraBay slotu se mu zdá "doplňková", čili plná je pro něj prázdná a prázdná je naopak podle HALu plná. KPowerSave je vcelku oprávněně zmatené a taky se podle toho chová.

A řešení? Kompilaci se nejde vyhnout. Buď se musí zkompilovat jádro a zakázat jedno z těch dvou interfejsů. S HALem verze 0.5.10 lépe to v /sys, protože toto HAL 0.5.10 stejně neumí číst správně (neboť špatně předpokládá, že dostane informaci od inotify, o něhož však nic nepřichází a nepřichází, a...). Nebo je nutné zkompilovat HAL. Verze 0.5.11 má tento problém vyřešený. A nebo, pokud chcete mít v systému (čímž teď myslím zejména ten balíčkovací) alespoň trochu pořádek, musíte použít balíčky z vývojové Fedory a přebalit je pro Fedoru 8.

Ani to není tak jednoduché, jak by mohlo vypadat. HAL-0.5.11 totiž chce (k přebalení) PolicyKit s verzí větší než 0.7 a pozor, PolicyKit s verzí větší než 0.7 požaduje HAL-0.5.11. Což je triviálně řešitelné, existují-li už hotové balíčky, horší už v situaci, kdy oba balíčky potřebujete přebalit. Postup, který fungoval je tedy přebalit a nainstalovat libsmbios z Fedory Development (o něj si řekne PolicyKit z Fedory Development), posléze přebalit PolicyKit a nainstalovat jen "natvrdo", tedy bez kontroly závislostí. No a teď je již možné přebalit HAL z Fedory Development a nainstalovat jej.

Na závěr již očekávané service haldaemon restart a KPowerSave vidí opět pouhé dvě baterie se správnými kapacitami.

Naštěstí tedy řešení existuje. Stálo mě to "jen" hodinu práce a dvě hodiny studia vývojářských mailing-listů. Každopádně si do budoucna update jádra a dalších low-level záležitostí pěkně rozmyslím. Pokud tedy nepřijdu na vlastnost, která v 2.6.23 a 2.6.24 fungovala, v 2.6.25 ale ne...

P.S. Ještě doplnění týkající se všech notebooků Lenovo ?61: Pokud si myslíte, že máte-li v systému nabitou baterii, systém je zapojen k napájení a to náhle vypadne, že budete za každých okolností v pohodě, tak se šeredně pletete. A to v případě, že máte napájení přes dokovací stanici. Chlapci z Lenova se totiž domnívají, že když vypadne napájení docku, je to z hlediska notebooku to samé, jako kdybyste mu přímo z desky utrhli třeba sériový port. Nezávisle na OS (který ani nemusí být spuštěný) laptop prostě zmrzne, rychlost procesoru vyskočí na maximum a do hodiny spotřebuje baterku. Máte-li tento problém, updatujte BIOS a v něm pak zakažte pod Config -> Docking station veškerá Legacy zařízení. Přijdete tak o sériové a paralelní port v docku, odměnou však bude to, že až zase vypadne elektřina, notebook si nenechá vaši rozdělanou práci pouze pro sebe.

       

Komentáře

[H4wk]

Muzu mit dotaz jak je to s baterkou v UltraBay slotu? Nekde jsem cetl, ze se vybiji jako prvni uplne na nulu a az pak se zacne vybijet druha baterka.

[Michal Švanda]

Je to tak. Ale dá se to ovlivnit právě přes tp_smapi, které vytvoří další interface v /sys/devices/platform/smapi a pak vždy zápisem hodnot lze přikázat nabíjení/vybíjení jedné nebo druhé baterky (a nastavit fůru dalších věcí). Nepochybně by to šlo démonizovat např. nějakým skriptem v cronu, který by mezi oběma baterkama třeba přepínal.

[Michal Karas]

Nebo to jde ovlivnit i "hardwarově". Pokud se vysune taková ta páčka, pomocí které se potom zařízení z UltraBay slotu vytahuje, tak jede notebook primárně na klasickou baterku.

[David Jaša]

Hm, s notebooky je sranda bez ohledu na distribuci. Mě fascinuje, jak se povedlo Ubunťákům rozbít suspend mezi poslední alfou Feistyho a finálním vydáním (a doteď to není spravené).

[e.lisak]

To podivné chování při vypnutí napajení v zadokovaném stavu se týká i [T,R]60