Jaderné noviny 297

22. 2. 2005 | Robert Krátký

Články - Jaderné noviny 297  

OOM Killer v uživatelském prostředí. Linux 2.6.11-rc2; nefunkční VMware. Linux 2.6.11-rc2-mm1; problémy s AGP. Stav podpory 802.11x.

OOM Killer v uživatelském prostředí, 70 e-mailů

10. led - 28. led

Mauricio Lin napsal: Provedli jsme srovnání verze v jádře a v uživatelském prostředí a zjevně se to chová podobně. Chcete-li si srovnání s jadernou verzí OOM Killer [OOM - Out Of Memory = vyčerpaná paměť, killer = zabiják] udělat sami, stáhněte si patch a modul. Marcelo Tosatti to považoval za zajímavé, i když samotný kód nekomentoval: OOM Killer v uživatelském prostředí je však nebezpečný. Musíte zaručit, aby k alokacím nedocházelo před spuštěním OOM Killer a než bude zabíjený proces mrtvý a jeho stránky uvolněné - alokace pod OOM mohou způsobit zatuhnutí. OOM Killer v uživatelském prostředí je nespolehlivý a nejsem si jist, jestli stojí za tu námahu jej předělávat na spolehlivý.

Ale pak odpověděl sám sobě: Vlastně je to nespolehlivé jen tehdy, když je volán z OOM. Vy ale v tomto případě máte démona, který periodicky zapisuje do /proc/oom? Mauricio odpověděl: Ano, vysvětlím. Dosáhne-li spotřeba paměti 98 procent nebo tak podobně, nazýváme to červenou zónou. Když je dosaženo červené zóny, spustí se hodnotící algoritmus, který zvolí, jaké procesy mohou být zabity, dojde-li k OOM. Je-li spotřeba paměti pod touto hranicí (ne v červené zóně), nebude hodnotící algoritmus spuštěn. Takže máme cyklus, který kontroluje využití paměti, a je-li dosaženo červené zóny, je hodnotící algoritmus spuštěn ještě než se dostaneme do stavu OOM.

Edjard Souza Mota také poukázal na to, že tento patch přesouvá do uživatelského prostředí pouze hodnotící algoritmus, ne samotného "zabijáka": Díky tomu jde o jiný přístup a může stát za to jej vyzkoušet - především kvůli případům, kde chceme umožnit lepší hodnotící pravidla. Například v embedded zařízeních s málo zdroji a několika důležitými spuštěnými aplikacemi: která je nejlepší? Chápu-li to správně, tak současný způsob hodnocení si moc nevybírá, kterou aplikaci by bylo zrovna nejlepší zabít. To Marcelovi připadalo rozumnější a měl pocit, že v tom případě stojí patch za zvážení.

Linux 2.6.11-rc2; nefunkční VMware, 26 e-mailů

21. led - 27. led

Linus Torvalds oznámil Linux 2.6.11-rc2: OK, zkouším to opět uklidnit před vydáním 2.6.11. Máme tu hromadu malých pročištění, anotací a oprav. Aktualizace ovladačů, cpufreq, PPC, PARISC, ARM, ... Zkontrolujte, prosím, jestli mi něco neuniklo. Udo A. Steinberg poslal hlášení o chybě při kompilaci netfilter, kterou Martin Josefsson diagnostikoval a opravil. Udo na Linuse naléhal, aby patch přijal, ale Linus odpověděl: Jděte s tím, prosím, přes Davea M. Odpoví vám rychle, ale je radši, když podobné věci nejdříve projdou přes konferenci netdev - pokud tam už nebyly (netdev@oss.sgi.com).

Jinde napsal Sytse Wielinga: Mohl bys, prosím, vrátit zpět skb_copy_datagram? V jádře už se to nepoužívá, ale modul vmnet (ve VMware) to rozhraní pořád využívá k skb_copy_datagram_iovec. Poslal patch, ale Christoph Hellwig odpověděl: Spíš sprav VMware. Nebo upgraduj na opravenou verzi..

Linux 2.6.11-rc2-mm1; problémy s AGP, 132 e-mailů

24. led - 27. led

Andrew Morton oznámil Linux 2.6.11-rc2-mm1:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc2-mm1/

• Všude spousta aktualizací a oprav.

• Na mém testovacím stroji není v konzoli blikající kurzor. Vím o té chybě, nehlaste ji, prosím.

  Ukázalo se, že tu chybu má na svědomí cleanup-vc-array-access.patch, ale jedná se bohužel o obrovský patch.

Brice Goglin hlásil:

Na mém Compaqu Evo N600c (Radeon Mobility M6 LY) přestalo fungovat X, je-li zapnuto DRI. Moje XFree 4.3 (z Debianu testing) s DRI používá drm a radeon moduly z jádra.

Místo běžného okna gdm se objeví černá nebo zrnitá obrazovka (zbytkové kusy obrazu z posledního funkčního sezení). Kurzor myši funguje. Sysrq funguje. Ale Caps-lock ne. Mohu pingnout, ale ne připojit přes SSH.

Nevím přesně, co se to děje. V dmesg nic zajímavého nevidím. Odstranění DRI z konfiguračního souboru X (i když jsou i nadále natahovány moduly drm/radeon) to spraví. Linusův 2.6.11-rc2 funguje bez problémů.

Florian Bohrer hlásil stejný problém s ovladačem od nVIDIA: Vypadá to, že vůbec nefunguje AGP. Poblíž se k odpovědnosti přihlásil Dave Jones a požádal, aby byla aktualizace agpgart-bk prozatím vynechána. Za pár hodin poslal patch, ale dodal, že ještě nejsou vyřešeny všechny problémy. Brice patch vyzkoušel a hlásil 100% úspěch. Nabídl pomoc s dalším testováním a Dave prohlásil: Je docela s podivem, že to vůbec funguje.

Stav podpory 802.11x, 3 e-maily

25. led - 28. led

Dan Williams napsal:

Tento seznam věcí, které by měly být v Linuxu opraveny v oblasti podpory wireless [bezdrátová komunikace], vznikl díky mému pokusu o vytvoření GUI pro linuxovou bezdrátovou komunikaci - NetworkManager (http://people.redhat.com/dcbw/NetworkManager). Nejde samozřejmě o nějaký seznam požadavků. Sám pomalu některé věci opravuji, když se k nim dostanu (začlenění orinoco, opravení linux-wlan-ng, malé patche pro jaderný wireless ovladač). Myslím, že nikdo zatím nesestavil vyčerpávající seznam problémů s wireless v Linuxu.

Řekl bych, že největším problémem je stagnace API Wireless Extensions [rozšíření pro bezdrátovou komunikaci] a autoři ovladačů proto dělají věci po svém (například podporu WPA), protože WEAPI se v této oblasti neprojevuje jako vůdce. To lze napravit. A v tuto chvíli to nevypadá ani na moc práce, protože hlavním provinilcem je tu WPA.

Komentáře vítám. Doufám, že to vyburcuje více lidí ke snaze o opravení aspoň nějakých věcí.

Takže, bez dalších okolků, zde je ten seznam:

• Hodnoty kvality se výrazně liší nebo úplně chybí:

  1. atmel nevrací ze scanovaných [vyhledávaných] AP žádná data o kvalitě.
  2. ipw_2100 nevrací vůbec žádná data o kvalitě (v1.02).

  3. Téměř každý ovladač hlásí kvalitu jiným způsobem:

     • Prism54 používá procenta.
     • airo míchá používání absolutních a relativních hodnot v dBm.
     • Průměrné a maximální úrovně kvality jsou skoro u všech ovladačů umělé a vůbec nevychází z karty.

  Je třeba udělat: sjednotit hodnoty kvality. Wireless Extensions podporují dva různé druhy dat o kvalitě - procentuální a dBm. JEDNO VYBRAT. Já bych doporučoval do uživatelského prostředí hlásit pouze procenta pomocí volání SIOCGIWSTATS. A pro získávání specifických hodnot dBm/šumu bych použil samostatná ioctl - bude-li to uživatelská aplikace _a_ ovladač podporovat. Nemůžeme po uživatelských aplikacích chtít, aby hádaly, podle kterého ze tři různých algoritmů ovladač kvalitu hlásí.

• Hodnoty frekvence se výrazně liší od iw_get_range:

  1. Prism54 používá úplně jiné exponenciální hodnoty než airo.
  2. Airo, atmel a orinoco jsou stejné.

  Je třeba udělat: sjednotit hodnoty frekvence u všech karet. Používat skutečné frekvence v MHz místo formátu "exponent a mantisa" jak je tomu nyní. Donutit uživatelské aplikace ke konvertování kanálů na frekvence - podle toho, jaké frekvence ovladač podporuje. Nebo opravit ovladače tak, aby hlásily dvojice Frekvence<->Kanál, když oznamují podporované frekvence. Ale podstatné je vybrat JEDEN ZPŮSOB a všechny ovladače přizpůsobit. Zbavit uživatelské prostředí hádanek a zvolit jedno API, které budou ovladače používat.

• Airo/prism54 mají asi problémy s IPv6 a způsobují paniku jádra.

  1. Některé ovladače nevymažou [NULL] svá data po té, co s nimi skončily, což později způsobuje paniky jádra. Viz Red Hat bugzilla #135432. Dave Jones má patch pro airo, který - jak se zdá - funguje lépe - je v jádrech 2.6.10 od Red Hatu.

  Je třeba udělat: zajistit, aby všechny ovladače při uzavírání likvidovaly svá data. Nebo opravit ty části jádra, které ta stará data využívají. Prostě přijít na to, kde je problém.

• Ne všechny ovladače mají správnou podporu netlink:

  1. Orinoco je příliš neposedný, posílá moc událostí (neměl by je např. posílat během scanu).
  2. Atmel, airo a další asi nemají podporu netlink vůbec.

  Je třeba udělat: opravit všechny ovladače tak, aby po úspěšném připojení k přístupovému bodu daly jádru signál, že síťové spojení je "up" [nahozeno].

• Ne všechny ovladače podporují bezdrátové scanování:

  1. Především orinoco - podpora už je napsána a pomalu se dostává do jádra.

  Je třeba udělat: urychlit začlenění nového ovladače orinoco do jádra.

• Problémy s firmwarem

  1. Nahrávání firmwaru Cisco aironet je dost nestálé. Např. s verzí 5.21 selhává. Vypadá to, že pro používání WEP je u většiny přístupových bodů potřeba firmware <= 5.02. Poslední ovladač od Cisco se od toho v jádře dost liší.

  Je třeba udělat: vyřešit licenční vztahy mezi ovladačem od Cisco pro jádro 2.4 (který je pod MPL) a ovladačem airo v jádře (který je pod GPL). Pak zjistit, jakých změn se dočkal ovladač od Cisco, aby podporoval firmware až k verzi 5.30.17, a provést tyto změny v ovladači z jádra.

• Podpora ethtool pro všechny ovladače:

  1. Hodně jich udělal Viro, nejsem si jistý, jestli je to dokončené.

• Podpora Ad-Hoc režimu je ve většině ovladačů buď dost nestabilní nebo úplně chybí:

  1. Prism54 hlásí chybu "mgmt tx queue full" na jinak funkční kartě.
  2. Madwifi při přepínání do ad-hoc režimu resetuje bitrate na 0.

  Je třeba udělat: opravit ovladače, aby podporovaly Ad-Hoc režim. Pokusit se od výrobců získat specifikace hardware a registrů - pokud to ještě pro všechny "moderní" karty nemáme.

• Podpora WPA buď chybí nebo se na ní teprve pracuje. S tím je potřeba pomoci.

  1. Věc se má tak, že Wireless Extensions API výrazně zaostává za možnostmi dnešních čipsetů. Podpora pro WPA a příbuzné technologie by měla být _ve_ Wireless Extensions, místo toho, aby to fungovalo jako teď, kdy většina ovladačů pro WPA nastavení vyčleňuje nestandardní privátní volání ioctl().

  Je třeba udělat: standardizovat rozhraní pro WPA a příbuzné technologie a implementovat to rozhraní ve Wireless Extensions API. Opravit všechny ovladače, aby používaly nové API místo privátních volání ioctl(). Některé z ovladačů. které WPA podporují: atmel, madwifi, prism54, ipw2200. Rovněž by při té příležitosti bylo prospěšné zavést podporu pro volání, která potřebují 802.1x stacky (jako wpa_supplicant a Open 802.1x). Aby nemusely ovladače patchovat (Open 802.1x). Nebo vytvářet speciální háčkové moduly pro každý ovladač (wpa_supplicant), díky kterým mohou zachytávat potřebné autentizační pakety nebo nastavovat WPA na kartě.

• Se skrytými ESSID ovladače zacházejí každý jinak.

  1. ipw2x00 zachytí " " a skupiny \0 a a změní to v ovladači na "<hidden>", zatímco ostatní ovladače jen předají prázdný řetězec.

  Je třeba udělat: standardizovat všechny ovladače, aby do uživatelského prostoru pouze předaly prázdný řetězec - pokud stanice nevysílá ESSID. Ovladače by se neměly snažit být v této věci chytré.

Pořadí důležitosti (podle mě):

1. Všechny ovladače _MUSÍ_ podporovat bezdrátové scanování (že, orinoco?).
2. Podporu WPA je třeba standardizovat ve Wireless Extensions.
3. Jednotné údaje o kvalitě od všech ovladačů - jak o právě připojených AP, tak o scanovaných.
4. rtnetlink oznámení o spojení od všech ovladačů při připojení k AP.
5. Podpora Ad-Hoc režimu.
6. Podpora Ethtool.
7. Otázky kolem firmwaru Cisco.

---

V originálu Kernel Traffic 297 vyšla navíc ještě tato témata:

• Removing eepro100, xircom_tulip_cb, And iph5526 Drivers
• usbutils Version 0.70 Released

Tento článek vychází ze seriálu Kernel Traffic (www.kerneltraffic.org) a je zveřejněn pod licencí GPL verze 2.

Diskuse k tomuto článku

[lyon]

Bohuzel musim souhlasit s neutesenym stavem u wifi - chybejici monitoring u nekterych cipsetu (napriklad jiz docela staricke orinoco se stale musi patchovat), udaje o sile signalu jsou casto vice nez zmatecne a cpani vseliceho nemozneho do private ioctl() je taky k vzteku. Takze jsem docela rad, ze se tim nekdo zacal zabyvat :)

[Michal W]

kde můžu najít patche pro orinoko, trapím se s tím už pár dní, a pomalu začínám docházet k závěru že se vrátím k 2.4 jadru. Mužete mi někdo poradit co s tim? potřebui scanovat........

[Libor Klepac]

zde

http://www.nongnu.org/orinoco/

cely ovladac.. staci prelozit mimo jaderny strom (samozrejme musis mit nakonfigurovane jadro)

[lyon]

http://www.kismetwireless.net/HOWTO-26_Orinoco_Rfmon.txt

http://www.kismetwireless.net/HOWTO-orinoco-drivers.txt

http://www.kismetwireless.net/code/orinoco-0.13e-rfmon-dragorn3.diff

[Pavel Dobeš]

Já nevím, asi jsem už tou angličtinou zkažen, ale překládat 'kernel panic'? Ale je to je pouze IMHO.

PaD

[Robert Krátký]

Jo, také si tím nejsem 100% jistý, ale vycházím z toho, že ačkoliv "panika jádra" nezní úplně ideálně, mělo by to být srozumitelné pro oba "tábory".

[Zdeněk Burda]

Panika jádra je IMHO v pořádku, ale stejně to překládám jako kernel je panic

[Hynek (Pichi) Vychodil]

Tak to překládáte špatně, to by tam muselo bý kernel is panic. Kernel panic lze přeložit jedině jako panic of kernel a tedy jaderný panic

[David Jež]

Osobne pouzivam hlasku ze kernel je panic... Ale ,,zpusobuje paniku jadra`` je takove dost umele sroubovane z anglictiny, ceske ,,zpanikari jadro`` je myslim take srozumitelne a mezi linuxari hojne pouzivane takze se snad zavdecis vsem taborum .
-djz

[AstorLights]

Kernel Panic
==================================
Zas Kernel Panic - není to lehký,
Linux je nanic, snad jen pro děvky,
ale i tak je, to systém křehký,
a víla kterou stvořil jsem si v hlavě,
abych o ní mohl mluvit, před klukama,
Co s ní dělám, v noci i zrána,
je pořád se mnou, zkompilovaná,
Kluci všechno sežerou mi zruky zobou
nafouk jsem jim hlavy,
ó to mě baví, ikdyž mám panic, a to mě trápí
kdy už to skončí, půjdu se opít, o ó ó...

Ptali se mě jestli jsem už něco měl s nějakým -nixem,
a já jim řek, že jasně
ptali se mě kolik jsem jich snažil poznat
a já jim řek, že spousty
ptali se mě co jsem s nima dělal
a já jim řek, že úplně všechno
řekli mi: Tak to už jseš teda velkej chlap
a já jim řek, no jasně...

[Zdeněk Štěpánek]

Zdravim

Naprosty souhlas s WiFi. Proste co ovladac, to jine rozhrani. Nekterej vraci v iwconfigu frekvenci, jinej kanal, jeden dava signal v dBm (xx/92), jinej soft zase jiny cisla, dalsi vraci procenta (paneboze jenom to ne, to je blbost na entou). No proste zmatek.

Ale budme radi ze to chodi tak jak to chodi, konkurence co ma i na serverech mys je na tom jeste hur.

Zdenek

[David Jež]

Vracet procenta je demence, ale pokud to tak ma hlasit nejaky user space metr pro lusery a iwconfig vrati dBm tak proc ne. Je v tom chaos ale na druhou stranu stale by mohlo byt hur, pokud se povede ozivit wireless extense jako standard tak to bude uplne nejlepsi.

Chaos uvedeny v clanku mne osobne nedrti tolik jako nepouzivatelny bordel v linux-ng pro prismy, to fakt neni rozhrani. Kdyby misto toho pouzivali treba prikazy jako hexa udelali by lepe, bylo by to stejne srozumitelne a hlavne kratsi . Toto je IMHO hlavne vec, ktera musi chcipnout ze vseho nejdriv a pokud mozno hned .
-djz

[Zdeněk Štěpánek]

Heh?

A co te nuti pouzivat linux-wlan-ng? Ja pouzivam hostap 0.1.0 a nemam sebemensi problemy. A ze tech 626tek tady mame.. Pres hexa nastavuju vykon, ale je to spis problem v wireles tools ze to tam nechodi.

P.S.: Az se zeptas lusera jakej ma signal a on ti rekne 40% tak z toho budes na prasky.. Co potrebuju ja je sila signalu a sila sumu v dBm.

Zdenek

[Libor Klepac]

nekde jsem pred rokem zachytil zpravu, ze nekdo bude delat spolecny strom se vsemi ovladaci wlan ... to asi vysumelo , nebo ne?

[Michal Čihař]

To bylo IMHO pro nějaké BSD, kde to už snad i funguje....

[Libor Klepac]

myslim, ze je to tohle

http://lwn.net/Articles/87952/

ale patch je tam posledni (a asi i prvni) na 2.6.7