Jaderné noviny 280

9. 11. 2004 | Robert Krátký | Jaderné noviny | 4383×

Blikání LED na klávesnici při kernel panic. Kontextové přepínání více instancí Linuxu. Defragmentace paměti. Ujasnění pravidel pro ověřování patchů.

Do konference přišlo celkem 1941 emailů, nejvíce jich poslali Andrew Morton, Robert Love a Alan Cox.

Blikání LED na klávesnici při kernel panic, 6 e-mailů

29. zář - 30. zář

Andi Kleen napsal:

Pozdější vydání verze 2.4 obsahovaly funkci, která způsobila blikání LED, když došlo ke kernel panic. Tento patch ji přidává do 2.6.

Je to užitečné, jste-li v X a systém zamrzne. Když blikají LED, alespoň víte, že příčinou je kernel panic, a ne jen tak nějaké zatuhnutí.

Trošku jsem patch vyčistil a portoval ho na nový ovladač klávesnice. Oproti 2.4 to nyní funguje i s panic=... a už se nespoléhá na tikání přerušení časovače [timer interrupt ticking]. Také je to přehlednější, protože se používá obecný callback, ne ifdef. Mělo by to také fungovat s ovladačem klávesnice zkompilovaným jako modul, a frekvence blikání může být nastavena v SysFS (to se hodí pro některé KVM přepínače, kterým se podobné věci nelíbí). Nastavení na 0 funkci vypne.

Zbývá udělat: vymyslet způsob, jak použít HLT v zaneprázdněných smyčkách. V současné době spolykají počítače při panic hodně energie a někdy v takovém stavu zatuhnou na několik dní než je možné je resetovat. Bohužel to však znamená spolehnout se opět na přerušení časovače.

P.S. Než se někdo zeptá: ne, nezajímá mě výstup v morseovce.

Kontextové přepínání více instancí Linuxu, 6 e-mailů

1. říj

Arvind Kalyan se zeptal:

Snažím se nahrát a spustit dva linuxové kernely současně; pokouším se předvést virtualizaci jako první krok.

Poradíte mi někdo, kde začít? Díval jsem se na plex, bochs, vmware, usermode linux... pouze simulují architekturu, na které běží jiné jádro.

Mým cílem je dát oběma jádrům přímou kontrolu nad hardwarem a pak mezi nimi "kontextově přepínat" podle time-slice.

Frederik Deweerdt doporučil: Zkus se podívat na Adeos: http://home.gna.org/adeos/. Martin Waitz navrhl: Můžeš zkusit Xen: http://www.cl.cam.ac .uk/Research/SRG/netos/xen/. Neumožňují ale přímou manipulaci s hardwarem, místo toho používají své vlastní ovladače. Adam Heath opravil: Od verze 2.0 už přímou manipulaci s hardwarem podporují. Chris Wright také doporučil Xen.

Defragmentace paměti, 31 e-mailů

1. říj - 4. říj

Marcelo Tosatti napsal:

Posledních pár týdnů si pohrávám s defragmentací paměti.

Následující patch implementuje funkci "coalesce_memory()", která bere jako parametry "zone" a "order".

Snaží se přesunout dost fyzicky blízkých stránek tak, aby vytvořila volné místo o velikosti "order".

Dělá to tak, že zkontroluje, jestli je stránku možné přesunout, alokuje novou stránku, "odmapuje" PTE (Page Table Entry), zkopíruje data na novou stránku, přemapuje PTE a vloží stranu na radix/LRU.

Zatím to není moc kompletní - současné vyhledávání radixu na SMP zmrví odmapovávání souborových stránek (vyhledávání swapcache by mělo být bezpečné) a spousta dalších chybiček. Například PTE nejsou po odmapování znovu stanoveny.

Pracuji na tom.

Ale na UP to funguje dobře (pár minut :)) a lehce vytvoří velké fyzické oblasti nefragmentované paměti.

S takovou funkcí můžeme vytvořit mechanismus pro kswapd (nebo samostatný thread kernelu, bude-li třeba), který by si všiml, že máme málo vyšších stránek [high order pages], a použít koalescenční algoritmus - místo uvolňování jednotlivých stránek z LRU naslepo - v naději, že sestavíme fyzicky velké nefragmentované oblasti paměti.

Nick Piggin a Marcelo pak řešili možné problémy s kswapd. Nick poslal vlastní patch, o kterém již dříve mluvil s Linusem Torvaldsem. Řekl, že se pokusí jej nechat začlenit do 2.6.10 společně s Marcelovým defragmentátorem.

Ujasnění pravidel pro ověřování patchů, 10 e-mailů

1. říj - 2. říj

Dave Hansen měl pár otázek k nedávným změnám v pravidlech zasílání patchů, které bylo poprvé popisováno v Jaderných novinách 264: Linus navrhuje nová pravidla označování původu záplat. Dave napsal:

Po nedávných aktualizacích pro ppc64 se několik patchů nepodařilo bez problému začlenit do mého stromu. Protože jsem líný, požádal jsem jednoho z vývojářů ppc64, aby to pro mě synchronizoval. Ale byl to někdo jiný než původní autor patchů.

Když mi je poslal zpátky, byly řádky "Signed-off-by:" původního autora (i moje) pryč a byly nahrazeny jménem toho chlapíka, který je pro mě začlenil. Určitě to bylo kvůli způsobu, jak generuje patche, zjevně ne zlý úmysl, ale i tak by mě zajímalo, jak se to má dělat "správně".

Zapisujeme logický postup?

Signed-off-by: původní autor
Signed-off-by: začlenil patch
Signed-off-by: správce stromu

Nebo skutečnou cestu patchů, což by ukázalo, že se u správce stromu objevily dvakrát?

Signed-off-by: původní autor
Signed-off-by: správce stromu
Signed-off-by: začlenil patch
Signed-off-by: správce stromu

A záleží na tom vůbec?

Linus Torvalds odpověděl:

Nemyslím, že by na tom moc záleželo, ale osobně radši vidím na konci seznamu osobu, která mi to poslala ("poslední dotyk"). To je částečně proto, že především u větších balíků patchů (např. od Andrewa) prostě provedu najdi-a-nahraď a nahradím všechna "signed-off-by odesílatel" řádkou "signed-off-by odesílatel a já".

I tak si však myslím, že je to docela zbytečné (a možná matoucí), aby byl někdo zmíněn dvakrát, takže bych vlastně dával přednost tomu, aby taková osoba před odesláním prostě přesunula svůj (předchozí) řádek na poslední místo.

Poznámka bokem: Také jsem rád, když jsou hned nad Signed-off-by řádkami údaje "Acked-by:" ("ví o tom") nebo "Cc:", protože se to hodí v případě technických problémů s patchem - objeví-li se chyba, je velmi pohodlné jen vzít všechny lidi ze signed-off-by _a_ acked-by a další "zainteresované" lidi a poslat jim dotaz. I kdyby ty řádky "Acked-by:" nebyly k ničemu jinému, než že by značily, že diskuze se účastnil i někdo další - ačkoliv se ve skutečnosti nepodíleli na psaní nebo posílání patche.

Paul Jackson napsal:

Způsob přidávání řádku Acked-by mě trochu mate.

Když pošlu patch poté, co jsem si o něm pěkně popovídal s Pepou Novákem, měl bych sám za Pepu přidat řádek Acked-by, nebo bych se ho měl nejdříve zeptat (případně ho znát dost dobře na to, abych věděl, že by souhlasil), a nebo bych ho měl přidat jen pokud si o to Pepa řekne?

Jinými slovy, zavazuje přítomnost takového řádku Pepu k něčemu vůči patchi - snad kromě toho, aby nebyl otrávený, když se ho na něj někdo zeptá?

Linus odpověděl: "Acked-by" neznamená nic, takže se řiďte vlastním úsudkem. Zopakoval, že 'acked-by' nikoho k ničemu nezavazuje: Aspekt otravnosti je jediným aspektem, který je potřeba brát v potaz.

---

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

• Redesigning Readahead
• Linux 2.6.9-rc2-mm4 Released
• Linux 2.6.9-rc3
• Linux 2.6.9-rc3-mm1 Released
• Software Suspend 2.1-rc1 For 2.6.8.1 And 2.6.9-rc3
• Merging DRM And fbdev
• Linux 2.6.9-rc3-mm2 Released
• Software-Suspend Wakeup Behavior

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

Komentáře

[Jiří Svoboda]

"v naději, že sestavíme fyzicky velké nedefragmentované oblasti paměti."
To je ovsem pravy opak toho, ceho chceme dosahnout. V originale se pise:
"in the hope to build large physically contiguous memory areas.",
takze by tam melo byt bud "nefragmentovane" nebo mozna "fyzicky souvisle".

Jinak opet pochvala.

[Robert Krátký]

Díky. Hloupé přehlédnutí. Opraveno.

[coolio]

Jsem linuxlama, proto tento dotaz: při kernel panic nefunguje známý trojhmat pro restart - je nějaký jiný krom HW resetu?

[Ritchie]

Aha, Ctrl+Alt+Del je známý trojhmat? Mně už moc známý nepřijde. Alt_R+SysRq+B. Výpis všech SysRq akcí Alt_R+SysRq+H. Kernel ale musí být skompilován s příslušnou volbou (Magic SysRq Y). Podrobněji již letitý článek na rootu.

[Petr Jakubec]

  Jako "linuxlama" se ti tezko stane ze privedes linuxovy kernel k panice, protoze jiste pouzivas nejakou standardni linux-distro, kde by se toto nemelo stat.
  Leda ze by si poskodil zaznam o poloze / pri bootu - to je tak jedine co me napada.
  Ctrl+alt+del je vsak uplne neco jineho.
  A nehledej zadnou podobnost s blue-death ve W. W. Na panic reaguji okamzitym restartem (proste slitnou a s nikym se o tom nebavi!).
-- Petr

[coolio]

Na to blikani vsech diod na klavesnici a napis "kernel panic" jsem narazil kdyz jsem si stahnul Zipslack co jede pod FAT32. Resp. mne nejede, pri startu se zadrhne, nepostoupi do dalsich runlevelu. Vzdy jsem musel notebook vypnout a zapnout. Ovsem pricinu jsem stejne nenasel, snad podle jednoho zdroje co jsem vygoogloval jde o bordel v CR a CR+LF v konfiguracich, rozdil mezi Win Linuxem. Nez abych to opravoval, tak jsem to smaznul.

Ale diky za rady, budou se jeste hodit.

[Michal Kubeček]

I u "standardní distribuce" se to může stát. Třeba zrovna včera jsem po dlouhé době na takový případ narazil. Stačilo k tomu nainstalovat do distribuce pro AMD64 Firefox 1.0 (dělal to jak přeložený pro x86_64, tak standardní 32-bitový build), povolit v konfiguraci Javu a chvíli prohlížet stránky. Vyrobil jsem jich asi deset, než jsem přišel na to, že to souvisí s tou Javou. Ještě zkusím příčinu trochu izolovat, aby mělo smysl to reportovat.

Automatický restart při kernel panic není tak úplně a priori špatná myšlenka. Třeba u serverů, které mají běžet pokud možno nepřetržitě, je to dokonce žádoucí. Proto také existuje /proc/sys/kernel/panic

[egg]

Znáš trojhmat Ctrl+Alt+Reset? Ten funguje.

[coolio]

Bohužel na notebooku ne