Nalezen první bug způsobující vyšší spotřebu v Linuxu

ahaho, ten phoronix nebidaj ma nejaku uroven

Škoda, že zprávička neobsahuje už aktualizovaný článek... přitom stačilo prokliknout Twitter, kde už nějakých šest hodin leží tenhle odkaz:

http://www.phoronix.com/scan.php?page=article&item=linux_2638_aspm&num=1

A v čem byl teda háček?

problem byl v aspm, podivej se, co mas v /sys/module/pci­e_aspm/parame­ters/policy

nejlip kdyz tam je powersave, jestli nejde zapnout pak je potreba pridat parametr jadra pcie_aspm=force

ale pry jeste alespon jedna starsi regrese zustava

To je problem? Ja v tom problem nevidim. Staci sa pozriet ako dlho trva oprava chyb Microsoftu. Takto sa pise kvalitny SW?

No, prave, ze u Linuxu by clovek doufal v lepsi odezvu.

Mno... Neprekvapilo by me, kdyby tomu nekdo trochu "pomohl"....

Když může bezpečnostní díra přetrvat roky od W2K až do W7... ;-)

asi to nikoho zvlášť netrápilo. 10 % je pár minut, to se ztěží pozná jestli to nebylo náhodou způsobeno nějakou zvýšenou zátěží.

Ten "amater" to vyresil tak, ze dostal od Intelu nejakou 16ti procesorovou mrchu,
na ktery kompiloval ruzny kernely a v elektr. siti mel pripojenej notebook pres specialni zarizeni, ktery mu ukazovalo spotrebu. Jestli jsem to pochopil dobre tak na to neprisel analyzou kodu ale "pulenim intervalu".
Ten patch kterej to zpusobil, bohuzel resi problemy pri suspend/resume na zabugovanych biosech. Takhle to dopada, kdyz se MS zusastni vytvareni nejakyho standartu - vznikne MS only technologie. To neni jen ACPI treba i HPET. Ne ze by to na linuxu nefungovalo, clovek si ale musi poradne davat bacha co si kupuje.

Ono je to ale o tom, že sa neprispôsobuje MS ale výrobci to kurvia dovtedy, dokedy to na MS OS nepôjde :/

A není na tom náhodou vidět komunitní přístup k psaní SW? MS má svoje certifikační testy, kde důkladně zjišťuje, jestli HW s jeho SW spolupracuje. Když výrobce udělá někde chybu, neprojdou mu MS testy, a certifikaci nedostane.
Kdyby Linux vyvíjela slušná komerční firma, tak by (vyjma jiných změn) zřejmě existoval certifikační program, který by zjišťoval kompatibilitu HW. Bohužel Linux nejen nemá funkční certifikační program (vyjma databází, kde Franta napíše, že mu nová síťovka doma funguje), ale ani nástroje pro hledání bugů v power managementu. Co brání mít v Linuxu zjišťovadlo nejčastějích bugů HW v oblasti power managementu? Co takovému nástroji brání v odeslání reportu do centrální DB (aby bylo možné masírovat výrobce HW), a případnému nastavení workaroundu v konfiguraci daného stroje? Už dávno mohla být vyřešená celá škála problémů, kde má Linux mizernou výdrž na baterky, neusíná, neprobouzí se ze spánku apod.
Můj názor? MS je (nejen) v power managementu tak 10-15 let napřed.

snip

Co brání mít v Linuxu zjišťovadlo nejčastějích bugů HW v oblasti power managementu?

/snip

A jak by takové zjišťovadlo testující mraky nejrůznějšího hardwaru v oblasti PM mělo vypadat?

Mimochodem, vůbec by mě nepřekvapilo, kdyby postup, který použil ten chlápek z phoronixu (tedy scm bisect v kombinaci s wattmetrem s automatizovatelným odečtem) v MS ještě nikdo nerealizoval. Pokud jo, určitě už na něj mají patent :)

Jak by to mohlo vypadat? Pro inspiraci si nabootujte Windows 7, spusťte "powercfg -energy", a prohlédněte si výsledný report v %system32%\energy-report.html. Dozvíte se které power states systém podporuje, které drivery brání přechodu do kterého power state, varování, chyby atd. Navíc bych čekal aplikaci workaroundů (tj. změn konfigurace) v reakci na známé chyby HW.
BTW kdyby chtěl někdo napsat článek o power managementu v Linuxu, byl by to chvályhodný počin. Určitě by nejen mě zajímalo, jestli drivery poskytují interface pro device states, jestli aplikace a drivery dostávají notifikace při změně global state, jak vypadá implementace ACPI Machine Language atd.

Postup, který použil ten chlápek z phoronixu, je dost divoký. Čekal bych spíš že to bude řešit někdo, kdo má dobrý přehled v power managementu obecně i v implementaci na Linuxu, a bude to řešit analýzou nějakého power management trace logu, kouknutím do vývojářské dokumentace, do kódu atd. Ne že by improvizace toho člověka byla špatná věc, spíše naopak. Ale improvizace většinou znamená, že pro danou situaci neexistuje "standardní" postup, což je špatně.

Jestli jsem to dobře pochopil, byl problém na hardwarově podstatně nižší úrovni, než standardní power stavy Sx, což je to, co řeší ten powercfg. Ten by v tomto případě zřejmě nijak nepomohl. Kouknutí do dokumentace by nijak nepomohlo, když byl problém v tom, že výrobci desek právě standard nedodržovali.

Powercfg není nástroj pro debugging power managementu, takže by opravdu nepomohl. Nicméně takhle nějak může vypadat nástroj pro automatické hledání známých bugů a aplikaci workarounds.
Z nástrojů MS můžete na troubleshooting použít PwrTest a log files (pwrmgmt.log, PwrProvider.log), možná s nastavením dalších log levels.

Kouknutí do trace log files a dokumentace by u většiny problémů naopak pomoci mělo.

15 let napred? To jsi asi trochu prehnal. Pred 15ti lety jeste neexistovalo ani ISA PnP.

Power management (tehdy APM) měly už Windows 95. ACPI je z roku 1996, jeho podporu měly Windows 98.

To máte jako s windowsem, kde mraky chyb nikdy nebyly vyřešeny a nikdy nebudou. Takhle se nepíše kvalitní sw. ;) Nicméně to, že si toho nikdo nevšiml dříve, je trestuhodné, to máte pravdu.

Nebude to spíš tím, že 10 % nikoho nepálí, neboli jde o podružný problém? Co?

Jsem zde nový. Jádro Linuxu obsahuje chybu. Proč si zde tedy téměř každý bere do úst Windows? Co to má společného s problémem jádra?

party moze zacat! je tu troll...