2.6.28-rc1: rapid hotkeys break on eeepc again :(

2.6.28-rc1: rapid hotkeys break on eeepc again :(

[Alan Jenkins]

Similar but different to the original symptoms of bugzilla #11089 (which
is closed, fixed by the specific patch I tested).  Hotkeys give up the
ghost after being held down for a while, or pressed rapidly.  However
they don't get "out of sync" as in that bug.  I've already tried the
acpi-test tree, but that didn't fix it.

Bad: v2.6.28-rc1
Good: v2.6.27-89-g3156d1e

I can't see any non-trivial changes to the EC or eeepc-laptop drivers in
that range, so it looks like I have to do this the hard way.

Bisecting: 3857 revisions left to test after this

Ow.

Alan

Re: 2.6.28-rc1: rapid hotkeys break on eeepc again :(

[Alexey Starikovskiy]

Please check if changing msleep to udelay helps.
Alan Jenkins wrote:
> Similar but different to the original symptoms of bugzilla #11089 (which
> is closed, fixed by the specific patch I tested).  Hotkeys give up the
> ghost after being held down for a while, or pressed rapidly.  However
> they don't get "out of sync" as in that bug.  I've already tried the
> acpi-test tree, but that didn't fix it.
>
> Bad: v2.6.28-rc1
> Good: v2.6.27-89-g3156d1e
>
> I can't see any non-trivial changes to the EC or eeepc-laptop drivers in
> that range, so it looks like I have to do this the hard way.
>
> Bisecting: 3857 revisions left to test after this
>
> Ow.
>
> Alan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   

Re: 2.6.28-rc1: rapid hotkeys break on eeepc again :(

[Alan Jenkins]

Alexey Starikovskiy wrote:
> Please check if changing msleep to udelay helps.
> Alan Jenkins wrote:
>> Similar but different to the original symptoms of bugzilla #11089 (which
>> is closed, fixed by the specific patch I tested).  Hotkeys give up the
>> ghost after being held down for a while, or pressed rapidly.  However
>> they don't get "out of sync" as in that bug.  I've already tried the
>> acpi-test tree, but that didn't fix it.
That was in acpi-test, unless I misread the changelog.  It's the main
reason I tried that, I should have mentioned it, sorry.   So no, it
didn't help.

Thanks
Alan

Re: 2.6.28-rc1: rapid hotkeys break on eeepc again :(

[Alexey Starikovskiy]

Alan Jenkins wrote:
> Alexey Starikovskiy wrote:
>> Please check if changing msleep to udelay helps.
>> Alan Jenkins wrote:
>>> Similar but different to the original symptoms of bugzilla #11089 (which
>>> is closed, fixed by the specific patch I tested).  Hotkeys give up the
>>> ghost after being held down for a while, or pressed rapidly.  However
>>> they don't get "out of sync" as in that bug.  I've already tried the
>>> acpi-test tree, but that didn't fix it.
> That was in acpi-test, unless I misread the changelog.  It's the main
> reason I tried that, I should have mentioned it, sorry.   So no, it
> didn't help.
Any luck with bisect? 

Re: 2.6.28-rc1: rapid hotkeys break on eeepc again :(

[Alan Jenkins]

Alexey Starikovskiy wrote:
> Alan Jenkins wrote:
>> Alexey Starikovskiy wrote:
>>> Please check if changing msleep to udelay helps.
>>> Alan Jenkins wrote:
>>>> Similar but different to the original symptoms of bugzilla #11089
>>>> (which
>>>> is closed, fixed by the specific patch I tested).  Hotkeys give up the
>>>> ghost after being held down for a while, or pressed rapidly.  However
>>>> they don't get "out of sync" as in that bug.  I've already tried the
>>>> acpi-test tree, but that didn't fix it.
>> That was in acpi-test, unless I misread the changelog.  It's the main
>> reason I tried that, I should have mentioned it, sorry.   So no, it
>> didn't help.
> Any luck with bisect? 

It didn't seem to like what I gave it.  I ended up at a commit which
lacked the EC rewrite - when as far as I'm concerned, I'm tracking a
regression from after that point.

So I tried some manual fiddling, and I'm now starting a bisect between
two different points on mainline.  That's got to work :).  It looks like
it broke sometime after the main merge from the acpi tree.

$ git-describe
v2.6.27-7166-g765426e
$ git-bisect good
$ git-bisect bad v2.6.28-rc1
Bisecting: 215 revisions left to test after this

Re: 2.6.28-rc1: rapid hotkeys break on eeepc again :(

[Alan Jenkins]

Alan Jenkins wrote:
> Alexey Starikovskiy wrote:
>   
>> Alan Jenkins wrote:
>>     
>>> Alexey Starikovskiy wrote:
>>>       
>>>> Please check if changing msleep to udelay helps.
>>>> Alan Jenkins wrote:
>>>>         
>>>>> Similar but different to the original symptoms of bugzilla #11089
>>>>> (which
>>>>> is closed, fixed by the specific patch I tested).  Hotkeys give up the
>>>>> ghost after being held down for a while, or pressed rapidly.  However
>>>>> they don't get "out of sync" as in that bug.  I've already tried the
>>>>> acpi-test tree, but that didn't fix it.
>>>>>           
>>> That was in acpi-test, unless I misread the changelog.  It's the main
>>> reason I tried that, I should have mentioned it, sorry.   So no, it
>>> didn't help.
>>>       
>> Any luck with bisect? 
>>     
>
> It didn't seem to like what I gave it.  I ended up at a commit which
> lacked the EC rewrite - when as far as I'm concerned, I'm tracking a
> regression from after that point.
>
> So I tried some manual fiddling, and I'm now starting a bisect between
> two different points on mainline.  That's got to work :).  It looks like
> it broke sometime after the main merge from the acpi tree.
>
> $ git-describe
> v2.6.27-7166-g765426e
> $ git-bisect good
> $ git-bisect bad v2.6.28-rc1
> Bisecting: 215 revisions left to test after this
>   

Well, that didn't work.

I wasn't quite methodical enough.  It depends on my doing something...
it might be the lid switch, or using the sound, or network, or switching
from battery to AC, or removing the battery...

So it needn't be a regression from the patches I tested before.  More
likely it's a problem with certain action(s) that I've only performed
recently.

Alan

Re: 2.6.28-rc1: rapid hotkeys break on eeepc again :(

[Alexey Starikovskiy]

Alan Jenkins wrote:
> Well, that didn't work.
Pity...
Could you produce a debug log from EC?
Probably it's a good time to open a new bug report...

Regards,
Alex.

Bisection result: eeepc hotk breakage

[Alan Jenkins]

Alexey Starikovskiy wrote:
>
> Alan Jenkins wrote:
>> Well, that didn't work.
> Pity...
> Could you produce a debug log from EC?
> Probably it's a good time to open a new bug report...

<http://bugzilla.kernel.org/show_bug.cgi?id=11917>
"Asus Eee PC hotkeys stop working after prolonged usage"

I stuck at it, found a reliable test and bisected successfully. 
2.6.28-rc2 is broken, but I can fix it by reverting the bad commit. 
(There were some conflicts, I fixed up the dock driver manually and
avoided building the rest).



27663c5855b10af9ec67bc7dfba001426ba21222 is first bad commit
commit 27663c5855b10af9ec67bc7dfba001426ba21222
Author: Matthew Wilcox <willy@linux.intel.com>
Date:   Fri Oct 10 02:22:59 2008 -0400

    ACPI: Change acpi_evaluate_integer to support 64-bit on 32-bit kernels

    As of version 2.0, ACPI can return 64-bit integers.  The current
    acpi_evaluate_integer only supports 64-bit integers on 64-bit platforms.
    Change the argument to take a pointer to an acpi_integer so we support
    64-bit integers on all platforms.

    lenb: replaced use of "acpi_integer" with "unsigned long long"
    lenb: fixed bug in acpi_thermal_trips_update()

    Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

Re: Bisection result: eeepc hotk breakage

[Alexey Starikovskiy]

Alan Jenkins wrote:
> Alexey Starikovskiy wrote:
>> Alan Jenkins wrote:
>>> Well, that didn't work.
>> Pity...
>> Could you produce a debug log from EC?
>> Probably it's a good time to open a new bug report...
> 
> <http://bugzilla.kernel.org/show_bug.cgi?id=11917>
> "Asus Eee PC hotkeys stop working after prolonged usage"
> 
> I stuck at it, found a reliable test and bisected successfully. 
> 2.6.28-rc2 is broken, but I can fix it by reverting the bad commit. 
> (There were some conflicts, I fixed up the dock driver manually and
> avoided building the rest).
Alan, to make things clear -- reverting following commit makes EC work without
a problem?

Thanks,
Alex.
> 
> 
> 
> 27663c5855b10af9ec67bc7dfba001426ba21222 is first bad commit
> commit 27663c5855b10af9ec67bc7dfba001426ba21222
> Author: Matthew Wilcox <willy@linux.intel.com>
> Date:   Fri Oct 10 02:22:59 2008 -0400
> 
>     ACPI: Change acpi_evaluate_integer to support 64-bit on 32-bit kernels
> 
>     As of version 2.0, ACPI can return 64-bit integers.  The current
>     acpi_evaluate_integer only supports 64-bit integers on 64-bit platforms.
>     Change the argument to take a pointer to an acpi_integer so we support
>     64-bit integers on all platforms.
> 
>     lenb: replaced use of "acpi_integer" with "unsigned long long"
>     lenb: fixed bug in acpi_thermal_trips_update()
> 
>     Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
>     Signed-off-by: Len Brown <len.brown@intel.com>

Re: Bisection result: eeepc hotk breakage

[Alan Jenkins]

Alexey Starikovskiy wrote:
>
> Alan Jenkins wrote:
>> Alexey Starikovskiy wrote:
>>> Alan Jenkins wrote:
>>>> Well, that didn't work.
>>> Pity...
>>> Could you produce a debug log from EC?
>>> Probably it's a good time to open a new bug report...
>>
>> <http://bugzilla.kernel.org/show_bug.cgi?id=11917>
>> "Asus Eee PC hotkeys stop working after prolonged usage"
>>
>> I stuck at it, found a reliable test and bisected successfully.
>> 2.6.28-rc2 is broken, but I can fix it by reverting the bad commit.
>> (There were some conflicts, I fixed up the dock driver manually and
>> avoided building the rest).
> Alan, to make things clear -- reverting following commit makes EC work
> without
> a problem?
>


Yes, that's right.


>>
>>
>> 27663c5855b10af9ec67bc7dfba001426ba21222 is first bad commit
>> commit 27663c5855b10af9ec67bc7dfba001426ba21222
>> Author: Matthew Wilcox <willy@linux.intel.com>
>> Date:   Fri Oct 10 02:22:59 2008 -0400
>>
>>     ACPI: Change acpi_evaluate_integer to support 64-bit on 32-bit
>> kernels
>>
>>     As of version 2.0, ACPI can return 64-bit integers.  The current
>>     acpi_evaluate_integer only supports 64-bit integers on 64-bit
>> platforms.
>>     Change the argument to take a pointer to an acpi_integer so we
>> support
>>     64-bit integers on all platforms.
>>
>>     lenb: replaced use of "acpi_integer" with "unsigned long long"
>>     lenb: fixed bug in acpi_thermal_trips_update()
>>
>>     Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
>>     Signed-off-by: Len Brown <len.brown@intel.com>
>

Re: Bisection result: eeepc hotk breakage

[Alexey Starikovskiy]

Alan Jenkins wrote:
> Alexey Starikovskiy wrote:
>> Alan Jenkins wrote:
>>> Alexey Starikovskiy wrote:
>>>> Alan Jenkins wrote:
>>>>> Well, that didn't work.
>>>> Pity...
>>>> Could you produce a debug log from EC?
>>>> Probably it's a good time to open a new bug report...
>>> <http://bugzilla.kernel.org/show_bug.cgi?id=11917>
>>> "Asus Eee PC hotkeys stop working after prolonged usage"
>>>
>>> I stuck at it, found a reliable test and bisected successfully.
>>> 2.6.28-rc2 is broken, but I can fix it by reverting the bad commit.
>>> (There were some conflicts, I fixed up the dock driver manually and
>>> avoided building the rest).
>> Alan, to make things clear -- reverting following commit makes EC work
>> without
>> a problem?
>>
> 
> 
> Yes, that's right.
Great!
What kernel version is that -- 32 or 64? 
> 
> 
>>>
>>> 27663c5855b10af9ec67bc7dfba001426ba21222 is first bad commit
>>> commit 27663c5855b10af9ec67bc7dfba001426ba21222
>>> Author: Matthew Wilcox <willy@linux.intel.com>
>>> Date:   Fri Oct 10 02:22:59 2008 -0400
>>>
>>>     ACPI: Change acpi_evaluate_integer to support 64-bit on 32-bit
>>> kernels
>>>
>>>     As of version 2.0, ACPI can return 64-bit integers.  The current
>>>     acpi_evaluate_integer only supports 64-bit integers on 64-bit
>>> platforms.
>>>     Change the argument to take a pointer to an acpi_integer so we
>>> support
>>>     64-bit integers on all platforms.
>>>
>>>     lenb: replaced use of "acpi_integer" with "unsigned long long"
>>>     lenb: fixed bug in acpi_thermal_trips_update()
>>>
>>>     Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
>>>     Signed-off-by: Len Brown <len.brown@intel.com>
> 

Re: Bisection result: eeepc hotk breakage

[Alan Jenkins]

Alexey Starikovskiy wrote:
> Alan Jenkins wrote:
>> Alexey Starikovskiy wrote:
>>> Alan Jenkins wrote:
>>>> Alexey Starikovskiy wrote:
>>>>> Alan Jenkins wrote:
>>>>>> Well, that didn't work.
>>>>> Pity...
>>>>> Could you produce a debug log from EC?
>>>>> Probably it's a good time to open a new bug report...
>>>> <http://bugzilla.kernel.org/show_bug.cgi?id=11917>
>>>> "Asus Eee PC hotkeys stop working after prolonged usage"
>>>>
>>>> I stuck at it, found a reliable test and bisected successfully.
>>>> 2.6.28-rc2 is broken, but I can fix it by reverting the bad commit.
>>>> (There were some conflicts, I fixed up the dock driver manually and
>>>> avoided building the rest).
>>> Alan, to make things clear -- reverting following commit makes EC work
>>> without
>>> a problem?
>>>
>>
>>
>> Yes, that's right.
> Great!
> What kernel version is that -- 32 or 64?

32 bit, my EeePC doesn't do 64.

>>
>>
>>>>
>>>> 27663c5855b10af9ec67bc7dfba001426ba21222 is first bad commit
>>>> commit 27663c5855b10af9ec67bc7dfba001426ba21222
>>>> Author: Matthew Wilcox <willy@linux.intel.com>
>>>> Date:   Fri Oct 10 02:22:59 2008 -0400
>>>>
>>>>     ACPI: Change acpi_evaluate_integer to support 64-bit on 32-bit
>>>> kernels
>>>>
>>>>     As of version 2.0, ACPI can return 64-bit integers.  The current
>>>>     acpi_evaluate_integer only supports 64-bit integers on 64-bit
>>>> platforms.
>>>>     Change the argument to take a pointer to an acpi_integer so we
>>>> support
>>>>     64-bit integers on all platforms.
>>>>
>>>>     lenb: replaced use of "acpi_integer" with "unsigned long long"
>>>>     lenb: fixed bug in acpi_thermal_trips_update()
>>>>
>>>>     Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
>>>>     Signed-off-by: Len Brown <len.brown@intel.com>
>>
>

Re: Bisection result: eeepc hotk breakage

[Alexey Starikovskiy]

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

Alan Jenkins wrote:
> Alexey Starikovskiy wrote:
>> Alan Jenkins wrote:
>>> Alexey Starikovskiy wrote:
>>>> Alan Jenkins wrote:
>>>>> Alexey Starikovskiy wrote:
>>>>>> Alan Jenkins wrote:
>>>>>>> Well, that didn't work.
>>>>>> Pity...
>>>>>> Could you produce a debug log from EC?
>>>>>> Probably it's a good time to open a new bug report...
>>>>> <http://bugzilla.kernel.org/show_bug.cgi?id=11917>
>>>>> "Asus Eee PC hotkeys stop working after prolonged usage"
>>>>>
>>>>> I stuck at it, found a reliable test and bisected successfully.
>>>>> 2.6.28-rc2 is broken, but I can fix it by reverting the bad commit.
>>>>> (There were some conflicts, I fixed up the dock driver manually and
>>>>> avoided building the rest).
>>>> Alan, to make things clear -- reverting following commit makes EC work
>>>> without
>>>> a problem?
>>>>
>>>
>>> Yes, that's right.
>> Great!
>> What kernel version is that -- 32 or 64?
> 
> 32 bit, my EeePC doesn't do 64.
is the attached patch enough to fix ?


[-- Attachment #2: x.patch --]
[-- Type: text/x-diff, Size: 426 bytes --]

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index ef42316..e0f1534 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -751,6 +751,7 @@ ec_parse_device(acpi_handle handle, u32 Level, void *context, void **retval)
 		return status;
 	ec->gpe = tmp;
 	/* Use the global lock for all EC transactions? */
+	tmp = 0;
 	acpi_evaluate_integer(handle, "_GLK", NULL, &tmp);
 	ec->global_lock = tmp;
 	ec->handle = handle;

Re: Bisection result: eeepc hotk breakage

[Rafael J. Wysocki]

On Friday, 31 of October 2008, Alan Jenkins wrote:
> Alexey Starikovskiy wrote:
> >
> > Alan Jenkins wrote:
> >> Alexey Starikovskiy wrote:
> >>> Alan Jenkins wrote:
> >>>> Well, that didn't work.
> >>> Pity...
> >>> Could you produce a debug log from EC?
> >>> Probably it's a good time to open a new bug report...
> >>
> >> <http://bugzilla.kernel.org/show_bug.cgi?id=11917>
> >> "Asus Eee PC hotkeys stop working after prolonged usage"
> >>
> >> I stuck at it, found a reliable test and bisected successfully.
> >> 2.6.28-rc2 is broken, but I can fix it by reverting the bad commit.
> >> (There were some conflicts, I fixed up the dock driver manually and
> >> avoided building the rest).
> > Alan, to make things clear -- reverting following commit makes EC work
> > without
> > a problem?
> >
> 
> 
> Yes, that's right.

Hm, so in fact it _is_ a regression from 2.6.27 (this commit could not be
present in that kernel).

Thanks,
Rafael


> >> 27663c5855b10af9ec67bc7dfba001426ba21222 is first bad commit
> >> commit 27663c5855b10af9ec67bc7dfba001426ba21222
> >> Author: Matthew Wilcox <willy@linux.intel.com>
> >> Date:   Fri Oct 10 02:22:59 2008 -0400
> >>
> >>     ACPI: Change acpi_evaluate_integer to support 64-bit on 32-bit
> >> kernels
> >>
> >>     As of version 2.0, ACPI can return 64-bit integers.  The current
> >>     acpi_evaluate_integer only supports 64-bit integers on 64-bit
> >> platforms.
> >>     Change the argument to take a pointer to an acpi_integer so we
> >> support
> >>     64-bit integers on all platforms.
> >>
> >>     lenb: replaced use of "acpi_integer" with "unsigned long long"
> >>     lenb: fixed bug in acpi_thermal_trips_update()
> >>
> >>     Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
> >>     Signed-off-by: Len Brown <len.brown@intel.com>
> >
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: Bisection result: eeepc hotk breakage

[Alan Jenkins]

Rafael J. Wysocki wrote:
> On Friday, 31 of October 2008, Alan Jenkins wrote:
>   
>> Alexey Starikovskiy wrote:
>>     
>>> Alan Jenkins wrote:
>>>       
>>>> Alexey Starikovskiy wrote:
>>>>         
>>>>> Alan Jenkins wrote:
>>>>>           
>>>>>> Well, that didn't work.
>>>>>>             
>>>>> Pity...
>>>>> Could you produce a debug log from EC?
>>>>> Probably it's a good time to open a new bug report...
>>>>>           
>>>> <http://bugzilla.kernel.org/show_bug.cgi?id=11917>
>>>> "Asus Eee PC hotkeys stop working after prolonged usage"
>>>>
>>>> I stuck at it, found a reliable test and bisected successfully.
>>>> 2.6.28-rc2 is broken, but I can fix it by reverting the bad commit.
>>>> (There were some conflicts, I fixed up the dock driver manually and
>>>> avoided building the rest).
>>>>         
>>> Alan, to make things clear -- reverting following commit makes EC work
>>> without
>>> a problem?
>>>
>>>       
>> Yes, that's right.
>>     
>
> Hm, so in fact it _is_ a regression from 2.6.27 (this commit could not be
> present in that kernel).
>   

Yes, I suppose it is distinct from the previous EC regression.

Re: Bisection result: eeepc hotk breakage

[Alan Jenkins]

Alexey Starikovskiy wrote:
> Alan Jenkins wrote:
>> Alexey Starikovskiy wrote:
>>> Alan Jenkins wrote:
>>>> Alexey Starikovskiy wrote:
>>>>> Alan Jenkins wrote:
>>>>>> Alexey Starikovskiy wrote:
>>>>>>> Alan Jenkins wrote:
>>>>>>>> Well, that didn't work.
>>>>>>> Pity...
>>>>>>> Could you produce a debug log from EC?
>>>>>>> Probably it's a good time to open a new bug report...
>>>>>> <http://bugzilla.kernel.org/show_bug.cgi?id=11917>
>>>>>> "Asus Eee PC hotkeys stop working after prolonged usage"
>>>>>>
>>>>>> I stuck at it, found a reliable test and bisected successfully.
>>>>>> 2.6.28-rc2 is broken, but I can fix it by reverting the bad commit.
>>>>>> (There were some conflicts, I fixed up the dock driver manually and
>>>>>> avoided building the rest).
>>>>> Alan, to make things clear -- reverting following commit makes EC
>>>>> work
>>>>> without
>>>>> a problem?
>>>>>
>>>>
>>>> Yes, that's right.
>>> Great!
>>> What kernel version is that -- 32 or 64?
>>
>> 32 bit, my EeePC doesn't do 64.
> is the attached patch enough to fix ?
>
Nice.  Yes, that fixes it, thanks!

I checked the commit diff for any similar potential errors.  Most of the
changes are "obviously correct".  However, there are changes in
thermal.c which look similar to the one that caused the problem in the
EC driver.

I think someone knowledgeable needs to audit the changes to the thermal
driver, in case the Thinkpads start melting again :-P.  The commit#
again: 27663c5855b10af9ec67bc7dfba001426ba21222.

Alan

Re: Bisection result: eeepc hotk breakage

[Alexey Starikovskiy]

Alan Jenkins wrote:
> Nice.  Yes, that fixes it, thanks!
>
>   
great, I've updated #11917.
> I checked the commit diff for any similar potential errors.  Most of the
> changes are "obviously correct".  However, there are changes in
> thermal.c which look similar to the one that caused the problem in the
> EC driver.
>
> I think someone knowledgeable needs to audit the changes to the thermal
> driver, in case the Thinkpads start melting again :-P.  The commit#
> again: 27663c5855b10af9ec67bc7dfba001426ba21222.
>
>   
no, everything is fine in thermal -- they check status after every call.

Thanks again,
Alex.

Re: Bisection result: eeepc hotk breakage

[Zhao Yakui]

On Fri, 2008-10-31 at 22:54 +0800, Alexey Starikovskiy wrote:
> Alan Jenkins wrote:
> > Alexey Starikovskiy wrote:
> >> Alan Jenkins wrote:
> >>> Alexey Starikovskiy wrote:
> >>>> Alan Jenkins wrote:
> >>>>> Alexey Starikovskiy wrote:
> >>>>>> Alan Jenkins wrote:
> >>>>>>> Well, that didn't work.
> >>>>>> Pity...
> >>>>>> Could you produce a debug log from EC?
> >>>>>> Probably it's a good time to open a new bug report...
> >>>>> <http://bugzilla.kernel.org/show_bug.cgi?id=11917>
> >>>>> "Asus Eee PC hotkeys stop working after prolonged usage"
> >>>>>
> >>>>> I stuck at it, found a reliable test and bisected successfully.
> >>>>> 2.6.28-rc2 is broken, but I can fix it by reverting the bad commit.
> >>>>> (There were some conflicts, I fixed up the dock driver manually and
> >>>>> avoided building the rest).
> >>>> Alan, to make things clear -- reverting following commit makes EC work
> >>>> without
> >>>> a problem?
> >>>>
> >>>
> >>> Yes, that's right.
> >> Great!
> >> What kernel version is that -- 32 or 64?
Thanks for the patch. 
   It seems that the code path in the function of ec_parse_device is
incorrect.
   Whether the ec->global_lock is assigned to a value should be based on
the returned value of acpi_evaluate_integer(handle, "_GLK", NULL, &tmp).
   If AE_OK is returned, the ec->global_lock is assigned to true.
Otherwise it should be False.
   Is this OK?
 
Thanks.

  
> > 
> > 32 bit, my EeePC doesn't do 64.
> is the attached patch enough to fix ?
>