battery and thermal dissappears after few minutes of booting. on msi ex600 laptop

What bugs me, is that the battery detected all right during the boot,
and on a side note.
As long as the status of the battery changes, what I mean is, if I to start working on battery to drain it a little, and then plug the AC in, as long as the battery is not fully charged the status will be correct, but after a few minutes of complete charge, when the state no longer changes, the battery state will disappear.

Hi anagor,

Which specific 2.6.27-6 kernel version was working and which specific 2.6.27-7 kernel this began failing. For example was it working in say 2.6.27-6.9 and began failing with say 2.6.27-7.10 ? You can find this specific version by doing 'cat /proc/version_signature' . That can at least help narrow down where a patch may have been introduced that causes this regression. The changelog can be seen at:

https://edge.launchpad.net/ubuntu/+source/linux/

It's likely the best solution would be to do a git bisect to narrow down the offending patch. Would you be comfortable doing a git bisect - http://www.kernel.org/doc/local/git-quick.html#bisect . I've previously tried to outline performing a git bisect on an Ubuntu kernel in another bug report - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/273266/comments/6 so that may help. Let me know if you have any questions. Thanks.

Hi Leann,
The first part of your question will be easy to answer, in 2.6.27-6.9, which is the last of the 27-6 it was still working.
But on the very first of 27-7, which was 2.6.27-7.10 I think, it wasn't, and it still doesn't work on 2.6.27-7.13.
So I'm pretty sure it was some patch introduced in the 2.6.27-7.10 version.
As to the second part of your question, I can try to do git bisect myself, it will probably take me until the begging of the next week, but I should try nevertheless.
However, should you prefer a more quick solution, I suspect that the offending patch is this one:
linux (2.6.27-7.10) intrepid; urgency=low

  [ Alexey Starikovskiy ]

  * SAUCE: ACPI: EC: do transaction from interrupt context
    - LP: #277802

you can see the original here:
http://lkml.org/lkml/2008/10/11/43

My suspicion with this patch is because I know that on this line of laptops from MSI, the BIOS EC region is not standard compliant, as you can see in the following:
http://bugzilla.kernel.org/show_bug.cgi?id=9697
and
http://bugzilla.kernel.org/show_bug.cgi?id=9627

So there is a good chance that this specific patch by Alexey Starikovskiy is the problematic one, as it is the only one I saw that changes the ACPI EC directly.
So if you are not too busy :) and have the opportunity to create a kernel without this patch before I do, please let me know and I will try it.
Thanks a lot.

Hi anagor,

Let me try to build a .deb for you to install with that patch removed so you can test it. Thanks.

Ok, here's a .deb of the kernel to try.

Ohh, I'm sorry, but this is i386 and I need a 64 bit one :(/
If you think that it will be quicker for you to attach the source, I will recompile it myself rather then for you to compile and upload it again.

Ok, that'll work better since I don't have a 64bit arch machine here. I've attached the patch that we want to try reverting. Basically do the following:

$ sudo apt-get install git-core linux-kernel-devel fakeroot build-essential makedumpfile
$ git clone git://kernel.ubuntu.com/ubuntu/ubuntu-intrepid.git
$ cd ubuntu-intrepid
$ patch -p1 -R < 286169.patch
$ CONCURRENCY_LEVEL=2 AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-generic skipabi=true

Once that finishes building there should be something like linux-image-2.6.27-7-generic_2.6.27-7.14_i386.deb one directory level above the ubuntu-intrepid directory.

The following wiki also described building the Ubuntu kernel source - https://help.ubuntu.com/community/Kernel/Compile

Hope that helps. Thanks.

Well, I'm happy to say that it works, without this patch, the kernel is correctly detects GPE storm and starts working in polling mode instead of interrupt mode.

Oct 24 23:29:13 mark-laptop kernel: [ 0.600610] ACPI: EC: non-query interrupt received, switching to interrupt mode
Oct 24 23:29:13 mark-laptop kernel: [ 0.608051] ACPI: EC: GPE storm detected, disabling EC GPE
Oct 24 23:29:13 mark-laptop kernel: [ 1.108037] ACPI: EC: missing confirmations, switch off interrupt mode.
Oct 24 23:29:13 mark-laptop kernel: [ 1.153390] ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
Oct 24 23:29:13 mark-laptop kernel: [ 1.153390] ACPI: EC: driver started in poll mode

So the battery and temperatures are detected correctly and everything is working ok.

Thanks anagor. So the patch in question was actually cherrypicked form the upstream kernel. But I'll notify the kernel team of the regression it introduced. However, I'm curious if you'd be willing to test the upstream vanilla kernel as well to verify if this issue exists upstream as well and if reverting the patch resolves the issue. Information on how to build the upstream kernel from git can be found at https://wiki.ubuntu.com/KernelTeam/GitKernelBuild . Thanks.

I will try with the vanilla kernel, though I'm sure of the outcome, I also know that the kernel team won't consider the bug seriously enough until it can be proved that the vanilla have the same behavior.

Thanks.

Ok, I've tried the vanilla kernel, currently its 2.6.28-rc2.
Sure enough the problem exists there, here is the relevant exert from dmesg:

[ 0.156016] ACPI: EC: non-query interrupt received, switching to interrupt mode
[ 0.172212] PCI: MCFG area at e0000000 reserved in ACPI motherboard resources
[ 0.185424] PCI: Using MMCONFIG at e0000000 - efffffff
[ 0.193727] ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
[ 0.193727] ACPI: EC: driver started in interrupt mode

full dmesg.log is attached.
also, this kernel I've loaded without any restricted drivers, like nvidia for example, so it won't taint the kernel.
So the problem is the mentioned patch. and it still exists in 2.6.28-rc2 vanilla.

Thanks.

Hi anagor,

Thanks for all the testing and the feedback. It's greatly appreciated. Since you've confirmed this also exists in the upstream kernel I think it would be good if an upstream bug report would also be opened at http://bugzilla.kernel.org . That way the upstream developers are also notified of the issue. So if it's not too much extra trouble, care to open the upstream report as well since you have the affected hardware and can confirm the issue with the patch. We can also link this report to the upstream report. Thanks.

Ok, I've submitted this bug to kernel.org's bugzilla,
you can see it here:
http://bugzilla.kernel.org/show_bug.cgi?id=11892

I don't know how to add a watch for remote bug reports, but you probably do :)

Thanks.

Ohh, I see it was added automatically.

I think we can close/mark as fix released this bug safely now.
The patches that fixed this issue are in the mainline kernel now, and I tested the 2.6.27-10 ubuntu kernel which have those patches in it already, and it all works well.

Thanks.

@anagor -- thanks for the heads up. I have read through the upstream bug, good work there with those guys to find and fix this one. I have checked our 2.6.27-10.20 release and it does indeed contain the upstream fix from upstream. That came through as part of the 2.6.27.7 stable updates.

Moving this Fix Committed as this is in -proposed.

Marking this Fix Released as the current 2.6.27-11.31 kernel is currently available through -updates.

https://edge.launchpad.net/ubuntu/+source/linux