Bug 12187

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