Laptop becomes slow when charger is disconneted

I am trying to solve this problem and this is what I've found :

This is what appears when I disconnect the charger
[ 82.368392] [Firmware Bug]: battery: (dis)charge rate invalid.
[ 83.555021] =>>>>>>>>>>=============================>set power:0, 0!

This is what appears when I reconnect the charger
[ 108.701448] =>>>>>>>>>>=============================>set power:1, 0!

I've tried to update the kernel but the situation remains. So in my opinion this could be a Xorg or Kernel problem. But I'm starting to think that this isn't a Kernel problem (even knowing that the same message appears on the logs of the stock and updated kernel).

If it was a kernel problem then the CTRL+ALT+F1 workaround shouldn't work since this only interacts with Xorg no ?

I would first look at this documentation from Ubuntu:

Why is my laptop slow when it's on battery?

So this might not be a bug but a feature. You should check to see if you have CPU frequency scaling enabled.

I'm pretty sure it is a bug. Here is what I got.

The CPU Scalling is defined as Ondemand. The minimum is 800Mhz and the maximum is 2.40Ghz.

When I am on charger the CPU is always on 800Mhz until I do something that needs to use more resources (like opening the browser).

When I am on battery the same happens.

But here is what happens. I open a terminal an type "watch cpufreq-info", and then see it at 800mhz. I then connect the charger open the browser and see it scaling from 800Mhz to 2.40Ghz and going down again to 800Mhz when the browser is loaded. Then I disconnect the charger and do the same operation, but the CPU doesn't change from 800Mhz and it is slow to open, I can move the mouse anywhere on the screen nothing will change expect on one part.. the terminal.

If (when everything is slow to open) I put the mouse anywhere else with activity (like the bottom bar, or in this case, the Terminal with the command watch cpufreq-info running) then the CPU will scale from 800Mhz to 2.40Ghz and the browser will open normally.

So when I am on battery what I usually do is just move the mouse around until I found "the place" where it speeds up everthing (this is the same workaround as when I do CTRL+ALT+F1).

I will try to set it as "Performance" and see if it changes anything.

There is something else that I've found. The speed problem is solved when the icon of the mouse changes.

As an example, I open Abrowser and it is slow to open (very very slow), but if I put my mouse anywhere where his icon will change (like the corner of a window to resize, and this even without clicking) then the browser will open fast as it should.

I will post a view to show.

Here is the video showing the problem. I will test with nomodeset just to see if this is a Nouveau driver bug.

There is no problem with the nomodeset option enabled in the kernel line on grub. It is very probably a Nouveau problem.

The bug is very similar to this one:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/1005167

Some questions:

Are you using the default Trisquel desktop as shipped (i.e. any customizations other than the backgroud)?

What is the exact make and model (including any model subcodes from the label underneath) of this laptop and the bios version?

Are you testing with all optional peripherals removed? If not please do so.

Then please include the dmesg output immediately after both a mains and a battery boot. Then dmesg over an unplug event and separately over a plug event.

Also attach the output of

lspci -vv
lsusb -v
cat /proc/cpuinfo
cat /proc/interrupts

Before starting I want to thank you for trying to help.

I am using Trisquel 6.0 without any changes and without any additional peripherals.

My laptop is an MSI MS-1722 with a nVidia Geforce 9600M GT and a Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, and for the bios it is the A1722IG6 V1.0F version. More informations can be found here http://www.msiwhitebook.com/product_spec.asp?model=MS-1722-ID1.

As for the informations :

dmesg output with a charger

http://trisquel.info/files/dmesg_charger.txt

dmesg output on battery

http://trisquel.info/files/dmesg_battery.txt

lspci -vv

http://trisquel.info/files/lspci_vv.txt

lsusb -v

http://trisquel.info/files/lsusb_v.txt

cat /proc/cpuinfo

http://trisquel.info/files/cat_cpuinfo.txt

cat /proc/interrupts

http://trisquel.info/files/cat_interrupts.txt

Update:

Thanks to "lembas" from the forum, I've found that there is a workaround for this problem only by doing "sudo pm-powersave false" in the terminal.

Now I need to find how to solve the problem without forcing pm-powersave to false at each boot.

$ cat /etc/acpi/events/battery 
# /etc/acpi/events/battery
# Called when AC power goes away and we switch to battery

event=battery
action=/etc/acpi/power.sh

$ cat /etc/acpi/power.sh 
#!/bin/sh

test -f /usr/share/acpi-support/key-constants || exit 0

. /usr/share/acpi-support/policy-funcs

if [ -z "$*" ] && ( [ `CheckPolicy` = 0 ] || CheckUPowerPolicy ); then
    exit;
fi

pm-powersave $*

I am no bash expert, but commenting out the "pm-powersave $*" line should do the trick :-)

Perhaps you should study the behavior of the pm-powersave command, find and change its configuration files so to discover if you could keep using it to reduce your laptop's power consumption.

Beginning with "man pm-powersave":

FILES
       /etc/pm/power.d/, /usr/lib/pm-utils/power.d/
           When you run pm-powersave it combines the scripts in these two
           directories and executes them in sorted order. [...]

;-)

Hello,

Before anything, thanks for helping :D

I've already tried this by creating an empty file with the same name on /etc/pm/power.d/ directory one by one until I see what script from /usr/lib/pm-utils/power.d/ was doing the problem, but non of them solved (even after having all the scripts replaced).

I also know that the problem doesn't exist on Trisquel 5.5 but when I updated the Kernel using the linux-libre one the problem appeared so it seems to be related to the power management under the kernel (?).

Other than that, I've also noticed that it doesn't occur on KDE, and better, it doesn't occur on openbox UNTIL I open a gnome application like nautilus... (I didn't tried with any KDE application)...

So I don't know either how to solve this, or where to report :S

Sorry if I'm starting to get boring with this thing but I really liked to solve this in order to continue using Trisquel :S

I also noticed that Ubuntu 12.04 didn't had that problem in the same way. I only noticed a 5 seconds delay until any folder get open in Nautilus, but nothing different for any other application like Firefox, Gedit or Terminal.

So why does this only happens in Trisquel 5.5 with an update 3.7.x kernel or in Trisquel 6.0 with the original kernel (and also the 3.7.x update)