Low throttling always active : machine very slow

Bug #199391 reported by Baptiste MATHUS
2
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Hi all,
1) baptiste@pumte:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu hardy (development branch)"

Laptop Inspiron 8600 pentiuum M1.6Ghz.

For a week or so now, it seems like the kernel upgrade made something wrong. In fact, it seems like the system is always running under its max performance possibilities.

This could be normal if it didn't resulted in a slow system, but the machine is almost unusable. The process of opening a new tab and loading a new page in firefox can easily takes for examples up to 2 or 3...

Let's precise I didn't have any problem before. I finally decided to log this bug because as I said, my system is becoming (almost) unusable.

Additional info : this morning when I started it, the system was normally responsive. In fact, when Iooking at the throttling in /proc, the state was T0 (100%).
After a few seconds, as my system was becoming to behave like a 386, I gave another look and saw the system had just switched to T6 (25%) :-/ :
baptiste@pumte:~$ cat /proc/acpi/processor/CPU0/throttling
state count: 8
active state: T6
state available: T0 to T7
states:
    T0: 100%
    T1: 87%
    T2: 75%
    T3: 62%
    T4: 50%
    T5: 37%
   *T6: 25%
    T7: 12%

I perfectly understand that the throttling could be useful when being on battery or when idle, but for those tests, Iaunched firefox, a video, and had the charging plugged...

Let me know if you need any other information.

Thanks a lot.

Revision history for this message
Baptiste MATHUS (ml-batmat) wrote :

One precision: after booting, the machine always behaves correctly for some minutes. Throttling state is T0 at this moment.

Then at some point (when starting a video, or having firefox with more than 5 or 6 tabs, the fan starts to rotate and looking at the throttling informations shows that it switched to T6 mode.

I noticed I can switch to T7 state when being root and echoing 7 to the proc/acpi/processor/CPU0/throttling file. But echo anything lower than 6 has no effect.

I logged this bug here because I'm using hardy and I thought you'd be interested knowing about that potential new problem. Please let me know if I should instead use some forums or anything else.

Thanks a lot.
Cheers.

Revision history for this message
ski (skibrianski) wrote :

I am having the same problem with hardy on amd64. When I am plugged in, I get 2333MHz (which is right). When I am not plugged in, my laptop always gets the lowest available frequency (1000MHz in my case).

cpufreq-selector -f 2333000
will occasionally work for me, but usually only lasts less than a second, even with the cpu freq. governor set to cpufreq_userspace.

I tried the workaround in
http://ubuntuforums.org/showthread.php?t=760282, but it doesn't work for me.

This is a really annoying bug, makes it impossible to watch x264 videos unless I am plugged in (among other things).

Revision history for this message
Ian Weisser (ian-weisser) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Ubuntu release? Thanks in advance.

Daniel T Chen (crimsun)
Changed in linux:
status: New → Incomplete
Revision history for this message
Ian Weisser (ian-weisser) wrote :

We're closing this bug since it is has been some time with no response from the original reporter.

However, if the issue still exists please feel free to reopen with the additional information required by the Ubuntu Kernel Team:
1. Please include the output of the command "uname -a" in your next response. It should be one, long line of text which includes the exact kernel version you're running, as well as the CPU architecture.
2. Please run the command "dmesg > dmesg.log" after a fresh boot and attach the resulting file "dmesg.log" to this bug report.
3. Please run the command "sudo lspci -vvnn > lspci-vvnn.log" and attach the resulting file "lspci-vvnn.log" to this bug report.

For your reference, the full description of procedures for kernel-related bug reports is available at https://wiki.ubuntu.com/KernelTeamBugPolicies

Changed in linux:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.