Portál AbcLinuxu, 5. května 2025 19:36
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.
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.
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
Situace kolem uspání a hibernace je momentálně v Linuxu tragická. Dalo by se to shrnout asi takto:
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.
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.
2.6.31 vanilla original EEE901 funguje do RAM i na disk - na Prestigio 159W to same - vzdy posledni vydany bios
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.
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.
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.
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)
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.
Do verze 2.6.28.x fungoval znamenitě TuxOnIce. Od té doby (a od zavedení věcí kolem KMS) buď nefunguje vůbecPro 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.
Možná mám špatný BIOS.
Žádné sr**ky jako TuxOnIce mi do systému nesmíVy jste, pane, vůl.
Ne, neni vul. Jen spravne tusi/vi, ze TOI pouziva strasne moc hacku.
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.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.
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.
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.)
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 */
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....
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.
Jak na zkousku uzavrit popisovac 2, abych si mohl vyzkouset to chovani pri uzavrenem popisovaci?
#include <unistd.h> close(STDERR_FILENO);
2>&-
.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.