Energiegebruikprobleem van Linux-kernel verholpen

Er is een oplossing voor het Active State Power Management -probleem van de Linux-kernel, die er voor zorgt dat laptops met het besturingssysteem een aanzienlijk kortere accuduur hebben dan voor de release van Linux-kernel 2.6.38.

Na het uitbrengen van Linux-kernel 2.6.38, ontdekten veel Linux-gebruikers dat de accuduur van hun laptop aanzienlijk verslechterd was. Het probleem speelde bij alle distributies en werd herleid tot een verandering in kernel 2.6.38, die ervoor zorgde dat Active-State Power Management uitgeschakeld werd als het bios van een systeem het gebruik ervan niet nadrukkelijk toestond. Active-State Power Management, of aspm, is onderdeel van de pci-e-specificatie en het protocol zorgt ervoor dat systeemonderdelen minder energie gebruiken bij inactiviteit.

Het bleek echter dat veel systemen wel degelijk aspm ondersteunden, zonder dat dit viel af te leiden uit het bios. De ACPI Description Table gaf bij een groot aantal moederborden niet aan dat de feature ondersteund werd, terwijl dit wel het geval was. Het inschakelen van aspm is te forceren via het commando "pcie_aspm=force" tijdens het booten van de kernel, maar deze oplossing vereist dat de gebruiker al weet dat hij met problemen kampt en de fix vergt bovendien kennis die veel gebruikers niet hebben.

Werkelijke oplossingen bleven maandenlang uit, ook na het verschijnen van de kernelversies 2.6.39, 3.0 en 3.1. Red Hat-ontwikkelaar Matthew Garrett heeft nu echter een patch voorgesteld die soelaas biedt en die nabootst hoe Windows met de feature omgaat. De patch zorgt ervoor dat aspm alleen uitgeschakeld wordt als het platform nadrukkelijk pci-e-beheer toestaat. In overige gevallen blijft aspm ingeschakeld, ook als geen nadrukkelijke ondersteuning voor de feature wordt vermeld door het bios.

Uit de eerste testen van de site Phoronix blijkt dat het energiegebruik van een geteste laptop weer terug is op het niveau van Linux-kernel 2.6.37 en eerdere versies. Garret heeft inmiddels meerdere patches uitgebracht. De site tekent aan dat er nog wel andere zaken met betrekking tot energiegebruik in de kernel onder handen genomen moeten worden.

Reacties (51)

[DeeD2k2]

Aangezien een gepatchte kernel maken nog lastiger is dan het boot commando aanpassen, hierbij de instructies om het bij je huidige Ubuntu installatie te doen. Dit kan vooral handig zijn omdat je anders waarschijnlijk op kernel 3.3 moet wachten (het merge window van versie 3.2 is namelijk net gesloten).

• Open de terminal en voer het commando gksudo gedit /etc/default/grub uit
• Verander de regel GRUB_CMDLINE_LINUX_DEFAULT="quiet splash quiet" in GRUB_CMDLINE_LINUX_DEFAULT="quiet splash quiet pcie_aspm=force"
• Opslaan en afsluiten
• Voer het commando sudo update-grub uit

[Superstoned]

Laat me dan de openSUSE tip toevoegen. Zoals gebruikelijk met openSUSE hoef je niet de command line op:

- start YaST van het menu en ga naar 'bootloader' (ik heb de engelse versie)
- klik op 'edit' en voeg 'pcie_aspm=force' toe aan de 'optional kernel command line parameter'
- klik OK. Je kunt nu evt andere kernels die je geinstalleerd hebt ook aanpassen. Zo niet, klik 'OK' en de wijziging is uitgevoerd.

* bonus tip: als je toch je boot loader aanpast, zet dan ook de 'VGA mode' op de resolutie van je scherm - en op 24 bits. Scheelt weer een 'flash' van het wisselen van scherm resolutie bij het opstarten en switchen naar de console

[Verwijderd]

Het is ook mogelijk om "pcie_aspm=force" toe te voegen aan de kernel config voordat er een nieuwe kernel gecompileerd wordt (door de Linux distro makers). Hierna hoeft je dus ook niets meer aan te passen bij GRUB of LILO. Deze optie is tijdens het configureren van de kernel te vinden onder "processor type and features" > "Build in kernel command line"

Daarnaast is het belangrijk om te weten dat bijna alle ACPI, SSDT, DSDT etc. BIOS code vaak geschreven zijn in een buggy Windows compiler. Hierdoor heeft Linux soms problemen met het automatisch detecteren van de mogelijke PM/ACPI functies ook al ondersteund de BIOS de Linux OSI. Meer info hier: http://en.gentoo-wiki.com...escription_of_the_Problem

Je kan ook proberen zelf een nieuwe tabel te compileren met een dergelijk iasl compiler en de volgende instructies: http://powersave.sourceforge.net/powersave/DSDT.html

Vaak is dit ook terug te vinden in de kernel log of met dmesg als bijvoorbeeld:
[Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
Fail in evaluating the _REG object of EC device. Broken bios is suspected.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 08:28]

[asx245]

Weet je ook hoe je dat bij Fedora doet?

[Verwijderd]

Voor Fedora:

sudo gedit /etc/grub.conf

Typ je paswoord in en enter

Gedit zou moeten starten met de configuratie file geopend.

Voeg volgende regel toe:

"pcie_aspm=force"

Bewaar en herstart.

[spectator]

Voor Fedora 16:

voeg de cmdline parameter toe aan de de regel in /etc/default/grub

en dan:
grub2-mkconfig -o /boot/grub2/grub.cfg

reboot.

[zenlord]

Toch even bij vermelden dat niet iedereen die linux gebruikt dit *moet* doen. Niet iedereen werd getroffen door dit probleem, dus enkel deze /hack/ toepassen als je zeker weet dat jouw systeem getroffen is.

[marcvangend]

In dat geval: hoe kan ik dan weten of mijn systeem last heeft van deze bug?

[DeeD2k2]

Doordat je merkt dat je laptop minder lang mee gaat dan voorheen, bijvoorbeeld bij de upgrade van Ubuntu 10.10 naar 11.04/11.10.

Overigens heeft het, voor zover ik weet, geen gevolgen om deze hack toe te passen als je niet "getroffen" bent. Ofwel, je kunt het altijd doen, mits je voorzichtig bent (zoals litemotiv en zenlord terecht aangeven).

[RobertMe]

Overigens heeft het, voor zover ik weet, geen gevolgen om deze hack toe te passen als je niet "getroffen" bent.

De patch naar de aanloop naar de 2.6.38 kernel was er niet voor niets. Op het moment dat er daadwerkelijk geen ondersteuning was voor ASPM maar de kernel dit wel gebruikte/wou gebruiken kon dit voor problemen zorgen. Daarom dus juist dat de patch er is gekomen die het in het BIOS checkt (waardoor ASPM dus weer veel te vaak niet gebruikt werd).

[spectator]

De patches zijn driver specifiek. ASPM wordt in de driver disabled. Welke drivers gepatcht moeten worden, daarvoor heeft Matthew in de Windows INF files moeten kijken.

[Reactie gewijzigd door spectator op 25 juli 2024 08:28]

[rob12424]

Is dit probleem eigenlijk na te trekken met systemtap?

http://stapgui.sourceforge.net/
http://sourceware.org/systemtap/wiki

Want als er een handige handleiding is kan iedereen het toch checken?

Dan weet je ook of je die hack moet uitvoeren?

[litemotiv]

Als de patch in de kernel wordt opgenomen is de kans 100% dat hij door Ubuntu gebackport zal worden.

Ik zou in ieder geval niemand aanraden om aan grub te gaan rommelen als ze niet precies weten waar ze mee bezig zijn, één letter teveel of te weinig en je systeem zal niet meer opstarten.

[finnfoto]

Als je benieuwd bent of jou moederbord last heeft van het verkeerd doorgeven van de ASPM is het overzicht op http://www.phoronix.com/s...?page=news_item&px=OTk4NQ wellicht handig.

The list below is what was generated by OpenBenchmarking.org for detected motherboards that are PCI Express enabled, but where the Fixed ACPI Description Table (FADT) claims that the Active State Power Management feature is not supported. To ensure some quality, each motherboard in the list had at least two unique submissions where ASPM could be detected as not working due to the ACPI table.

Via "dmidecode" onder "Base Board Information" heb ik in mijn geval het type van mijn laptop's moederbord kunnen achterhalen.

[marcvangend]

Durft iemand een schatting te doen hoe lang het nog zal duren voor deze fix terug te vinden is in mainstream Linux distributies als Ubuntu, Mint, Fedora etc?

[Superstoned]

Natuurlijk: in de nieuwe versies. openSUSE 12.1 komt woensdag uit dus dat gaat em niet worden. Volgende releases van Ubuntu en Fedora zijn April volgend jaar en openSUSE 12.2 komt over 8 maanden, da's July 2012, uit.

Je kunt natuurlijk vrij eenvoudig zelf de nieuwere kernel installeren als ie uit is. De meeste distro's hebben een repository met nieuwere kernels en je kunt hun ontwikkel versie natuurlijk draaien maar da's flink onstabiel.

Voor openSUSE ga je naar kernel.opensuse.org of beter nog - je gaat over op Tumbleweed en je hebt sowieso altijd de laatste stabiele software zonder maanden wachten zoals bij de meeste distro's


Gr
Jos

[hostname]

De kernel waar deze patch in komt (waarschijnlijk 3.2) komt er pas bij de volgende release. Nu zijn er ook vrij veel distributies die patches zoals deze backporten, dus er is eigenlijk niks zinnigs over te zeggen. Het zou best kunnen dat deze patch volgende week in Ubuntu zit; maar ook dat hij er pas over 6 maanden is.

[DeeD2k2]

De merge window van 3.2 is al gesloten (lees: er worden geen nieuwe functies meer toegevoegd, enkel worden bestaande onderdelen bijgeschaafd). Waarschijnlijk zit het dus pas in versie 3.3 van de mainline kernel.
Echter, het is de distributeurs natuurlijk vrij om oudere kernels te patchen. Het kan dus veel eerder...

[hostname]

Ik kan me eerlijk gezegd wel voorstellen dat Linus een patch als deze toch nog toe laat na het sluiten van het merge window. Gezien het uitblijven van replys op lkml lijkt het er echter toch op dat het inderdaad pas 3.3 gaat worden.

[zenlord]

Reken maar op 9-12 maanden vooraleer een kernel wordt gereleased waarin dit is opgenomen. Daarna is het gokken afhankelijk van de distro die je gebruikt. Een rolling release zal dit waarschijnlijk binnen enkele weken na verschijnen oppikken, maar als je debian stable gebruikt, dan zal je nog wel wat langer moeten wachten

[Mijzelf]

maar als je debian stable gebruikt, dan zal je nog wel wat langer moeten wachten

Maar ja, de keerzijde van de medaille: de huidige kernel van Squeeze is 2.6.32, en bevat deze 'bug' dus nog niet.

[i-chat]

reken er anders maar dik op dat dit gewoon in de volgende ubuntu 12.04 komt... als de kernel 3.0 (of welke ubuntu ook gaat pushen, deze patch nog niet heeft dan zal die gewoon door cononical worden gebackport dit zijn namelijk 'fixes' die nagenoeg weinig impact hebben.

[McCloud]

Aangezien Matthew een kernel developer van Red Hat is, neem ik aan/hoop ik, dat de kernel in Fedora (= Red Hat sponsored community project, oftewel de distro waaraan deze jongens zitten te sleutelen) redelijk snel gepatched zal worden.

[_Thanatos_]

Paar weken? Die distro's kunnen toch ook updates downloaden, zonder het hele OS te upgraden, dus een kernel patch kan daar ook tussen zitten.

[Verwijderd]

Lijkt wel of er altijd wel iets mis is met Linux als je het op een notebook wil installeren. Toen ik er een tijdje geleden naar keek was er een probleem met harde schijven. Ze zouden sneller defect gaan door te vaak overschrijven of iets dergelijks. Nu weer de accu en nog steeds is het niet mogelijk om te switchen met Optimus.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 08:28]

[rob12424]

Als je wat beter zoekt. Linux is van oorsprong een Server besturingssysteem en daarom staan alle logfuncties aan! Die logs kan hij soms idd een beetje teveel gebruiken. Dit kun je uitzettten en is voornamelijk met ssd´s van belang.

Er waren bepaalde ssd´s die crashten en toen werd het aan het vele schrijven toe gerekend. Achteraf bleek er wat anders fout te zijn en was het zo dat omgerekend met de zwaarste berekening je ssd pas na min. 100 jaar het niet meer deed door teveel overschrijvingen.

Je kan Linux met een ssd 3/4 sneller maken door die logfunccties uit te zetten en je levensduur van je ssd daarmee vergroten. Let er wel op die logfuncties zitten er niet voor niets in!

[UPPERKEES]

Je kan /var/log (log partitie) ook gewoon op een andere schijf zetten. Ook kan je in /etc/fstab en met hdparm je schrijf settings tot in de nopjes tweaken. Samen met nog een hoop kernel tweaks in /etc/sysctl.conf, je kan vast nog

Linux is meer dan alleen een besturingssysteem, het is ook een hobby. Als je geen extra hobby zoekt dan kan je beter geen Linux nemen. Zo zie ik het tenminste.

[kh65]

Zo zie je maar weer.
Is het eigenlijk een probleem van de BIOS waardoor Linux,
die netjes probeert te zijn, minder goed in powersaving mode gaat.
Waar je ook al niet bij stil moet staan als ontwikkelaar...

[humbug]

Dit is natuurlijk wel iets wat eenvoudig te testen is. Dat deze bug in 4 kernel releases zit en niet eerder is opgelost zegt veel over de prioriteiten van de ontwikkelaars. Die ligt dus niet bij linux op je laptop.

[labtech]

niks bug..Dit zegt meer over moederbordfabrikanten van laptops... Standaarden, waarom zou je je eraan houden...

[BeosBeing]

Beiden hebben jullie gelijk.
Moederbordfabrikanten willen zo goedkoop mogelijk produceren en dus als het werkt is het goed genoeg, waarbij er inderdaad allen naar Windows gekeken wordt. Op het moment dat iets wel vereist is wordt het ingebouwd, maar dat aanpassen, ook al is het slechts eenmalig, kost geld.

Bij de kernel-ontwikkelaars ligt inderdaad de prioriteit bij high-end-systemen met ik dacht minimaal 12-cpu-cores, niet bij notebooks. Gezien de monolitische kernel meer aansluit bij eenvormigere systemen (notebooks zijn eenvormiger als desktops/workstations en servers, er zit minder vaak bijzondere, uitzonderlijke of zeldzame hardware in) is dat op zich ook onlogisch.

.

[SED]

en luisteren naar je klanten.. oh wacht het zijn geen" klanten dus prioriteiten liggen al snel ergens anders.

[CAPSLOCK2000]

Gewone eindgebruikers maken nog helemaal geen gebruik van deze kernels, daar zijn ze nog te nieuw voor. Pas sinds een maand ofzo zijn er distributies die deze kernels uberhaupt gebruiken. Nu is er een oplossing, die zal wel snel als quickfix worden verspreidt.
Als je echter Ubuntu LTS, RHEL of Debian Stable gebruikt dan heb nog een kernel die hier geen last van heeft. De enige mensen die hier last van hebben zijn de gebruikers die altijd direct het nieuwste van het nieuwste installeren en die kunnen over het algemeen wel omgaan met dit soort probleempjes.

[spectator]

ASPM is juist disabled vanaf 2.6.38 omdat er devices waren waarmee dit verkeerd ging. Heeft niks te maken met bleeding edge willen zijn.

[Stevie-P]

Kernel 2.6.38 is oa opgenomen in de updates van ubuntu, en er zijn een heleboel 'gewone eindgebruikers' die automatische updates aan hebben staan.
Kijken welke kernel jij in gebruik hebt kan met 'uname -a'.

[Verwijderd]

Dit is natuurlijk wel iets wat eenvoudig te testen is. Dat deze bug in 4 kernel releases zit en niet eerder is opgelost zegt veel over de prioriteiten van de ontwikkelaars. Die ligt dus niet bij linux op je laptop.

Heeft niks met de kernel te maken maar aan de mamaplanken makers

[wica]

Mooi dat dit opgelost wordt, maar komt als ik het dus goed lees op neer dat de fabrikant van de moederborden zicch niet netjes aans de specs hebben gehouden.

[Verwijderd]

Die fabrikanten hebben een lange geschiedenis van precies net genoeg implementeren zodat Windows werkt en de rest laten zitten. Vandaar ook de ophef over secure boot, ervaringen uit het verleden laten zien dat de motivatie van bios-Fabrikanten om andere systemen te ondersteunen 0,niks is.

[Xenan]

Als ik het artikel zo lees past ook Microsoft een work around toe, dus ligt het toch aan de moederbordfabrikanten.

[MSalters]

Nee. De ACPI tabellen zijn OS-dependent. In dit geval is de Windows ACPI tabel correct (ASPM ondersteund) en hoeft Windows dus geen workaround te doen.

[Verwijderd]

Nee. De ACPI tabellen zijn OS-dependent. In dit geval is de Windows ACPI tabel correct (ASPM ondersteund) en hoeft Windows dus geen workaround te doen.

Vista had wel deglijk last hier van toen het uitkwam

[SED]

ACPI is een oorspronkelijke Wintel ontwikkeling.
Daar zal de oorzaak ook wel liggen.

http://en.wikipedia.org/w...ation_and_Power_Interface

[asx245]

Eindelijk :-) Ik dacht eerst dat linux geen combinatie van sandy bridge en nvidia (hybride graphics) kon combineren, mijn Windows installatie werkte bijna dubbel zo lang op batterij als op linux!

[RobertMe]

Linux ondersteund NVidia Optimus (zoals dat heet) ook niet. Ik weet niet precies hoe het zit, maar het kan ook zijn dat je NVidia kaart continue aan staat, maar hij niet gebruikt wordt. De kaart wordt in ieder geval niet gebruikt (omdat Linux dus geen hybride graphics ondersteund), of hij aan of uit staat durf ik niet te zeggen. Als ie aan staat heb je dus alsnog "een probleem" (stroomgebruik door hardware die never nooit gebruikt wordt).

[Verwijderd]

Tussen de oudere kernels zit ook verschil leek het, ik deed een upgrade van 2.6.35-22 naar -30 en het vebruik nam gelijk 6 watt toe. Weer gedowngrade en het verbuik is wederom terug op het oude level.

[Verwijderd]

Ik wil ook graag terug naar een vorige kernel maar weet niet hoe
(ubuntu)

[Speeder]

Idd, herkenbaar probleem, diverse asus netbooks worden in de BIOS ook niet goed uitgelezen met als gevolg dat bij de bootloader commandline de ACPI geforceerd moet worden waar door opeens de helderheid een stuk omhoog wordt geschroefd.

[UPPERKEES]

"Het inschakelen van aspm is te forceren via het commando "pcie_aspm=force" tijdens het booten van de kernel, maar deze oplossing vereist dat de gebruiker al weet dat hij met problemen kampt en de fix vergt bovendien kennis die veel gebruikers niet hebben."


Zoals sommige tweakers al hebben aangegeven, is dit helemaal niet moeilijk om te fixen voor een Linux gebruiker. Het is gewoon wat aanpassen in Grub. En het weten dat je het probleem hebt is ook niet zo lastig vast te stellen, je laptop gaat namelijk sneller leeg... Voor een desktop is het wel lastiger, maar als je op de hoogte bent van dit probleem ga je als je daar niet lekker mee zit wel achter komen. Ikzelf heb een Zalman fancontroller met een energie verbruik functie, maar ja die heeft niet iedereen natuurlijk.