Re: patch for bugs 9998 and 10724

[Alexey Starikovskiy <astarikovskiy@suse.de>]

Zhao Yakui wrote:
> On Tue, 2008-09-09 at 13:36 +0400, Alexey Starikovskiy wrote:
>> Zhao Yakui wrote:
>>> On Tue, 2008-09-09 at 13:12 +0400, Alexey Starikovskiy wrote:
>>>> Zhao Yakui wrote:
>>>>> Hi, Alexey
>>>>>     You attached the updated patch on the bug 10724/9998.
>>>>>     Can the following situation be handled by your patch?(For example:
>>>>> bug 10724)
>>>>>        EC GPE Interrupt storm is detected and EC GPE will be disabled
>>>>> when doing EC transaction.
>>>>>        If EC notification event happens while doing EC transaction(EC
>>>>> GPE is disabled), the SCI_EVT bit of EC status register is cleared
>>>>> automatically before we can handle it.
>>>> SCI_EVT is cleared only as a response to query command sent to EC, there is no 
>>>> timeout on it.
>>> If the SCI_EVT is cleared only after issuing query the command, in
>>> theory the poll timer should also handle it. But on the laptop of bug
>>> 10724 it seems that the poll timer can't handle such notification event.
>>> And on the laptops of bug 11428 and 8459 the poll timer can't handle the
>>> notification event when the system is switched from GPE mode to polling
>>> mode.
> What we cared only is whether the EC notification event can be detected
> by OS when the following case happens? (For example: On the laptop of
> bug 10724)
>     EC GPE Interrupt storm is detected and EC GPE will be disabled when
> doing EC transaction.
>     If EC notification event happens while doing EC transaction(EC GPE
> is disabled), the SCI_EVT bit of EC status register is cleared before we
> can handle it.
In such case, event is lost. 
>     
>> The problem here is with auto-repeat of function keys, thus the need to _distinguish_
>> one event from another (SCI bit will be set, just the event will be either different 
>> or next of the same kind). Poll timer does it's job every 500ms, thus auto-repeated keys are
>> lost. With the fastest auto-repeat being 30/s or 33ms we have plenty of time.
>>>> Transaction will take at most 2 ms (1 write/1 read or 2 writes in poll mode), 
>>>> and at the end of the transaction there is a check of the SCI bit.
>>>> With the un-patched EC SCI bit needs to stay for period while the QUERY_PENDING bit is set,
>>>> which could be quite more than 2 ms, and it seems to comply with that even on most broken
>>>> hardware.
>>>>>        Can the EC notification event be handled by OS?
>>> Maybe it will take very short time to do the EC transaction. Myabe in
>>> most cases it is about 2ms. But in some worse situation it will take a
>>> long time(For example: 100ms). If the EC notification happens in such
>>> case, how to handle the event? (the SCI_EVT bit will be cleared before
>>> we can detect it).
>> Where do you get this 100ms number? 
> As I state in the previous email, the msleep is realized by the function
> of schedule_timeout. The input parameter of msleep will be translated to
> jiffies unit. In such case the time of EC transaction will be related
> with the definition of HZ.(If the HZ is 100, msleep(1) will cost
> 10ms).At the same time when one process is waked up, maybe it won't be
> scheduled immediately. If so, the time of EC transaction will be
> longer.Maybe in some worse case the time will exceed 500ms.
>     The detailed info log can be found in 
>      http://bugzilla.kernel.org/show_bug.cgi?id=11141
> 
> 
Ok.