cynyr: The vendors are not fixing it, so what are we suppose to do in the meantime?
Announcement
Collapse
No announcement yet.
Linux 3.2 Is Still Looking To Be Power Hungry
Collapse
X
-
Again I think the Distributions are the problem
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.
Comment
-
Results
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).
Comment
-
-
Originally posted by del_diablo View Postcynyr: The vendors are not fixing it, so what are we suppose to do in the meantime?
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
-
Originally posted by cynyr View PostEdit 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.
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
-
Originally posted by cynyr View PostRight but doesn't setting this to "on" when the hardware really doesn't support cause breakage?
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.
Comment
Comment