Linux 3.2 Is Still Looking To Be Power Hungry

[del_diablo]

cynyr: The vendors are not fixing it, so what are we suppose to do in the meantime?

[blackiwid]

Why do they not just ask on the installation such a question like is your pc a notebook and from this century, or something like that.

Or they just define that the distribution is not for older hardware, they did skip i386 support at some time too. so maybe there are then other distries that supports older hardware.

btw I just try to make this phoronix test stuff, it takes hours till it loads all the files it needs.

[blackiwid]

So,

I tried to use the phoronix test suite I even downloaded the newer versinon as deb file and installed it, the test did run 1 time after that it never did again. So that was a pain in the ass.

But now I just used:
watch -n1 'cat /proc/acpi/battery/BAT1/*'

tried it with and without this kernel option. It was nearly not messuarable what the difference was, its idle with max brightness of the monitor and wlan on
without the option 12400 mW and with the option 12200-12300 mW so its only 1-2% difference I dont think thats a big problem. Its nearly not worth the effort to change the file for 1-2% more akku time. its for my long akku runtime of ~7hours maybe 5 mins more.

I dont know if its for another load or another hardware more but here that was very disapointing did hope for a bigger difference. btw thats a lenovo e325 (zacate sys).

[not.sure]

I dont know if its for another load or another hardware more but here that was very disapointing did hope for a bigger difference. btw thats a lenovo e325 (zacate sys).

I'm not.sure, but IIRC this specific ASPM problem was only on intel systems.

[blackiwid]

lol that explains much than I look into it again with my intel netbook.

[cynyr]

cynyr: The vendors are not fixing it, so what are we suppose to do in the meantime?

Edit your grub.conf, open a ticket with your distro, and/or call/write the support for your computer and ask them to fix it, carry a power cord or spare battery with you.

I'm not a kernel dev, but I've seen this sort of thing before and the kernel almost always picks the spec and assumes the hardware doesn't lie. IDE HDs and if they are done writing, ACPI, hard drive sector size. Of course there are some work-arounds in the kernel the intel FPU bug comes to mind, and i'd bet a fair amount of the ALSA drivers as well.

[cyring]

Edit your grub.conf, open a ticket with your distro, and/or call/write the support for your computer and ask them to fix it, carry a power cord or spare battery with you.

I'm not a kernel dev, but I've seen this sort of thing before and the kernel almost always picks the spec and assumes the hardware doesn't lie. IDE HDs and if they are done writing, ACPI, hard drive sector size. Of course there are some work-arounds in the kernel the intel FPU bug comes to mind, and i'd bet a fair amount of the ALSA drivers as well.

That bug seems still opened
monitored with the powertop running with ArchLinux 64 bits, Linux 3.1.x
kworker threads display more than 60% of kernel wake-ups
when the last is idling
Btw, system is a Core i7 8 cores, speedstep, hyperthreading, C6 state, OC 3.2GHz, VTx, everythings activated

[halo9en]

I've been testing the it87 driver and noticed my Vcore was 1.08 instead of 0.96 when idle. (...) anything under 2.6 gives me 2.6, 2.6-3.1 GHz speeds work as expected. There is an unpassable floor at 2.6.

Scary. Can someone else confirm this, or has that been fixed in 3.2 ?

[leeenux]

Right but doesn't setting this to "on" when the hardware really doesn't support cause breakage?

This is based on the original assumption of the problem, which turned out to be wrong. The kernel devs are now saying that they were misunderstanding the spec when they decided to turn it off the first time, and that it's actually OK to turn it on.

The problem is ACPI, which is a poorly documented clusterfuck of a standard Intel created, and then they allowed Microsoft to twist the arms of motherboard manufacturers to use it as a tool to make it difficult to support various hardware with an x86 OS. There are famous emails subpoenaed from Bill Gates himself during the Microsoft anti-trust hearings in the 90s, discussing ways to use ACPI to sabotage Linux. It obviously worked, as we have these kind of bugs in the mainline kernel, because motherboard manufacturers won't reveal how their ACPI implementation works for fear of what the Microsoft mafia will do to them. Of course, nobody thinks to blame Microsoft or Intel for the problem, it must always be Linus' fault.