Jaderné noviny – 26. 8. 2009 (diskuse)

[martin()]

sledgehammer == palica ? :-/

[Andrej Herceg]

Nie, ale sledgehammer == palice ;)

[martin()]

Tak toto by ma ani vo sne nenapadlo

[Semo]

Cesky je palica bud palica, alebo hlava, alebo velke kladivo. Takze je to spravne.

[Semo]

Alebo este hul.

[Tyfus]

Vy jste mi češtináři.

Kovářské kladivo se odjakživa jmenuje „perlík“.

[Marián André]

Hm, tuším kladivko na rozklepávanie mäsa je v češtine palička... (?)

[trekker.dk]

Co se začlenění TuxOnIce týče, tak je škoda, že to neklaplo - mezi ty jeho "hezké" vlastnosti třeba patří to, že umí uspat a probudit X.org s binárními ovladači nvidia, což suspend v hlavní řadě jaksi moc ne-e.

[Robert Krátký]

Moje distribuční jádro (Debian, 2.6.30) to umí - jen pak nefunguje nastavení pomocí nvidia-settings. Ale pokud to člověk nepotřebuje, tak je vše v pohodě.

[trekker.dk]

Já jsem to zkoušel tuším s 2.6.29 (možná .28) made in udělej si sám, když se na tuxonice-dev diskutovalo o začlenění do jádra. Aby se stroj probudil, musel jsem ten modul úplně vyndat. (Ale možná něco vylepšili, časem to zkusím)

[Jiri Slaby]

K tomu zacleneni: neni se cemu divit, ten kod neni uplne koser. Nicmene zaclenovat se bude. Ale ne jako samostatny "swsusp". Misto toho bude soucasny swsusp vylepsen.

 

Ano, nvidia muze byt problem pro upstream swsusp. Ze zvedavosti, nepomuze zvyseni SPARE_PAGES v kernel/power/power.h na dvojnasobek? nvidia dela velke alokace behem suspendu a ten soucasny objem ji nemusi stacit. Pricemz si dokazu predstavit, ze ikdyz alokace selze, tak oni vrati nechybovy stav. TOI pouziva std. 2M.

[trekker.dk]

K tomu zacleneni: neni se cemu divit, ten kod neni uplne koser.

Což to je mi jasný.

Ale ne jako samostatny "swsusp". Misto toho bude soucasny swsusp vylepsen.

Nic proti - pokud se tam teda dostanou všechna vylepšení, která potřebuju, aby mi swsusp fungoval.

Ze zvedavosti, nepomuze zvyseni SPARE_PAGES v kernel/power/power.h na dvojnasobek?

Zkusim, až se v tom zase budu někdy rejpat.

[trekker.dk]

Ze zvedavosti, nepomuze zvyseni SPARE_PAGES v kernel/power/power.h na dvojnasobek?

Zvýšil jsem, pomohlo*. Dám tomu pár dní testování a uvidíme, jestli se něco nepokazí. (sync před uspáním jsem dělal už doteď a budu v tom pokračovat )

[Andrej]

Situace kolem uspání a hibernace je momentálně v Linuxu tragická. Dalo by se to shrnout asi takto:

• Hibernace, která je přímo v mainline kernelu, se nikdy neprobudí. Nemá smysl to vůbec zkoušet. Nechápu, proč tam vůbc je. Mělo by tam být upozornění, označení EXPERIMENTAL a podobně. Jen ohrožuje data důvěřivých uživatelů a nepřináší žádný užitek.
• Do verze 2.6.28.x fungoval znamenitě TuxOnIce. Od té doby (a od zavedení věcí kolem KMS) buď nefunguje vůbec, nebo zrovna pro daný kernel nejsou patche. Celkově se tedy dá říct, že momentálně funkční hibernace pro Linux neexistuje.
• Uspání do RAM fungovalo bezproblémově, ba znamenitě až do verze 2.6.28.x. Od této verze už uspání do RAM nefunguje. Problém už není v tom, že by se systém neprobudil. On se ani neuspí, jen se zasekne.

Fakt nechápu, jaká převratná změna musela ve verzi 2.6.29 přijít, že to všechny věci kolem uspání do RAM a hibernace poslalo do kytek. Nehledě na fakt, že nové ovladače grafiky Intel jsou už několik měsíců rozbité a nedá se s nimi pracovat. Takže ani toho slavného KMS si člověk neužije.

 

[Filip Jirsák]

Píšete o Linuxu obecně, nebo o jedné nebo několika málo instancích na vašem počítači, případně pár počítačích okolo?

[Andrej]

O Linuxu obecně. Do verze 2.6.28 mně na mých počítačích i všem známým, kteří používají Linux, funovala hibernace bez potíží a totéž platilo o uspání do RAM. Od verze 2.6.29 nevím o nikom, komu by tohle fungovalo.

Pokud je tu někdo s vanilla kernelem verze 2.6.29 a vyšší, komu funguje buď uspání nebo hibernace, ať už s TuxOnIce nebo s původní (podle mě nebezpečnou a nefunkční) implementací, moc rád se od něj něčemu přiučím.

Kdysi jsem řešil problém, že po probuzení počítače z hibernace mi nefungoval IRDA port a musel jsem ho ručně zapnout. Dokonce jsem to hlásil jako bug a vývojáři TuxOnIce to dali do pořádku prakticky okamžitě. Nicméně ve srovnání s dnešní situací se mi nefunkční IRDA zdá jako titěrný a nesmyslný problém.

[CIJOML]

2.6.31 vanilla original EEE901 funguje do RAM i na disk - na Prestigio 159W to same - vzdy posledni vydany bios

 

[Filip Jirsák]

A přibližně se to týká třech lidí nebo tří set? A ti vaši známí mají různý hardware, různé konfigurace softwaru atd., nebo všem svým známým doporučujete osvědčenou značku základních desek a čipsetů, a teď je s tou jednou řadou problém, a vy to zobecňujete na vše? Z toho původního komentáře to není poznat, a vzhledem k tomu, že se tady v diskusi objevují i komentáře od lidí, kterým to funguje, ta vaše generalizace se mi zdá přehnaná. Ne že by zrovna mně fungovalo uspávání počítačů pod Linuxem bez problémů, ale v mém případě je to spíš rukama a neochotou to řešit, protože u desktopu mi delší boot ráno nevadí, a u notebooku nefunkční touchpad po probuzení nějak přežiju, stejně ho používám nerad.

[Andrej]

Týká se to (odhadem) deseti lidí. Hardware mají v podstatě různorodý, někdo starší 32-bit, někdo 64-bit, různé značky. Já nikomu nic nedoporučuju, hardwarem se nezabývám a neradím lidem, co si koupit.

Přiznám se, že kdybych pečlivě hlásil každý bug a snažil se zachytit aspoň jednu rozumnou logovou hlášku přes netconsole, možná by se to dalo vyřešit. Už takové věci nedělám, přece jen toho elánu nemám tolik jako dřív. Ono se to těžko řeší, když ten stroj odporně zatuhne. Pak nezbývá než přebootovat, zkusit vyhodit nějaký modul, znova zkusit uspat... Na to už prostě nemám nervy. A mám dojem, že před cca třemi lety tam byly mnohem menší problémy (například IRDA), které navíc bylo možné nějak vyřešit. Dnes vidím jenom sekanec a nemám tušení, co se tam děje.

[Jendа]

Hibernace, která je přímo v mainline kernelu, se nikdy neprobudí.

Nemáte pravdu, mně se probouzí úplně bez problémů. Takže určitě neplatí nikdy. Jádra 2.6.24 - 2.6.30, předtím jsem hibernaci nezkoušel.

Nemá smysl to vůbec zkoušet.

Vyzkoušel jsem, fungovala mi na první pokus (distribuční jádra Archu a Debianu). Pravda, pak jsem chtěl obraz paměti šifrovat a na to bylo potřeba upravit skripty v initramdisku, ale bez šifrování mi to šlo v pohodě.

Nechápu, proč tam vůbc je.

Nevím, ale řekl bych, že proto, aby fungovala hibernace.

Jen ohrožuje data důvěřivých uživatelů

To tedy nevím, jak může neprobuzení se ohrozit data. Filesystém na tom bude stejně, jako kdyby vypadla elektřina.

a nepřináší žádný užitek.

Mně se hibernace docela hodí - spouštění všech služeb trvá strašně dlouho, takhle mám za chvilku počítač přesně v tom stavu, v jakém jsem ho uspal.

Fakt nechápu, jaká převratná změna musela ve verzi 2.6.29 přijít, že to všechny věci kolem uspání do RAM a hibernace poslalo do kytek.

Žádných problémů jsem si nevšiml. Akorát jsem trochu zápasil v VirtualBoxím modulem.

[Andrej]

Já mám vanilla kernel, takže to nemá smysl takhle srovnávat. Distribuční kernel jsem nikdy nezkoušel a ani to nemám v plánu.

Mně původní hibernace ještě nikdy nefungovala. Pravda je, že jsem to zkoušel jen cca desetkrát, ale pokaždé to naprosto spolehlivě selhalo. Počítač se buď neprobudil, nebo se vůbec neuspal a zatuhl. TuxOnIce donedávna fungoval spolehlivě.

Mně už původní hibernace při jednom z pokusů o uspání poškodila filesystém. Konkrétně to byl Reiser4 a byl to jeden z mála případů, kdy jsem ho musel opravovat pomocí fsck. Mám za to, že se jednalo o něco vážnějšího než ekvivalent výpadku napájení.

Užitek přináší pouze spolehlivá a funkční hibernace. TuxOnIce byl až donedávna ideálním řešením. To, co je dnes v kernelu, mi spolehlivé nepřipadá. I s uspáním do RAM byl problém, protože počítač se cca při každém desátém uspání neprobudil. Jakmile to nemá rozumnou spolehlivost, nemá to smysl. Dnes už mi uspání do RAM nefunguje vůbec, takže je to fuk.

Asi nemá smysl to nějak řešit. Třeba mám špatný BIOS. Taky už jsem líný při každém selhání shromažďovat logy a hlásit bug, což jsem dřív dělával.

[stativ]

Co se týče Reiser 4 tak bych to zas tak neházel na hibernaci. Ačkoliv FS je (byl?) to určitě pěkný, slyšel jsem na něj docela dost nadávek co se týče poškození FS.

A jen tak mimochodem Arch používá vanilku.

[M. Lox]

Ačkoliv FS je (byl?) to určitě pěkný

Je.

slyšel jsem na něj docela dost nadávek co se týče poškození FS.

Taky už se mi párkrát rozsypal, ale vždycky to bylo hardwarem. (Vadný disk || vadná RAM || vadný kabel) == (fsck.reiser4: Read nodes: 12345678, Nodes left in tree: 1234567) .

[Patrik Uhrak]

Ja som sa ale napr. od kernelu 2.6.28 az po 2.6.31 s problemom uspania do ram a nasledneho prebudenia nestretol a pouzivam to kazdy bozi den. Mam ale nvidia kartu a driver z oficialnych stranok. Mozno je to tou intel grafikou, mozno niecim inym na tvojom stroji, no u mna to ide. Co sa tyka hibernacie, to nepouzivam, neviem potvrdit.

[trekker.dk]

Aby těch věcí, kdy prohlašuje něco, co platí pro tebe, za všeobecně platné, nebylo málo, tak

Do verze 2.6.28.x fungoval znamenitě TuxOnIce. Od té doby (a od zavedení věcí kolem KMS) buď nefunguje vůbec

Pro 2.6.29 byl patch a TOI fungoval naprosto bez problémů, nedávno jsem rebootoval s 33 dní uptime.

nebo zrovna pro daný kernel nejsou patche.

Pro 2.6.30 patch nebyl, ale zato se v mailing listu objevila adresa na gitový strom, ze kterého se nechalo 2.6.30 udělat a TOI fungoval. Pro 2.6.31 patch je, používám na dvou strojích a na obou funguje.

[Andrej]

Možná mám špatný BIOS.

[Josef Kufner]

Jak hibernace co je v kernelu, tak uspávání do RAM mi funguje s téměř 100% úspěšností. Nebude to klasický PEBKAC ?

[Mandarinka]

Spíš to (ne)funguje na konkrétním hardware... HIbernace (na linuxu) nikdy nebyla spolehlivá v tom, že by běžela všude.

[xm]

Já s vámi nemohu souhlasit. Mám přesně opačnou zkušenost - s jádry do 2.6.28 (včetně) mi suspend to RAM nefungoval (fungoval v nějakých hodně starších, ale pak přestal jít, jestli si správně pamatuju někdy okolo 2.6.26). Jádro 2.6.29 to zpravilo a v 2.6.30 taktéž funguje perfektně. Suspend to disk (hibernace) mi fungoval snad vždy. Testováno na 2 strojích s čipovou sadou a grafikou AMD/ATI.

[xm]

Jen doplním, že používám oficiální suspend z vanilla kernelu. Žádné sr**ky jako TuxOnIce mi do systému nesmí

[trekker.dk]

Žádné sr**ky jako TuxOnIce mi do systému nesmí

Vy jste, pane, vůl.

[xm]

Nápodobně, pane Vy mi také lezete už delší dobu krkem, obzvláště v diskuzích o KDE a politice, arogance z vás z nich přímo čiší.

[Jiri Slaby]

Ne, neni vul. Jen spravne tusi/vi, ze TOI pouziva strasne moc hacku.

[Blaazen]

Dobrý den, moje zkušenost je taková, že na nový notebook (čipset a CPU Intel) jsem zkoušel dát v červenci Debian s jádrem 2.6.26 a z hibernace i ze Suspend To RAM se to probudilo rovnou do kernel panic. Zkoušel jsem všemožná nastavení, upgrade jádra na 2.6.30 a nic nepomohlo (čímž nevylučuju problém ve mně, tehdy jsem s Linuxem spíš začínal). Pak jsem zkusil Kubuntu 9.04 s jádrem 2.6.28 a šlo to hned, bez nastavování. Od té doby 100% funkčnost. B.

[Nicky726]

Nehledě na fakt, že nové ovladače grafiky Intel jsou už několik měsíců rozbité a nedá se s nimi pracovat. Takže ani toho slavného KMS si člověk neužije.

Včera jsem nahodil aktuální Arší intel ovladače, podle wiki zapnul KMS, rebootoval a měl funkční grafiku včetně KMS. Žádné problémy s grafikou jsem zatím nezaregistroval.

[Andrej]

Právě dnes ten bug uzavřeli, prý už to funguje a nedochází k zamrznutí.

Nicméně otázka je, za jakých podmínek. Například já mám dual head konfiguraci 1050x1680 svisle a 1024x768 vodorovně s překrytím 90 pixelů (aby virtuální screen nepřesáhl limit pro 3D akceleraci). S něčím takovým má KMS pořád těžký problém.

[Jiri Slaby]

Apeluji na vas, abyste to reportovali. Ikdyz se vam nechce. Takhle to nebudete mit funkcni nikdy. (Ano, na muj vkus linux az moc testovani prenasi na lidi. Ale zaroven nevim, jak to zlepsit.)

[ticcky]

 Nechci rypat, ale nerozumnel jsem vtipu v komentari ve zdrojaku v citacich, tak jsem se koukl na original... =)

v orig. zni takto:

/* Promote an attitude of violence to a BIOS engineer today */

 

a v cestine je to podle me:

/* Dnes podpor nasilny postoj k vyvojarum biosu */

 

[kralyk z abclinuxu]

Překlad v článku je určitě přesnější než cos napsal.

[stativ]

Přesnější není, ale nezní tak kostrbatě. U překladu jde o to najít překlad, který zní přirozeně ale zároveň je co nejpřesnější. Osobně spíš kladu důraz na přirozenost. Pokud chci doslovný překlad, který se nedá pořádně číst můžu použít překladač.

[snehuliak]

Suhlasim s ticcky s tym prekladom. Dufam ze takto zle sa neprekladaju cele jaderne noviny. Asi by som sa mal raz konecne pozriet na original....

[Patrik Uhrak]

Chyby su vsade, ja som ale velmi vdacny za preklady, aj ked mozno len 99,9% spravne. Je to to vyborne citanicko, aj ked zvacsa tomu velmi nerozumiem :D ale to je druha strana mince. Takze dakujem autorovi prekladu.

[Andy]

+1

[kralyk z abclinuxu]

Já zas doufám, že nikdo nebude překládat JN tak špatně jako ticcky

[Jirka]

Jak na zkousku uzavrit popisovac 2, abych si mohl vyzkouset to chovani pri uzavrenem popisovaci?

[Michal Vyskočil]

#include <unistd.h>
close(STDERR_FILENO);

[petr_p]

V bashi stačí za příkaz přidat 2>&-.

[geebranz]

Good innovator

polebarnssalemor.com