lkml.org 
[lkml]   [2008]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [2.6.28-rc2] EeePC ACPI errors & exceptions
Not a problem, just find the root cause. Or shut up.


Zhao Yakui wrote:
> On Tue, 2008-10-28 at 13:46 -0700, Alexey Starikovskiy wrote:
>
>> Hi Darren,
>>
>> Please check if the patch
>> http://marc.info/?l=linux-acpi&m=122516784917952&w=4
>> helps.
>>
> In the attached patch the msleep is replaced by udelay gain.
> In the following commit the udelay is replaced by msleep.
> >commit 1b7fc5aae8867046f8d3d45808309d5b7f2e036a
> >Author: Alexey Starikovskiy <astarikovskiy@suse.de>
> >Date: Fri Jun 6 11:49:33 2008 -0400
> >ACPI: EC: Use msleep instead of udelay while waiting for event
>
> After the problem happens again, the udelay is restored again before
> getting the root cause.
> Maybe we should find the root cause of the problem and change the
> working flowchart about the EC driver. It is inappropriate that we make
> some changes and it is reverted again when the problem happens.
>
> At the same time after mlseep is replaced by the udelay, the CPU will
> do thing but loop while doing EC transaction on some laptops (In the
> function of ec_poll). If 100 EC transactions are done, the CPU will do
> nothing but loop at least for 100*2*100 microseconds. In such case maybe
> the performance will be affected.
>
> After the following commit is merged, the EC transaction will be
> executed in EC GPE interrupt context on most laptops.Maybe it is easier.
> But for the some laptops it can't be done in EC GPE interrupt context.
> So it falls back to the EC polling mode. (This is realized by the
> function of ec_poll).
> >commit 7c6db4e050601f359081fde418ca6dc4fc2d0011
> >Author: Alexey Starikovskiy <astarikovskiy@suse.de>
> >Date: Thu Sep 25 21:00:31 2008 +0400
> >ACPI: EC: do transaction from interrupt context
>
> Why is AE_TIME sometimes returned by the function of ec_poll?
>
>> static int ec_poll(struct acpi_ec *ec)
>>
> {
> unsigned long delay = jiffies + msecs_to_jiffies(ACPI_EC_DELAY);
> msleep(1);
> // Maybe the current jiffies is already after the predefined jiffies
> after msleep(1). In such case the ETIME will be returned. Of course the
> EC transaction can't be finished. If so, IMO this is not reasonable as
> this is caused by that OS has no opportunity to issue the following EC
> command sequence.
> while (time_before(jiffies, delay)) {
> gpe_transaction(ec, acpi_ec_read_status(ec));
> msleep(1);
> if (ec_transaction_done(ec))
> return 0;
> //Maybe there exists the following cases. EC transaction is not finished
> after msleep(1),but the current jiffies is already after predefined
> jiffies. So ETIME is returned. In such case, IMO this is also not
> reasonable.
> }
> return -ETIME;
> }
> At the same time msleep is realized by schedule_timeout. On linux
> although one process is waked up by some events, it won't be scheduled
> immediately. So maybe the current jiffies is already after the
> predefined timeout jiffies after msleep(1).
> Although the possibility of this issue can be reduced by that msleep
> is replaced by udelay,maybe the issue still exists if the preempt
> schedule happens at the corresponding place.
>
> In the above case the ETIME will be returned by ec_poll. But the
> reason is not that EC controller can't update its status in time.
> Instead it is caused by that host has no opportunity to issue the
> sequence operation in the current work flowchart. In current EC work
> flowchart the EC transaction is done in a big loop.
>
> Maybe the better solution is that the EC transaction is explicitly
> divided into several different phases.
>
> Maybe my analysis is not correct. If so, please correct me.
> Welcome the comments.
>
> thanks.
>
>
>
>
>> Thanks,
>> Alex.
>>
>>
>>
>
>



\
 
 \ /
  Last update: 2008-10-29 10:33    [W:0.105 / U:1.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site