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).
Created attachment 19231 [details] dmesg output right after boot
Created attachment 19232 [details] dmesg output right after the problem occured
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.
hmmm, this is an ec bug. please check if this is a duplicate of bug 12011/11884.
(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.
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.
(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.
Leonid, does the problem still exist in the latest upstream kernel? Alexey, what's the status of the bug?
Zhang, The problem definitely does exist in 2.6.29.
Leonid, Could you please check if disabling calls to acpi_ec_burst_enable() in drivers/acpi/ec.c helps?
(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.
(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.
(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);
Leonid, Please also try changing from udelay(...) to msleep(1) in addition to removing burst. Please post new dmesg if it does not help.
(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.
Created attachment 20806 [details] merge modes and disable burst Please check if this patch works too?
(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.
(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.
Ok, the last patch works for any time. I'm going to upgrade to (unpatched) 2.6.30-rc1.
closed due to in activity for 4 months please re-open if there is still a problem in 2.6.30.stable