Newsshake: Linux 2.6.21, fglrx + swsusp, tifm

29.4.2007 12:19 | Přečteno: 1265× | Linux | | poslední úprava: 29.4.2007 12:32

Myslím, že by to bolo príliš dlhé, dať to do správičiek - takže tu je nejaké zhrnutie vecí, ktoré som našiel na nete dnes, pri nezáväznom hľadaní riešní mojich problémov s 2.6.20kovým jadrom (varovanie: okrajovo súvisí s feistym :o)).

Po prechode na Feistyho, pomocou upgrade skriptu, som okrem o 10-15 sekúnd dlhšieho bootu objavil aj pár regresií na mojom noťase, ktorých riešenie ešte nie je zďaleka konečné - ale aspoň sem poznamenám pár zaujímavých informácií pre ľudí, ktorých by to mohlo zaujímať. Väčšina z týchto problémov asi nie je spôsobená feistym ako takým, ale skôr prechodom na jadro 2.6.20. Hádam, že keby boli ubunťáci posunuli vydanie tak, aby stihli 2.6.21ku, asi by toho bolo ešte viac... Hlavne, keby použili zaujímavú ale asi aj dosť veselú (čo sa následkov) týka možnosť NO_HZ. Ale k veci... Teda, veciam, a od konca..

Tifm / čítačka SD/MMC/MS kariet Texas Instruments

V mojom noťase (prestigio 1530) sa nachádza čítačka, ktorá sa hlási pod linuxom ako
Generic system peripheral [0805]: Texas Instruments PCI6411/6421/6611/6621/7411/7421/7611/7621 Secure Digital Controller.
História jej fungovania na mojich doterajších systémoch je veľmi zaujímavá. V Dapperovi fungovala, pomocou driveru SDHCI. V Edgym prestala a po nejakých pár týždňoch som prišiel na to, že po pridaní modulu tifm_7xx1 to znovu funguje. SDHCI je totiž ovládač pre štandardizované rozhranie čítačiek SD kariet, kým Tifm je určený priamo pre dané TI modely čítačiek (má to niečo spoločné s rôzne napájkovanými pinmi.. nebudem radšej písať, ako presne to je, už si to nepamätám a asi to je aj tak fu(c)k :o)). A v edgym zrazu kernel pomocou modulu SDHCI čítačku ignoroval - až tifm to zase dala do poriadku. Viac-menej. Skôr menej

Ďalšia "zaujímavosť" je, že medzi jadrami 2.6.15 (dapper) a 2.6.17 (edgy) došlo aj k úpravám v ovládačoch VFAT filesystému a zrejme aj bufferovania. A to k dosť nepríjemným - fat začala využívať buffer iným spôsobom ako predtým - problém bol, že tento spôsob bufferovania dosť nevyhovuje (niektorým) flash médiám. Napríklad moja čítačka, ktorá predtým dosahovala pri zápise 1-3 MB/s, po novom zvládala tak 50 kB/s (čiastočene asi aj vďaka very-much-work-in-progress tifm modulu). S plným vyťažením procesora. Riešenie "vraj" spočívalo v nastavení sync módu. Pár ľudí to risklo a následne (po pár-stonásobnom prepísaní častí fat tabuľky a následnom fyzickom zničení danej časti flash pamäti) kupovali nové médiá Takže, v edgym som bol zmierený s používaním externej čítačky na SD karty.

Čítanie však fungovávalo (aspoň do hibernácie notebooku) aj cez internú čítačku. O to väčšie prekvapko ma čakalo vo feistym, keď už nefungovalo ani len to. Ani cez SDHCI ani cez Tifm. To už na mňa bolo fakt veľa. Veľmi "rád" sa rozruším a hovorím o ľuďoch čo sú schopní takto zničiť predtým funkčný kód nelichotivé veci. Ale holt, občas som tá nelichotivá vec aj ja Zabudol som totiž modprobnúť modul tifm_7xx1, probnul som len tifm_sd. Kým som na to prišiel, prešiel som 15 000 fór (tak ako naposledy, keď som zisťoval, čo použiť miesto sdhci :o)), stiahol balík so zdrojákmi priamo od "výrobcu ovládača", skompiloval... Atď, atď... Ako hovorí jeden známy - som amatér, som sa tiež mohol najprv pozrieť na svoj vlastný wiki záznam

BTW: čo sa týka tifm modulu, tak v jadre 2.6.21 bola pridaná podpora pre jeho uspávanie. To asi znamená, že teraz nefunguje. Bohužiaľ to zatiaľ v 2.6.20 neviem spoľahlivo overiť, lebo viď nižšie :o)

Fglrx vs. swsusp

Druhá regresia, ktorá sa mi neviem z akéhosi dôvodu začala prejavovať až v 2.6.20 jadre je, že mi nefunguje sw suspend. To je na notebooku dosť nepríjemné - keď miesto 20-25 sekúnd systém bootuje vyše minúty (snáď aj 1.5), kým sa prestane "hýbať disk". Po prejdení niekoľkých fór som narazil na diskusiu v kernel mailliste, ktorá viac menej vysvetľuje, prečo to nefunguje.

Kto by čakal, že problém je znovu v binárnych ovládačoch - správne, chyba je v binárnych ovládačoch, konkrétne fglrx. V jednom z posledných krokov uspávania systému (potom, ako sa už uvoľnil dostatok pamäti) si totiž vyžiadajú relatívne veľké množstvo pamäti - čím efektívne zabránia uloženiu systému na disk a jeho vypnutiu. Riešenie je, z toho čo som pochopil, používať suspend2, ktorý má uspávanie vyriešené inak. Pravdepodobne (neprezeral som si archív git commitov ) sa pracuje aj na úprave niektorých štruktúr jadra tak, aby sa s takouto alokáciou pamäti dokázalo vyrovnať aj so swsusp (napr. tak, že by ovládač oznámil túto budúcu alokáciu dopredu). Binárne ovládače rulez

To by bolo na dnes alles... Aby som nezabudol, ospravedlňujem sa za prípadné chyby a nepresnosti

       

Komentáře

[johniez]

Suspend2 je pekna vec, ale pro zmenu na jadre suspend2-sources-2.6.19 nejede kvuli nejakejm patchum fglrx modul :) Ale ted koukam, ze vcera vecer konecne pribyl suspend2-sources-2.6.21 a 2.6.20 odmaskovali, tak konecne to snad pujde..

Jinak Ubuntu jsem se rozhodl z notase odstranit a nechat jen gentoo, na Daperovi se mi libilo ze fungovalo prakticky vsechno samo a mel jsem ho tam kdybych neco v gentoo pokazil :)

Po upgradu na Feisty nefunguje skoro nic, navic je to silene pomaly a gentoo uz chybi jen krucek k dokonalosti, kdezto s Ubuntem bych se zase patlal na coz neni moc cas..

Feisty je pro me zklamani..