Bug 12187 - battery status info dissapears in 2.6.27.5 - MSI PR200
battery status info dissapears in 2.6.27.5 - MSI PR200
Status: CLOSED UNREPRODUCIBLE
Product: ACPI
Classification: Unclassified
Component: EC
All Linux
: P1 normal
Assigned To: Alexey Starikovskiy
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-09 14:06 UTC by Leonid Podolny
Modified: 2009-08-29 18:26 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.28-rc5, 2.6.28-rc7
Tree: Mainline
Regression: Yes


Attachments
dmesg output right after boot (113.88 KB, text/plain)
2008-12-09 14:08 UTC, Leonid Podolny
Details
dmesg output right after the problem occured (119.70 KB, text/plain)
2008-12-09 14:09 UTC, Leonid Podolny
Details
merge modes and disable burst (9.53 KB, patch)
2009-04-05 06:43 UTC, Alexey Starikovskiy
Details | Diff

Description Leonid Podolny 2008-12-09 14:06:45 UTC
Latest working kernel version:2.6.27.4
Earliest failing kernel version:2.6.27.5
Distribution: Gentoo
Hardware Environment: MSI PR200
Software Environment:
Problem Description:
http://bugzilla.kernel.org/show_bug.cgi?id=10855
https://bugs.gentoo.org/show_bug.cgi?id=248452

Some time after booting the laptop the system stops seeing the battery and ac_adapter info in /proc/acpi/{battery,ac_adapter}.

For example, with fully charged battery and power cable connected:
looptop ~ # cat /proc/acpi/battery/BAT1/state
present:                 no
looptop ~ # cat /proc/acpi/ac_adapter/ADP1/state
state:                   off-line

The problem existed before 2.6.26-rc6, then, in 2.6.26-rc6 it stopped happening. Then I switched to stable gentoo kernels, and it resurfaced at upgrade from gentoo-sources-2.6.27-r1 to gentoo-sources-2.6.27-r4, based on vanilla 2.6.27.3 and 2.6.27.7, respectively. The offending patch was a patch upgrading from 2.6.27.4 to 2.6.27.5. Then I reproduced the problem on 2.6.28-rc5.
I'm attaching the dmesg output (with DEBUG printouts from drivers/acpi/ec.c).
Comment 1 Leonid Podolny 2008-12-09 14:08:11 UTC
Created attachment 19231 [details]
dmesg output right after boot
Comment 2 Leonid Podolny 2008-12-09 14:09:23 UTC
Created attachment 19232 [details]
dmesg output right after the problem occured
Comment 3 Leonid Podolny 2008-12-09 14:15:13 UTC
In 2.6.28 the problem occurs very rarely, sometimes days after the boot. However, if I turn on debug printouts in ec.c, it takes literally minutes to happen. I don't understand much in ACPI, but it probably means that the bug is triggered by timing, and the problem was never solved, but just stopped happening because of the other changes in kernel.
Comment 4 Zhang Rui 2008-12-09 18:18:58 UTC
hmmm, this is an ec bug.
please check if this is a duplicate of bug 12011/11884.
Comment 5 Leonid Podolny 2008-12-09 23:51:55 UTC
(In reply to comment #4)
> hmmm, this is an ec bug.
> please check if this is a duplicate of bug 12011/11884.
> 

bug 12011 definitely looks similar.
Comment 6 ykzhao 2008-12-10 19:09:28 UTC
Hi, Leonid
    Thanks for the detailed info.
    From the log in comment #2 it seems that the incorrect acknowledge byte is returned after issuing the EC burst command. The acknowledge byte should be 0x90.
    >[  626.317039] ACPI: EC: transaction start
[  626.317047] ACPI: EC: <--- command = 0x82
[  626.317156] ACPI: EC: ---> status = 0x1b
[  626.317162] ACPI: EC: ---> data = 0x09

    Will you please check whether this bug is the duplicate of bug 11892?
    Thanks.
Comment 7 Leonid Podolny 2008-12-10 22:48:23 UTC
(In reply to comment #6)

>     Will you please check whether this bug is the duplicate of bug 11892?
>     Thanks.
> 
Hi, 
I think that it's not, because the fix for the bug 11892 is shipped in 2.6.28-rc4 and I'm running 2.6.28-rc7, which should already include the fix.
Comment 8 Zhang Rui 2009-03-30 07:18:01 UTC
Leonid,
does the problem still exist in the latest upstream kernel?

Alexey,
what's the status of the bug?
Comment 9 Leonid Podolny 2009-03-30 07:22:35 UTC
Zhang,
The problem definitely does exist in 2.6.29.
Comment 10 Alexey Starikovskiy 2009-03-30 08:46:27 UTC
Leonid,
Could you please check if disabling calls to acpi_ec_burst_enable() in drivers/acpi/ec.c helps?
Comment 11 Leonid Podolny 2009-03-30 14:42:56 UTC
(In reply to comment #10)
> Leonid,
> Could you please check if disabling calls to acpi_ec_burst_enable() in
> drivers/acpi/ec.c helps?

It is now working without problems for 4 or so hours, definite improvement. However, some of the patches in bug 12011 also reduced the frequency of the the bug and it reproduced after more than a day.
Comment 12 Leonid Podolny 2009-03-31 20:46:08 UTC
(In reply to comment #10)
> Leonid,
> Could you please check if disabling calls to acpi_ec_burst_enable() in
> drivers/acpi/ec.c helps?

Alexey,
It still dissapears after a (long) while.
Comment 13 Leonid Podolny 2009-03-31 20:47:21 UTC
(In reply to comment #10)
> Leonid,
> Could you please check if disabling calls to acpi_ec_burst_enable() in
> drivers/acpi/ec.c helps?

Here is what I've done, just to make sure that I understood you correctly:
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 2fe1506..eaa4224 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -355,7 +355,8 @@ static int acpi_ec_burst_enable(struct acpi_ec *ec)
                                .wdata = NULL, .rdata = &d,
                                .wlen = 0, .rlen = 1};

-       return acpi_ec_transaction(ec, &t, 0);
+       //return acpi_ec_transaction(ec, &t, 0);
+       return 0;
 }

 static int acpi_ec_burst_disable(struct acpi_ec *ec)
@@ -607,7 +608,7 @@ acpi_ec_space_handler(u32 function, acpi_physical_address address,
        if (bits != 8 && acpi_strict)
                return AE_BAD_PARAMETER;

-       acpi_ec_burst_enable(ec);
+       //acpi_ec_burst_enable(ec);

        if (function == ACPI_READ) {
                result = acpi_ec_read(ec, address, &temp);
Comment 14 Alexey Starikovskiy 2009-03-31 22:53:48 UTC
Leonid,
Please also try changing from udelay(...) to msleep(1) in addition to removing burst. Please post new dmesg if it does not help.
Comment 15 Leonid Podolny 2009-04-04 19:11:06 UTC
(In reply to comment #14)
> Leonid,
> Please also try changing from udelay(...) to msleep(1) in addition to removing
> burst. Please post new dmesg if it does not help.

Works OK for three days now.
Comment 16 Alexey Starikovskiy 2009-04-05 06:43:01 UTC
Created attachment 20806 [details]
merge modes and disable burst

Please check if this patch works too?
Comment 17 Leonid Podolny 2009-04-06 05:50:12 UTC
(In reply to comment #16)
> Created an attachment (id=20806) [details]
> merge modes and disable burst
> 
> Please check if this patch works too?

9 hours, looks good.
Comment 18 Leonid Podolny 2009-04-06 05:50:53 UTC
(In reply to comment #17)
> (In reply to comment #16)
> > Created an attachment (id=20806) [details] [details]
> > merge modes and disable burst
> > 
> > Please check if this patch works too?
> 
> 9 hours, looks good.

I meant, 19 hours.
Comment 19 Leonid Podolny 2009-04-11 11:29:35 UTC
Ok, the last patch works for any time.
I'm going to upgrade to (unpatched) 2.6.30-rc1.
Comment 20 Len Brown 2009-08-13 03:14:12 UTC
closed due to in activity for 4 months
please re-open if there is still a problem in 2.6.30.stable

Note You need to log in before you can comment on or make changes to this bug.