EeePC 901, BIOS revision 1603, current Debian lenny; running on AC.
I've noticed the following errors & exceptions, apparently coinciding with
the startup of xfce4-sensors-plugin:
ACPI: EC: missing confirmations, switch off interrupt mode.
ACPI Exception (evregion-0419): AE_TIME, Returned by Handler for [EmbeddedControl] [20080926]
ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.SBRG.EC0_.BST2] (Node f7030d38), AE_TIME
ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.CBST] (Node f70336f8), AE_TIME
ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.BAT0._BST] (Node f7031c48), AE_TIME
ACPI Exception (battery-0360): AE_TIME, Evaluating _BST [20080926]
Also, this (which, unlike the above, is also present with 2.6.27.*):
ACPI: I/O resource 0000:00:1f.3 [0x400-0x41f] conflicts with ACPI region SMRG [0x400-0x40f]
ACPI: Device needs an ACPI driver
Full dmesg & config are attached.
(The Elantech touchpad patch from http://arjan.opmeer.net/elantech/ is
applied to this kernel.)
--
| Darren Salt | linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| <URL:http://www.youmustbejoking.demon.co.uk/progs.packages.html>
Thou shalt not sleep within an interrupt handler.
On Mon, 2008-10-27 at 15:52 -0700, Darren Salt wrote:
Will you please attach the output of acpidump?
Of course you can file a bug report at
http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
and attach the output of acpidump, dmesg.
It will be better if you can add the boot option of "printk.time=1".
thanks.
> EeePC 901, BIOS revision 1603, current Debian lenny; running on AC.
>
> I've noticed the following errors & exceptions, apparently coinciding with
> the startup of xfce4-sensors-plugin:
>
> ACPI: EC: missing confirmations, switch off interrupt mode.
> ACPI Exception (evregion-0419): AE_TIME, Returned by Handler for [EmbeddedControl] [20080926]
> ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.SBRG.EC0_.BST2] (Node f7030d38), AE_TIME
> ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.CBST] (Node f70336f8), AE_TIME
> ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.BAT0._BST] (Node f7031c48), AE_TIME
> ACPI Exception (battery-0360): AE_TIME, Evaluating _BST [20080926]
>
> Also, this (which, unlike the above, is also present with 2.6.27.*):
>
> ACPI: I/O resource 0000:00:1f.3 [0x400-0x41f] conflicts with ACPI region SMRG [0x400-0x40f]
> ACPI: Device needs an ACPI driver
>
> Full dmesg & config are attached.
>
> (The Elantech touchpad patch from http://arjan.opmeer.net/elantech/ is
> applied to this kernel.)
>
On Mon, 2008-10-27 at 15:52 -0700, Darren Salt wrote:
> EeePC 901, BIOS revision 1603, current Debian lenny; running on AC.
>
> I've noticed the following errors & exceptions, apparently coinciding with
> the startup of xfce4-sensors-plugin:
Will you please confirm whether the same issue exists on the previous
kernel? For example: 2.6.27 or 2.6.27-rc6
After the following commit is merged, it seems that on the EEEPC laptop
the EC will switch off EC GPE interrupt mode when there is no EC GPE
interrupt confirm for some EC transactions. Then AE_TIME is returned by
the function of ec_poll, which causes that the _BST object of battery
can't be evaluated.
>commit 7c6db4e050601f359081fde418ca6dc4fc2d0011
>Author: Alexey Starikovskiy <[email protected]>
>Date: Thu Sep 25 21:00:31 2008 +0400
>ACPI: EC: do transaction from interrupt context
When there is no EC GPE interrupt confirm in some EC transaction, the
EC will switch off the EC GPE interrupt mode in the function of
acpi_ec_wait.
But why is AE_TIME 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).
Now some people suggest that msleep is replaced by udelay. Although
the above two cases can be avoided by that msleep is replaced by udelay,
maybe the above two cases still exist if the preempt schedule happens at
the corresponding place.
At the same time when msleep is replaced by udelay, CPU will do
nothing but loop while executing udelay. If the 100 EC transactions are
done in one second, the CPU will do nothing in about 100*2*100
microseconds. IMO this is not reasonable.
IMO the better solution is that the EC transaction is divided into
the different phases. (Not do the EC transaction in one loop).
For example:
The EC read transaction can be done in the following sequence:
a. Issue read command
b. wait until the EC input buffer is empty and then write the EC
internal read address
c. wait until the EC output buffer is ready and read the data from
EC the Data port. Of course it indicates that EC read transaction is
finished.
The EC write transaction can be done in the following sequence:
a. issue the write command
b. wait until the EC input buffer is empty and write the EC internal
write address
c. wait until the EC input buffer is empty and write the data to the
EC Data port
d. wait until the EC input buffer is empty. After it becomes empty,
it indicates that the EC write transaction is finished.
Welcome the comments.
Thanks.
> ACPI: EC: missing confirmations, switch off interrupt mode.
> ACPI Exception (evregion-0419): AE_TIME, Returned by Handler for [EmbeddedControl] [20080926]
> ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.SBRG.EC0_.BST2] (Node f7030d38), AE_TIME
> ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.CBST] (Node f70336f8), AE_TIME
> ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.BAT0._BST] (Node f7031c48), AE_TIME
> ACPI Exception (battery-0360): AE_TIME, Evaluating _BST [20080926]
>
> Also, this (which, unlike the above, is also present with 2.6.27.*):
>
> ACPI: I/O resource 0000:00:1f.3 [0x400-0x41f] conflicts with ACPI region SMRG [0x400-0x40f]
> ACPI: Device needs an ACPI driver
>
> Full dmesg & config are attached.
>
> (The Elantech touchpad patch from http://arjan.opmeer.net/elantech/ is
> applied to this kernel.)
>
On Mon, 2008-10-27 at 15:52 -0700, Darren Salt wrote:
> EeePC 901, BIOS revision 1603, current Debian lenny; running on AC.
>
> I've noticed the following errors & exceptions, apparently coinciding with
> the startup of xfce4-sensors-plugin:
>
> ACPI: EC: missing confirmations, switch off interrupt mode.
> ACPI Exception (evregion-0419): AE_TIME, Returned by Handler for [EmbeddedControl] [20080926]
> ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.SBRG.EC0_.BST2] (Node f7030d38), AE_TIME
> ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.CBST] (Node f70336f8), AE_TIME
> ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.BAT0._BST] (Node f7031c48), AE_TIME
> ACPI Exception (battery-0360): AE_TIME, Evaluating _BST [20080926]
Will you please try the attached patch on the 2.6.28-rc2 and see whether
the issue still exists?
After the test, please attach the output of dmesg.
The following is included by the attached patch.
a. EC transaction is divided into several phases.
For example: EC write transaction
a. issue EC write command
b. wait until the input is empty and then write the internal
address
c. wait until the input is empty and write the data
d. wait until the input is empty. If it is empty, it indicates
that EC transaction is finished.
At the same time EC driver will be started in EC GEP mode. And when
there is no EC GPE confirmation for some EC transaction on some broken
laptops,the EC driver will be switched to polling mode. But EC GPE is
still enabled.
b. Some delay is added in the EC GPE handler on some broken BIOS.
The delay won't be added for most laptops.Only when more than five
interrupts happen in the same jiffies and EC status are the same, OS
will add some delay in the EC GPE handler. If the same issue still
happens after adding delay,the delay time will be increased.But the max
delay time is ten microseconds.
Thanks.
>
> Also, this (which, unlike the above, is also present with 2.6.27.*):
>
> ACPI: I/O resource 0000:00:1f.3 [0x400-0x41f] conflicts with ACPI region SMRG [0x400-0x40f]
> ACPI: Device needs an ACPI driver
>
> Full dmesg & config are attached.
>
> (The Elantech touchpad patch from http://arjan.opmeer.net/elantech/ is
> applied to this kernel.)
>
I demand that Zhao Yakui may or may not have written...
> On Mon, 2008-10-27 at 15:52 -0700, Darren Salt wrote:
>> EeePC 901, BIOS revision 1603, current Debian lenny; running on AC.
>> I've noticed the following errors & exceptions, apparently coinciding with
>> the startup of xfce4-sensors-plugin:
>> ACPI: EC: missing confirmations, switch off interrupt mode.
>> ACPI Exception (evregion-0419): AE_TIME, Returned by Handler for [EmbeddedControl] [20080926]
>> ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.SBRG.EC0_.BST2] (Node f7030d38), AE_TIME
>> ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.CBST] (Node f70336f8), AE_TIME
>> ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.BAT0._BST] (Node f7031c48), AE_TIME
>> ACPI Exception (battery-0360): AE_TIME, Evaluating _BST [20080926]
> Will you please try the attached patch on the 2.6.28-rc2 and see whether
> the issue still exists?
> After the test, please attach the output of dmesg.
I later noticed that ACPI functions (lid, hot keys etc.) were effectively
disabled by that bug – acpi_listen reported nothing at all.
With the patch, those ACPI errors are gone and the ACPI functions work again.
I see no other significant differences, but output is attached regardless
along with an ACPI dump. (rt2860sta is also present.)
(This leaves only the I/O resource conflict; but, unlike this, that's also
present in 2.6.27, doesn't seem to cause any harm, and looks like it's
specific to BIOS rev. 1603 and possibly others > 1301.)
[snip]
--
| Darren Salt | linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Use more efficient products. Use less. BE MORE ENERGY EFFICIENT.
I have 240 airconditioning in my car; 2 windows down at 40mph.
Hi Darren,
Please check if the patch
http://marc.info/?l=linux-acpi&m=122516784917952&w=4
helps.
Thanks,
Alex.
I demand that Alexey Starikovskiy may or may not have written...
> Please check if the patch
> http://marc.info/?l=linux-acpi&m=122516784917952&w=4
> helps.
With the other patch, this makes no difference.
With only your patch, ACPI EC is started in poll mode; later, several
"non-query interrupt received" messages are logged, followed by a "missing
confirmations" message; none of which I see with the other patch. Otherwise,
all seems well.
dmesg attached for the latter case.
--
| Darren Salt | linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Lobby friends, family, business, government. WE'RE KILLING THE PLANET.
You will lose an important file.
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 <[email protected]>
>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 <[email protected]>
>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.
>
>
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 <[email protected]>
> >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 <[email protected]>
> >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.
>>
>>
>>
>
>
On Wed, 2008-10-29 at 17:29 +0800, Alexey Starikovskiy wrote:
> Not a problem, just find the root cause. Or shut up.
Maybe you don't read the explanation I have written.
>
> 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 <[email protected]>
> > >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 <[email protected]>
> > >Date: Thu Sep 25 21:00:31 2008 +0400
> > >ACPI: EC: do transaction from interrupt context
> >
The following is the detailed explanation why this issue happens. In
fact after you sent your patch, I raise the issue about it. But it is
ignored. (Maybe the AE_TIME will be returned by EC driver. But the
reason is not caused by that EC controller can't update its status in
time. Instead it is caused by that host has no opportunity to issue the
sequence EC command.)
>
> > 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.
> >>
> >>
> >>
> >
> >
>
Zhao Yakui wrote:
> On Wed, 2008-10-29 at 17:29 +0800, Alexey Starikovskiy wrote:
>
>> Not a problem, just find the root cause. Or shut up.
>>
> Maybe you don't read the explanation I have written.
>
Found root cause should not have "maybe" before it.