Here's what I came up with -
1. I was fighting against EC_FLAGS_QUERY_PENDING. This was used to ignore
multiple successive GPE interrupts and treat them as a single GPE instead.
That's the exact opposite of what we want to do. Let's get rid of it.
2. Then we can apply my original patch to fix GPE polling on the Asus EeePC,
by repeatedly querying for GPEs until there are none left.
3. Finally, if I'm right then we now know how to handle "GPE interrupt storms".
Some EC's are raising multiple interrupts before we acknowledge them. but
they're just telling us how many events are pending. There's no harm in
that, so we don't ever need to disable GPE interrupts. Let's get rid of
GPE polling mode. (Code mainly stolen from Alexey).
Patch 3 would benefit from wider testing. Fortunately there are several open
bugs about GPEs so it should be easy to find testers :-).
Alan
--
| Andrew Morton | Re: Linux 2.6.21-rc4 |
| Andrew Morton | -mm merge plans for 2.6.23 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Balbir Singh | Re: [RFC][PATCH 2/7] RSS controller core |
git: | |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| David Miller | [GIT]: Networking |
| Andreas Henriksson | [PATCH 06/12] Remove bogus reference to tc-filters(8) from tc(8) manpage. |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
