abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

včera 23:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 145. brněnský sraz, který proběhne v pátek 20. října od 18:00 hodin v restauraci Time Out na adrese Novoměstská 2 v Řečkovicích. Jedná se o poslední sraz před konferencí OpenAlt 2017, jež proběhne o víkendu 4. a 5. listopadu 2017 na FIT VUT v Brně. Běží registrace účastníků.

Ladislav Hagara | Komentářů: 0
včera 21:44 | Nová verze

Byla vydána verze 5.2.0 multiplatformního virtualizačního nástroje Oracle VM VirtualBox. Jedná se o první stabilní verzi z nové větve 5.2. Z novinek lze zmínit například možnost exportování VM do Oracle Cloudu, bezobslužnou instalaci hostovaného systému nebo vylepšené GUI. Podrobnosti v seznamu změn. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 1
včera 14:00 | Zajímavý projekt

Byl spuštěn Humble Down Under Bundle. Za vlastní cenu lze koupit multiplatformní hry The Warlock of Firetop Mountain, Screencheat, Hand of Fate a Satellite Reign. Při nadprůměrné platbě (aktuálně 3,63 $) také Hacknet, Hacknet Labyrinths, Crawl a Hurtworld. Při platbě 12 $ a více lze získat navíc Armello.

Ladislav Hagara | Komentářů: 0
včera 13:00 | Nová verze

Google Chrome 62 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 62.0.3202.62 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře (YouTube). Opraveno bylo 35 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 4
včera 11:00 | Zajímavý článek

Článek (en) na Mozilla.cz je věnován vykreslování stránek ve Firefoxu. V průběhu roku 2018 by se ve Firefoxu měl objevit WebRender, jenž by měl vykreslování stránek urychlit díky využití GPU.

Ladislav Hagara | Komentářů: 5
včera 08:22 | Bezpečnostní upozornění

NÚKIB (Národní úřad pro kybernetickou a informační bezpečnost) informuje o zranitelnosti ROCA v procesu generování RSA klíčů, který se odehrává v softwarové knihovně implementované například v kryptografických čipových kartách, bezpečnostních tokenech a dalších hardwarových čipech vyrobených společností Infineon Technologies AG. Zranitelnost umožňuje praktický faktorizační útok, při kterém útočník dokáže vypočítat

… více »
Ladislav Hagara | Komentářů: 3
včera 01:23 | Zajímavý software

Příspěvek na blogu otevřené certifikační autority Let's Encrypt informuje o začlenění podpory protokolu ACME (Automatic Certificate Management Environment) přímo do webového serveru Apache. Klienty ACME lze nahradit novým modulem Apache mod_md. Na vývoj tohoto modulu bylo uvolněno 70 tisíc dolarů z programu Mozilla Open Source Support (MOSS). K rozchození HTTPS na Apache stačí nově přidat do konfiguračního souboru řádek s ManagedDomain. Minutový videonávod na YouTube [reddit].

Ladislav Hagara | Komentářů: 3
17.10. 14:15 | Komunita

Daniel Stenberg, autor nástroje curl, na svém blogu oznámil, že obdržel letošní Polhemovu cenu, kterou uděluje Švédská inženýrská asociace za „technologickou inovaci nebo důvtipné řešení technického problému“.

marbu | Komentářů: 11
17.10. 13:40 | Pozvánky

Cílem Social Good Hackathonu, který se uskuteční 21. a 22. října v Brně, je vymyslet a zrealizovat projekty, které pomůžou zlepšit svět kolem nás. Je to unikátní příležitost, jak představit nejrůznější sociální projekty a zrealizovat je, propojit aktivní lidi, zástupce a zástupkyně nevládních organizací a lidi z prostředí IT a designu. Hackathon pořádá brněnská neziskovka Nesehnutí.

… více »
Barbora | Komentářů: 1
17.10. 00:44 | Pozvánky

V sobotu 21. října 2017 se na půdě Elektrotechnické fakulty ČVUT v Praze uskuteční RT-Summit – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt.

… více »
Pavel Píša | Komentářů: 8
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (11%)
 (1%)
 (0%)
 (1%)
 (72%)
 (14%)
Celkem 79 hlasů
 Komentářů: 5, poslední dnes 07:28
    Rozcestník

    Jaderné noviny – 30. 6. 2011: Regrese správy napájení ve 2.6.38

    12. 7. 2011 | Jirka Bourek | Jaderné noviny | 3676×

    Aktuální verze jádra: 3.0-rc5. Citáty týdne: Frederic Weisbecker, Mauro Carvalho Chehab, Andrew Morton. -EJAKOUCHYBU? PCIe, správa napájení a problematické BIOSy. Umravňování výstupu do logů.

    Obsah

    Aktuální verze jádra: 3.0-rc5

    link

    Současné vývojové jádro je 3.0-rc5 vydané 27. června. Nic výrazně zajímavého. Nejzajímavější věc je asi to, že v ovladačích je jenom čtvrtina změn, víc (40 %) mají ve skutečnosti na svědomí souborové systémy: jsou tu btrfs, cifs, ext4, jbd2 a nfs. Detaily lze nalézt v kompletním changelogu.

    Stabilní aktualizace: 23. června vyšly s dlouhým seznamem oprav aktualizace jader 2.6.32.42, 2.6.33.15 a 2.6.39.2. Aktualizace 2.6.34.10 – první od dubna – vyšla 26. června taktéž s velmi dlouhým seznamem oprav.

    Citáty týdne: Frederic Weisbecker, Mauro Carvalho Chehab, Andrew Morton

    link

    Protože jsem se tak dlouho zabýval rcu dynticky pro věci ohledně nohz cpuset, hádám, že moje podvědomí došlo k závěru, že rozšířené klidové stavy rcu jsou celosvětově rozšířeným tématem, o kterém rodiny mluví během večeře a které se dokonce stalo základem některých ukolébavek. Stále slyším ten refrén, který vám umožní přepnout se s klidem do klidového stavu...

    -- Frederic Weisbecker

    Specifikace V4L2 je potřeba opravit, co se chybových kódů týče. Autoři ovladačů jsou mnohem kreativnější než autoři DocBook.

    -- Mauro Carvalho Chehab

    Různá POSIX_FADV_něco jsou tak špatně definovaná, že bylo chybou je vůbec použít. Měli jsme udělat něco jasně specifického pro Linux a dát uživatelskému prostoru explicitnější a přímější kontrolu na cache stránek.

    -- Andrew Morton

    -EJAKOUCHYBU?

    link

    napsal Jonathan Corbet, 29. června 2011

    Uživatelé API Video4Linux2 ví, že je poněkud komplikované, obsahuje 91 různých příkazů ioctl(). Co se hlášení chyb týče, je mnohem jednodušší: pokud se něco pokazí, aplikaci se téměř určitě vrátí EINVAL. Tato chyba může uživatelskému prostoru zkoušet sdělit, že zařízení je ve špatném stavu, že nějaký parametr byl mimo rozsah nebo jednoduše že požadovaný příkaz nebyl implementován. Není potřeba říkat, že pro vývojáře je těžké zjistit, co se vlastně stalo.

    Správce V4L2 Mauro Carvalho Chehab nedávno zaslal patch, který mění návratový kód na ENOIOCTLCMD v případech, kdy relevantní ovladač neimplementuje požadovaný příkaz. Tato změna by rozlišila alespoň jednu sadu problémů – až na to, že kód VFS v tichosti překládá ENOIOCTLCMD na EINVAL předtím, než chybu vrátí do uživatelského prostoru. Z pohledu aplikace se tedy nemění nic.

    Zajímavé je, že podle pravidel je jasné, co se v takové situaci má stát: pokud ioctl() příkaz nebyl implementován, jádro by mělo vrátit ENOTTY. Některé části jádra tuto konvenci dodržují, jiné ne. A není to nový problém ani problém specifický pro Linux; jak to řekl Linus: Tahle věc okolo EINVAL jde hodně do minulosti a je to pohroma. Pokud vím, je to starší záležitost než Linux samotný. Navrhl jednoduše změnit ENOIOCTLCMD na ENOTTY v celém jádře a zjistit, co se stane.

    Samozřejmě se stane to, že se změní ABI pro uživatelský prostor. Je zcela možné, že někde venku nějaký program závisí na tom, že při chybějící ioctl() funkci dostane EINVAL a že když se návratový kód změní, přestane fungovat. Je ale jenom jeden způsob, jak to říci s jistotou: udělat změnu a zjistit, co se stane. Mauro hlásí, že tato změna ve V4L2 podle všeho nic nerozbíjí, takže je slušná šance, že se dostane do jádra 3.1. Změna v celém stromě by ale mohla mít mnohem širší důsledky; jestli někdo najde odvahu to zkusit, to se uvidí.

    PCIe, správa napájení a problematické BIOSy

    link

    napsal Jonathan Corbet, 29. června 2011

    V dubnu Phoronix s fanfárou oznámil, že jádro 2.6.38 – a ta následující – obsahuje „zásadní“ regresi ve správě napájení, která na některých systémech výrazně snižuje dobu běhu na baterie. Problém vygeneroval poměrně dost diskuzí včetně tohoto vlákna v Launchpadu, ale málo řešení. Phoronix nyní tvrdí, že našli změnu, která způsobuje problém, a poskytl workaround, který pro některé uživatele stav zlepší. Skutečná oprava ale asi jen tak nepřijde.

    Protože se u PCI-Express zařízení používají vysoké takty hodin, mohou tato zařízení spotřebovat hodně energie, i když jsou nečinná. Proto byla vyvinuta „správa napájení pro aktivní stav“ [Active state power management, ASPM], která periférie přepne do režimu se sníženou spotřebou, když se zdá, že nebudou potřeba. ASPM může ušetřit energii, ale je zde obvyklé něco za něco: zařízení v režimu nízké spotřeby není okamžitě k dispozici. Na systémech, kde se ASPM používá, může přístup k zařízení, které je právě vypnuté, trvat výrazně déle. V některých situacích (obvykle v těch, které zahrnují běh na baterie), to může být akceptovatelné; v jiných ne. Takže jako většinu mechanismů pro správu napájení lze i ASPM vypnout a zapnout.

    Je to ale o něco komplikovanější; na systémech x86 se do toho vkládá BIOS. BIOS je pověřen počáteční konfigurací systému a tím, aby jádru sdělil, jaké funkce jsou k dispozici. Jednou z těchto informací je to, jestli systém obsahuje podporu ASPM. Jaderní vývojáři vcelku rozumně došli k závěru, že pokud BIOS řekne, že ASPM není podporováno, neměli by hrabat do registrů s ním spojených. Ukázalo se ale, že tento přístup nefungoval; v prosinci tedy Matthew Garret začlenil patch popsaný takto:

    V současnosti se odmítáme dotknout ASPM registrů, když nám BIOS řekne, že ASPM není podporováno. To může způsobit problémy, pokud BIOS (z jakéhokoliv důvodu) na některých zařízeních ASPM i přesto povolil. Kód se mění tak, abychom explicitně vynulovali ASPM, pokud FADT udává, že ASPM není podporováno, a aby se všechno při odstranění zařízení uklidilo, což řeší případ připojování za běhu.

    Jinými slovy BIOS někdy systému sdělí, že ASPM není podporováno, přestože je; a aby to bylo zábavnější, BIOS může ASPM na některých zařízeních zapnout (přestože tvrdí, že není k dispozici) předtím, než předá kontrolu jádru. Vývojáři operačních systémů nemají vývojáře BIOSů v úctě a má to své důvody.

    Kdyby si Andrew Morton changelog uvedený výše přečetl, určitě by si stěžoval, že „může způsobit problémy“ je pro změnu jádra poměrně vágní odůvodnění. Autor článku se Matthewa zeptal a získal informativní odpověď, kterou stojí za to přečíst si ji celou:

    Pokud je tento bit nastaven, platforma oznamuje OS, že nepodporuje ASPM. V minulosti jsme to brali tak, že jednoduše nemáme na ASPM bity sahat. Ukazuje se ale, že na některých systémech BIOS povoluje ASPM sám, pak nastaví bit „ASPM není podporováno“ a když dojde k přechodu do ASPM, hardware zhavaruje. Nejjednodušší věc, která se dá předpokládat, je, že BIOS je hloupý (abych byl upřímný, to předpokládám vždy) a neměl ASPM povolit. Od tohoto patche tedy vynulujeme stav ASPM, když BIOS oznámí, že platforma ASPM nepodporuje.

    Není těžké si představit, že přepnout zařízení do stavu, o kterém se jádru řeklo, že neexistuje, může v některých případech vyvolat zmatek. Trocha hledání například našla toho hlášení o zatuhnutí systému, které Matthewův patch opravil. Pokud BIOS tvrdí, že ASPM není podporováno, zdá se, že dává smysl ujistit se, že si žádné zařízení nebude myslet opak.

    Tento patch nicméně také byl označen za viníka poté, co se na Phoronixu zabývali hledáním půlením [bisect], aby našli příčinu dané regrese. Dává smysl, že vypnutí stavu snížené spotřeby může vést k vyšší spotřebě. Workaround navržený v článku spočívá v tom, že se použije volba pcie_aspm=force; ta donutí systém zapnout ASPM bez ohledu na to, co BIOS tvrdí o jeho podpoře. Tento workaround může bezpochyby na některých postižených systémech poskytnout lepší životnost na baterie; jinde nemusí fungovat vůbec. V tom druhém případě se systém může jednoduše zaseknout – což je stav s ještě horší charakteristikou latencí kombinovaný s překvapivě špatným využíváním energie. Workaround tedy může být přijat uživateli, kteří zjistí, že životnost baterií výrazně vzrostla, ale správné řešení problému to není.

    Najít toto správné řešení – pokud možno takové, které bude prostě fungovat bez potřeby přidávat zvláštní parametry pro boot – může být složité. Opět citujeme Matthewa:

    Jaké jsou alternativy? Můžeme zachovat status quo a přidat whitelist hardwaru, o kterém víme, že funguje. Problém je, že i když máme specifikace hardwaru, často nemáme errata. Nevíme s jistotou, jestli něco funguje nebo ne. Mohli bychom patch zrušit a přidat víc hardwaru na blacklist. Pak ale budeme muset najít všechna zařízení, která nefungují. Nebo je možné, že původní kód byl správně a Linux jednoduše hardware programuje odlišně, což způsobuje problémy s ASPM, které jinde nelze vidět.

    Vzhledem k nejistotě vývojáři jádra došli k závěru, že „plýtvání trochou energie“ je menší zlo než „na některých systémech se to zasekne“. Dokud nebude problém lépe pochopen, jiný přístup by bylo těžké ospravedlnit. Někteří uživatelé tedy budou muset workaround pcie_aspm=force používat ještě nějakou dobu.

    Problém se spotřebou energie, alespoň pokud autor článku ví, se mezitím nikdy neobjevil v žádné jaderné vývojové e-mailové konferenci. Nikdy se neobjevil na seznamu regresí 2.6.38. Pro většinu vývojářů tedy byl neviditelný a není žádným překvapením, že se mu nedostalo větší pozornosti. Ať už je to dobře, nebo ne, vývojová komunita má svoje způsoby, jak řešit problémy. Nahlásit chybu na linux-kernel rozhodně negarantuje, že bude opravena, ale zvyšuje to pravděpodobnost. Kdyby byl tento problém předložen přímo zainteresovaným vývojářům, mohli bychom se o hlavní příčině dozvědět již před dlouhou dobou.

    Umravňování výstupu do logů

    link

    napsal Jake Edge, 29. června 2011

    Správně ošetřit data od uživatelů je jedním ze základních principů zabezpečení. Různé zprávy v jaderném logu umožňují vložit uživatelem kontrolované řetězce pomocí specifikátoru formátu „%s“; útočník by to mohl zneužít tak, že potenciálně zmate správce systému vložením řídících znaků do řetězců. Vasilij Kulikov tedy navrhl patch, který by ošetřil některé znaky, které se v těchto řetězcích objevují. Objevily se nějaké otázky o tom, které znaky mají být ošetřeny, ale větší otázka je v kruzích zabývajících se bezpečností prastará: whitelistovat nebo blacklistovat?

    Problém vychází z toho, že správci často k zobrazení souborů s logy použijí nástroje jako tail a more, kterými si je zobrazí na TTY. Pokud uživatel může vložit řídící znaky (a konkrétně escape sekvence) do logu, mohl by způsobit přehlédnutí potenciálně důležitých informací – nebo způsobit jiné zmatky. V nejhorším případě by escape sekvence mohly zneužít nějakou díru v emulátoru terminálu a vykonat kód nebo způsobit jiný druh špatného chování. V patchi Vasilij poskytl následující příklad: Řídící znaky by mohly roota zmást tak, že když si prohlíží logy na tty, mohlo by například ^[1A potlačit předchozí řádku v logu.. Znaky, které jsou filtrované, patch jednoduše nahrazuje „#xx“, kde xx je hexadecimální hodnota znaku.

    Je to v podstatě poměrně nezávažná záležitost, ale není jasné, jestli pro používání řídících znaků v uživatelem dodaných řetězcích má nějaké legitimní použití. Tyto řetězce mohou přijít z různých míst; v diskuzi byla zmíněna jména souborů nebo ID řetězce USB produktů. První verze patche zjevně zacházela příliš daleko, když se ošetřily i znaky nad 0x7e (společně s řídícími znaky), což by vyřadilo i Unicode a další non-ASCII znaky. Po stížnostech Vasilijova druhá verze vyjímá pouze řídící znaky (tj. < 0x20) s výjimkou nové řádky a tabelátoru.

    To ale příliš nesedlo Ingo Molnárovi, který si myslí, že místo whitelistování bezpečných znaků by se měly blacklistovat ty potenciálně škodlivé:

    Také si myslím, že by se mělo vyřadit těch několik řídících znaků, které jsou škodlivé (jako o řádku výše a escape znak), místo toho aby se povolovaly všechny, o kterých víme, že jsou užitečné

    [...] Je to také lepší přístup pro jádro: ošetřujeme věci, o kterých víme, že jsou škodlivé, a jinak povolujeme.

    Jenže aby se vytvořil blacklist, je potřeba nejprve určit vliv různých řídících znaků na všech možných emulátorech terminálu, zatímco přístup s whitelistem má výhodu, že stačí jednoduše hodit mnohem větší síť. Jak píše Vasilij, zjistit, které znaky jsou problematické, není jednoduché:

    Dokázal bys okamžitě odpovědět, kdybys nečetl předchozí diskuzi, které řídící znaky jsou škodlivé, které jsou občas škodlivé (na některých tty) a které jsou vždycky bezpečné a proč (nebo dokonce odpovědět na to, proč jsou vůbec škodlivé)? Já nejsem člověk od tty a abych tohle mohl zodpovědět, musím si přečíst console_codes(4) nebo podobnou dokumentaci, většina vývojářů jádra na tom asi bude stejně.

    Rozkol mezi Ingem a Vasilijem patří mezi ty, které ve světě zabezpeční existují již mnoho let. Správná odpověď na to, co je lepší, neexistuje. Stejně jako u většiny věcí i u zabezpečení (a když jsme u toho u vývoje softwaru jako takového) mají whitelisty a blacklisty svá pro a proti. Obecně je pro uživatelem zadaná data (například ve webových aplikacích) konsenzem whitelistovat vstup, o kterém víme, že je správný, místo toho snažit se určit veškeré možné „špatné“ vstupy. Přinejmenším v tomto případě nicméně Ingo nepovažuje whitelisty za správný přístup:

    Blacklist je dobře definovaný: zakáže zobrazení některých znaků, protože se ví, že jsou nebezpečné

    Whitelist to na druhou stranu dělá špatným způsobem: snaží se vložit 'důkazní břemeno' na ty hodné – a to je opravdu kontraproduktivní.

    Není překvapením, že Vasilij s touto analýzou nesouhlasí: Co uděláš s nebezpečnými znaky, u kterých ještě nevíš, že jsou nebezpečné? I když není moc sporů o tom, že whitelist dobrých znaků je bezpečnější, je také méně flexibilní, pokud by se našlo legitimní použití dalších řídících znaků v uživatelem dodaných řetězcích. Krom toho je Ingo skeptický k tomu, že by se v ASCII řídících znacích skrývala nějaká nebezpečí: Toto tvrzení je hloupé – chceš říci, že v prostoru vypisování ASCII je nějaká 'neznámá chyba'?

    V tomto případě by obě řešení měla být dostatečná, protože neexistují dobré důvody takové znaky používat, ale Ingo má nejspíš pravdu v tom, že v ASCII se žádná skrytá nebezpečí neskrývají. Je otázka, jestli je tato změna vůbec zapotřebí. Obava, která vedla k patchi, se zakládá na tom, že by administrátor mohl přehlédnout důležité zprávy nebo být oklamán pečlivě sestaveným vstupem (Willy Tarreau poskytl zajímavý příklad toho druhého.) Linus Torvalds není přesvědčen, že se jedná o problém, který by bylo potřeba řešit:

    Opravdu si myslím, že uživatelský prostor by si měl filtrování zajistit sám – nikdo nedělá jenom 'cat' na dmesg. A jestli jo, můžou si za to sami.

    A afaik neošetřujeme escape sekvence ani na úrovni konzole, takže konzoli nelze řídícími znaky nijak zmást.

    A nejnebezpečnější znak je ten, který nefiltruješ: ten, na který skutečně reagujeme, je '\n' a matoucí zprávy v logu bys mohl potenciálně vytvořit tak, že do svého řetězce zabuduješ novou řádku a potom se pokusíš, aby zbytek vypadal nějak špatně (třeba jako oops)

    Vzhledem k Linusově skepticismu se nezdá, že by se patch dostal někam dál, i kdyby se použil přístup s blacklistem, který navrhuje Ingo. Je to, nebo by alespoň měla být, poměrně nevýznamná záležitost, i když spor o blacklistu vs. whitelistu pravděpodobně uvidíme znovu. Je spousta příkladů, kdy se v kontextu zabezpečení (i jiných) používají obě tyto techniky. Často se jedná o výběr mezi bezpečností (typicky whitelisting) a větší použitelností (blacklisting). Tento případ není nijak odlišný a určitě se objeví i jiné.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    12.7.2011 02:20 pc2005 | skóre: 34 | blog: GardenOfEdenConfiguration | liberec
    Rozbalit Rozbalit vše Re: Jaderné noviny – 30. 6. 2011: Regrese správy napájení ve 2.6.38
    Hmm rošáda s ioctl mě připadá jako pěkně hnusnej hack :-/, ale je možné, že jsem už propadl démonu optimalizace :-D. Jinak ty escape sekvence jsou vtipný, tuhle jsem se snažil udělat vlastní superuniverzální printf a nakonec jsem došel k názoru, že by detektor formátu musel fungovat rekurzivně sám na sebe :-D. Ale řešit escape sekvence kvůli potenciální kompromitaci je imho overkill, abych pravdu řekl, tak možnost, že by to šlo použít napadl až po přečtení :-D.

    BTW Ten rudej efekt neuzavřenýho tagu na nadpisy v menu je hustej :-O.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    12.7.2011 10:15 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Jaderné noviny – 30. 6. 2011: Regrese správy napájení ve 2.6.38
    BTW Ten rudej efekt neuzavřenýho tagu na nadpisy v menu je hustej :-O.
    Pravdu díš..
    12.7.2011 02:28 add.
    Rozbalit Rozbalit vše Re: Jaderné noviny – 30. 6. 2011: Regrese správy napájení ve 2.6.38
    Jak se řeší ASPM ve windows (mohlo by to fungovat i v linuxu), pokud to může bios tak strašně konit?
    12.7.2011 03:49 pc2005 | skóre: 34 | blog: GardenOfEdenConfiguration | liberec
    Rozbalit Rozbalit vše Re: Jaderné noviny – 30. 6. 2011: Regrese správy napájení ve 2.6.38
    Řekl bych, že to bude podobný jako ta nedávná diskuze o rebootu (otestuje několikrát dostupnost a kdyžtak se na to vykašle). Je taky možný, že windowsům vyjde BIOS vstříc.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    pushkin avatar 12.7.2011 07:17 pushkin | skóre: 42 | blog: FluxBlog
    Rozbalit Rozbalit vše Re: Jaderné noviny – 30. 6. 2011: Regrese správy napájení ve 2.6.38
    A nebo je prostě možné, že ASPM explicitně zapínají ovladače od výrobce daného hardware (základní desky). Vzhledem k faktu, že ovladače od výrobce pod Windows instalují prakticky všichni, odůvodňovalo by to, proč prakticky nikdo pod Windows podobný problém nepozoruje.
    "...viděl jsem Vás žíznit a tak jsem se vrátil." | Díky, Kájo!
    12.7.2011 12:56 JoHnY2
    Rozbalit Rozbalit vše Re: Jaderné noviny – 30. 6. 2011: Regrese správy napájení ve 2.6.38
    Drivery jsou vetsinou primo od intelu pro chipset a vyrobci desek na ne nesahaj. Jestli je v tech driverech jakejsi whitelist nebo blacklist by nemelo bejt slozity zjistit a Intel by mel sam mit zajem na tom aby na jeho HW chodilo ASPM spravne i v Linuxu.

    Taky je klidne mozny, ze widle udelaj pri prvni startu s ASPM nejaky strasny veci a kdyz se jim system slozi (to se snadno pozna), tak se prestanou v ASPM vrtat.
    Ravensun avatar 12.7.2011 16:36 Ravensun | skóre: 11 | blog: Ravensun's blog | Praha
    Rozbalit Rozbalit vše Re: Jaderné noviny – 30. 6. 2011: Regrese správy napájení ve 2.6.38
    Taky je klidne mozny, ze widle udelaj pri prvni startu s ASPM nejaky strasny veci....
    Voodoo :D

    či

    Imperius :D

    ? :D
    Gentoo je můj poslední velký linux test...
    12.7.2011 20:16 JoHnY2
    Rozbalit Rozbalit vše Re: Jaderné noviny – 30. 6. 2011: Regrese správy napájení ve 2.6.38
    Pravdepodobne oboji :-O ... MS je totiz mistr spinavejch reseni.
    13.7.2011 09:57 koudy
    Rozbalit Rozbalit vše Re: Jaderné noviny – 30. 6. 2011: Regrese správy napájení ve 2.6.38
    S tim bohuzel nelze nez souhlasit :) I kdyz uz se sem tam snazi dodrzovat sve standary (i kdyz to musi bejt nekdy makacka..)
    13.7.2011 01:45 Sten
    Rozbalit Rozbalit vše Re: Jaderné noviny – 30. 6. 2011: Regrese správy napájení ve 2.6.38
    ASPM se sděluje přes ACPI, které rozlišuje operační systémy, takže je klidně možný, že Windows to BIOS řekne správně, ale Linuxu (a jiným systémům, které výrobce netestoval) řekne nějakou blbost.
    13.7.2011 11:53 Roger
    Rozbalit Rozbalit vše Re: Jaderné noviny – 30. 6. 2011: Regrese správy napájení ve 2.6.38
    Linux se uz nejakou dobu kvuli podobnym vecem hlasi jako Windows, ne?
    13.7.2011 13:03 Sten
    Rozbalit Rozbalit vše Re: Jaderné noviny – 30. 6. 2011: Regrese správy napájení ve 2.6.38
    Ne, nehlásí a nehlásil. Navíc windowsí implementace ACPI je taková podivná, třeba u některých informací to používá BCD (0x10) pro hodnoty (10), i když podle standardu tam BCD nikde není.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.