On Thu, Mar 27, 2014 at 6:26 AM, Stefan Biereigel <stefan@xxxxxxxxxxxx> wrote:
> I tested both of your patches. The processing of events works well on my
> N150, the lid is reported open correctly after resume.
> For the second patch (the whitelisting-approach), I had to change the
> Product Name to "N150/N210/N220" instead of "N150P", because that is
> what dmidecode reports for my netbook.
That was quick - thanks for testing!
For the product name match then, it matches substrings not whole
strings, so "N150" should be sufficient (my mistake putting P on the
end).
> So, all three approaches work equally well for me (whitelisting my
> broken N150, blacklisting the broken Series 5/7/9, processing all the
> stale events). I personally would prefer a solution which needs to
> handle (best case) no custom cases, because there are always n+1 of
> them. But, as I don't know if there may be any problems with the
> approach that needs no special handling (processing all stale events) in
> the future, I'm not the one to decide the correct solution.
I won't be able to test ec_clear_process patch until tomorrow because
I have a full day today.
On my machine, _QXX events are all something like:
if (AC_PLUGGED_IN) {
do_something();
}
So if (for example) AC_PLUGGED_IN has changed since the event was
produced (e.g. no longer plugged in), nothing bad should happen.
That's not necessarily a guarantee that this wouldn't introduce new
bugs on other machines though.
I think the ideal fix would be to distinguish between events which are
"jammed" and won't be processed (like on Series 5/7/9), and events
which will be processed normally with GPEs (N150). I am not sure how
to do this or if it's even possible.
For example, on my machine, the EC status byte (EC_SC) seems to be
0x29 for jammed events, which means the SCI_EVT bit is set but we
never got/get the interrupt. On your N150, your status byte was 0x09
which means the SCI_EVT was not set - it was not yet asking for the OS
to attend to this.
I wonder if something as simple as this would work (in acpi_ec_clear):
if (!(acpi_ec_read_status(ec) & ACPI_EC_FLAG_SCI))
break;
status = acpi_ec_query_unlocked(ec, &value);
if (status || !value)
break;
This would make it only clear events while the SCI_EVT bit is set. I
am not sure that it would entirely remove the race condition you are
seeing, but it might be enough to fix it.
If we cant come up with a generally applicable solution, whitelisting
is the lesser of two evils when compared with blacklisting here. A
jammed EC won't function _at all_, while losing one or two EC events
on boot/resume doesn't prevent future events and is easier to work
around (though still not ideal).
Regards,
Kieran.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
