If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Comment

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).

Comment

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.

Comment

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

Comment

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.

Comment

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.