Mageia forum

Hello everybody,

I have acquired a new laptop a couple weeks ago. Of course the first thing I did was install mageia 2. This step was more or less easy, and everything worked quite well, I always use the dvd (dumped to a USB since this computer doesn't has DVD reader), and only install non free software when there is no option.

The problem appeared when using it relying on it's battery, noticed that the battery drained too fast, a simple test gave me only 2:30 hours while the same test gave me more than 4 hours with the default SO (windows 8). Furthermore the default SO is installed in a conventional disk while mageia is on a SSD I bought just to gain some battery life.

The test by the way was to run the nyan cat video (10h long and 240p resolution) on youtube fullscreen without screensaver and fixed screen bright at 50%.

The conclusion is that something weird happens in with mageia2.

The laptop is a sony E11 with a CPU AMD E2-1800. I spent a lot of hours looking if there is any known bug with this hardware but found nothing. Also have been searching if there is any bug in the kernel that prevents the power saving features to be used but also found nothing. The last thing read was about powertop bu i'm not sure what should be the normal output on that software, but found this part quite disturbing:



Comparing this to my old laptop using an atom CPU seems that the problem is that this one is always at it's max speed no matter what the demands are, and that's it I don't know what else to try.

My rig is running mageia 2 64bit with the kernel 3.3.8-netbook-2.mga2 and KDE as desktop environment.

Don't know what to do now , any comment is welcome.

I had a similar 100% cpu problem with an old AMD desktop I had. Always worked fine with kernels up to 3.1, but when I upgraded it to the 3.2+ versions I started getting 100% cpu usage with nothing using it. Searching with "top" and "htop" and several other system monitors showed nothing using more than a few percent of the cpu, and even those that were, added together, didn't come close to 100%. After weeks of scanning Google searches and trying all kinds of tests and suggestions, I finally stumbled on the culprit: the hardware timer and my video card for some reason were sharing the same interrupt. Why this happened with the newer kernels I have no idea. I ended up having to add "biosirq" to the grub configuration to get it working right. According to kernel.org this is not a recommended way to do things, as it could cause other problems, but in my case it fixed the problem and I didn't see any adverse effects.

I don't know if you're having the same problem, but it wouldn't hurt to check and see if there's anything sharing an interrupt that shouldn't be. You can find out by running this in a console and looking at the results:

Code: Select all

watch -n1 'cat /proc/interrupts'

This will show a "live" table of all the system interrupts, meaning you'll see some of them changing, especially the timer ones. There shouldn't be two things using the same interrupt, each should have it's own. When two share an interrupt it keeps the kernel having to sort out how to process them, and because a timer one happens so fast it ended up making the kernel "always on" more or less, resulting in the 100% cpu. And because the kernel itself isn't a "process", it doesn't show up in top or any of the other system monitors. When you're done looking at the table, just press CTRL+Z to exit it.

I don't know if my old problem is the same as you're experiencing, but I figure it can't hurt to check. I also don't know if the fix that worked for me would help you, mine was an older desktop where yours is a newer laptop, but if you do find two interrupts sharing a space, at least it will give you some direction to go in searching for a solution.

Hope it helps.

Thanks for the quick answer. I don't think it's the same problem. Here it's the output of /proc/interrupts



If I understood you correctly the problem would be having more than one entry for a single IRQ, and well, it happens for things like hardware attached to the USB controllers (input devices and wireless card).

Anyhow I tried to add the option biosirq to the grub (pci=biosirq) and it said "unknown option". Which lead me to the following thought:

This laptop uses uefi instead of bios. In order to make the installation USB detected I had to change an option called "boot mode" from "uefi" to "legacy", not sure what the option does exactly. And now that I have got everything installed if I change again from "legacy" to "uefi" the OS isn't detected.

Can this be related?

It very well could be. I'm afraid I don't know anything about how the new computers switch from UEFI to "bios" or "legacy" boot, whether there's an actual bios chip or some kind of pseudo-bios supplied by the UEFI. I can see I'm going to have to look into that, until that whole hardware change gets figured out one way or another on Linux I can see this being a recurring problem.

Seeing you didn't mention anything about a process running amok, I think it's pretty safe to say the cpu usage (and hence the battery drain) is being caused by the kernel interacting with some piece of hardware that it's having a problem with. Or perhaps not interacting with something it should be, something in power management? Not knowing anything about how UEFI works I'm afraid I've run out of ideas. But I do think it's a path needing exploring.

If it is something with the UEFI / bios switching, whatever you find to fix it, it would be great if you post your solution here on the Mageia forums. With many of the new computers having UEFI it's logical you won't be the only one experiencing this problem. It could potentially help a lot of other people. In the meantime I'm going to see what I can learn about UEFI and it's "legacy" mode too, it's got me curious. If I find anything that may be useful I'll post back to you. Good luck with it.

Thanks a lot.

Your guess is right, the problem here is not the CPU usage. It's not near 100% and all the software behaves as expected.

From what I have gathered the most clear problem is that CPU frequency is fixed at it's max 1700Mhz, and this kind of hardware should be able to scale that frequency to the actual usage, indeed windows does it, and this must be just the top of the iceberg I bet that there are a lot of power management features that aren't being used.

I will try any live distro that is able to boot from uefi and make some tests.

the legacy mode you talk about is so that the computer can recognise MBR based boot devices.

mageia is currently an MBR based boot OS and as such needs legacy mode.

it has nothing to do with power.

you need to look at the tunables tab under powertop

for example having PCI devices on all the time can eat battery, so you can shut down pci devices when they are not used.

a custom udev rule can be created for that.

the tunables will hint at what can be fixed.

for example the output from mine.

Code: Select all

>> Bad           Wireless Power Saving for interface wlan0
   Bad           Enable SATA link power management for /dev/sda
   Bad           VM writeback timeout
   Bad           Enable Audio codec power management
   Bad           Autosuspend for USB device Microsoft® Nano Transceiver v2.0 [Microsoft]
   Bad           Autosuspend for USB device USB2.0-CRW [Generic]
   Bad           Autosuspend for unknown USB device 2-1.6 (8087:07da)
   Good          Bluetooth device interface status
   Good          Autosuspend for USB device USB2.0 HD UVC WebCam [Chicony Electronics Co.,Ltd.]
   Good          Autosuspend for USB device xHCI Host Controller [usb3]
   Good          Autosuspend for USB device xHCI Host Controller [usb4]
   Good          Autosuspend for USB device EHCI Host Controller [usb1]
   Good          Autosuspend for unknown USB device 1-1 (8087:0024)
   Good          Autosuspend for unknown USB device 2-1 (8087:0024)
   Good          Autosuspend for USB device EHCI Host Controller [usb2]
   Good          Runtime PM for PCI Device Intel Corporation Panther Point PCI Express Root Port 1
   Good          Runtime PM for PCI Device Intel Corporation Ivy Bridge DRAM Controller
   Good          Runtime PM for PCI Device Intel Corporation Panther Point USB xHCI Host Controller
   Good          Runtime PM for PCI Device Intel Corporation Panther Point MEI Controller #1
   Good          Runtime PM for PCI Device Intel Corporation Panther Point USB Enhanced Host Controller #2
   Good          Runtime PM for PCI Device Intel Corporation Panther Point High Definition Audio Controller
   Good          Runtime PM for PCI Device Intel Corporation Device 088e
   Good          Runtime PM for PCI Device Intel Corporation Panther Point 6 port SATA Controller [AHCI mode]
   Good          Runtime PM for PCI Device Intel Corporation Ivy Bridge Graphics Controller
   Good          Runtime PM for PCI Device Intel Corporation Panther Point USB Enhanced Host Controller #1
   Good          Runtime PM for PCI Device Intel Corporation Panther Point PCI Express Root Port 2
   Good          Wake-on-lan status for device wlan0
   Good          Wake-on-lan status for device tun0
   Good          Using 'ondemand' cpufreq governor


regads peter

Thanks. Certainly my output doesn't look quite correct.



I will try with different settings and see what happens.
.
By the way looking how to make changes in powertop permanents found this thread for ubuntu

http://askubuntu.com/questions/112705/h ... -permanent

One suggests how to enable the lapto-mode. But I don't have the files explained in that forum. How do I know if I have got that "laptop-mode" enabled in mageia.

By the way, is there an easy way to make changes to powertop permanents? Is it dangerous to change the tunables options?

as i already said you need to create a custom udev rule that applies to your hardware.

powertop will just shut down hardware and then you will find stuff does not work any longer.

you cant go disabling all usb devices so some will be needed , what this is doing is implementing a sleep for your hardware when its not in use, saving power and thats what needs to be implemented.


for example, from my laptop (and dont go doing this verbatum, you will need to find out for yourself if this applies)

Code: Select all

[root@localhost ~]# cat /etc/udev/rules.d/10-runtime-pm.rules
SUBSYSTEM!="pci", GOTO="power_runtime_rules_end"
ACTION!="add", GOTO="power_runtime_rules_end"

KERNEL=="????:??:??.?"
PROGRAM="/bin/sleep 0.1"

ATTR{power/control}=="*", ATTR{power/control}="auto"

LABEL="power_runtime_rules_end"


regards peter

The most important thing is to get the CPU frequency scaling working, which shouldn't need any custom udev rules. In a terminal, as root, please execute the following command:

Code: Select all

urpmi cpufreq


If this results in the cpufreq package being installed, reboot, and you should then see your CPU frequency change dynamically according to workload. If not, or if the cpufreq package was already installed, please post the output of the following commands:

Code: Select all

cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_driver
cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_governor
cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_available_governors
cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_available_frequencies


From the first and second screenshot the problem seems to me that the processor currently does not know/support any C states so the processor can only run at full speed and hence draws the full power. That's what needs fixing. Frequency scaling can only work if the processor and the board/chipset support that, which currently does not seem likely, at least not with the current configuration ...

Well I left all this a bit behind, no by my will though, spent a week at the hospital (don't worry it wasn't life threatening) and the next week catching up with my college assignments and my job.

Anyhow the package cpufreq was installed if it really helps there goes the content on the files listed by martinw

Code: Select all

cat: /sys/bus/cpu/devices/cpu0/cpufreq/scaling_driver: No existe el fichero o el directorio
[root@white ~]# cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_governor
cat: /sys/bus/cpu/devices/cpu0/cpufreq/scaling_governor: No existe el fichero o el directorio
[root@white ~]# cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_available_governors
cat: /sys/bus/cpu/devices/cpu0/cpufreq/scaling_available_governors: No existe el fichero o el directorio
[root@white ~]# cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_available_frequencies
cat: /sys/bus/cpu/devices/cpu0/cpufreq/scaling_available_frequencies: No existe el fichero o el directorio
[root@white ~]#


As you can see no one exists (yes, the output is in spanish, sorry, it's my native language). I simply don't have the folder cpufreq on my computer.

@doktor5000
What does means that the CPU "does not support C states", does this means that this function won't be ever available in linux or it's just a feature not implemented in the actual version of the kernel?

Where can I find information about this topic (CPU support in linux) because before buying it I searched for this kind of things and found nothing, I assumed that linux hadn't this limitation with the processor.

Thanks also wintpe your suggestion is very useful, I just need some free time to look into it.

asimov-solensan wrote:Where can I find information about this topic (CPU support in linux)

try this link:

https://wiki.archlinux.org/index.php/CPU_Frequency_Scaling

If /sys/bus/cpu/devices/cpu0/cpufreq does not exist, it is most likely that your processor is too new to be fully supported by the 3.3.8 kernel. Two things you could try are

• Try updating your Mageia-2 installation - there is now a 3.4.24 kernel available for Mageia-2.
• Try a beta release of Mageia-3 (beta 2 is due out soon), which has the latest stable kernel.

Note that Mageia-3 is still under development, so I wouldn't recommend it for regular use - testing it now will just let you know if it will fix your problem.

Well I'm almost sure that the problem is solved. A million thanks tom, the article he linked guided me to right clues. Just looking a bit here end there found this page:

http://wiki.debian.org/InstallingDebian ... 205/wheezy

It says that the driver/module that manages the CPU frequency in this laptop is the powernow-k8. And guess what? It wasn't loaded automatically on my machine. Once loaded the powertop output is what it should:

[IMG=http://img547.imageshack.us/img547/5498/freqstatslast.png][/IMG]


I won't say that it's totally solved because I have made a quick test and the frequency is still fixed from what I gather from /proc/cpuinfo, but this can be related to kde energy monitor or something else, doesn't worry me that much. I will write here when i find it.

Thanks a lot guys, hope this thread helps anyone with the same problem.

Ok, it's definitely solved. The last problem was that the cpufreq governor was "performance", i changed to "ondemand" with the cpupower tool and now it behaves right.

Thanks everybody for the help.

Please mark the topic accordingly asimov-solensan.

You can do so by editing title/subject of the first post in the topic.
Place [SOLVED] in the beginning of the title.

Thanks in advance!!!

My apologize, I'm used to other forums where this is made by the administrators.

Well, just did hope this helps other people.

Would you please be so kind and add that solution to the Errata below hardware issues:
https://wiki.mageia.org/en/Mageia_2_Err ... are_Issues
And best would be to open a bug for this so it gets resolved: https://wiki.mageia.org/en/How_to_report_a_bug_properly

Ok, did it.