Prev: cpuset: fix the problem that cpuset_mem_spread_node() returns an offline node(was: Re: [regression] cpuset,mm: update tasks' mems_allowed in time (58568d2))
Next: restrict initial stack space expansion to rlimit - the process killer...
From: Alan Jenkins on 4 Mar 2010 04:40
On 3/4/10, Len Brown <lenb(a)kernel.org> wrote:
> Isn't the problem at hand that the boot-kernel stops
> in mid-transaction, and the resumed hibernate image
> then blunders forward with its first transaction
> only to find the EC in an intermediate state?
>
> If yes, I then making the transaction atomic WRT
> the boot kernel stopping should fix the problem.
>
> The patch sets a FROZEN bit, and subsequent
> requests for EC transactions simply fail.
> How do we know that we set the bit at the right time?
> What transactions or parts of transactions will fail,
> and what are the consequences of those failures?

The problem transactions on my machine were probably started by
ec_check_sci(). I.e. QUERY transactions which read the value of an
event raised by the EC. (I triggered the problem by pressing ACPI
hotkeys, although I haven't been able to reproduce it since).

That might explain why the transactions can be asynchronous with the
s2disk task - because these transactions are run in the ACPI
workqueue. Perhaps the workqueue needs to be flushed after the EC GPE
is disabled?

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: cpuset: fix the problem that cpuset_mem_spread_node() returns an offline node(was: Re: [regression] cpuset,mm: update tasks' mems_allowed in time (58568d2))
Next: restrict initial stack space expansion to rlimit - the process killer...