On Thu, 13 Jul 2006, Starikovskiy, Alexey Y wrote:
>
> I'm terribly sorry that my patch broke on your machine.
> May I ask you to send me or attach to #5534 output of acpidump from this
> machine?
I'll send it in another email, since I already generated it for Len ;)
> Do you think that the whole idea is crap, or if I limit number of
> possible spawned threads and forsibly put current thread to sleep (which
> will release ACPICA executer mutex), as it happens in DSDT of nx6125 it
> will be possible to use it?
I don't think the _idea_ is crap per se, but it would at a minimum need a
thread limit. But I think it's the wrong approach: especially if you put
the current thread to sleep, you really don't want another thread at all,
you are really just working around a problem that is totally internal to
acpi (and the AML interpreter in particular).
So I think the problem really lies elsewhere, and that the whole thread
approach was trying to paper over it. And having a limited set of threads
is probably potentially _worse_ then what we have now.
Is there no way to have the AML interpreter have some state, and just push
that current interrupted state back onto the "event queue", and just start
executing the new one instead? That sounds like it should fix the _real_
problem - a kind of "mini-scheduler" for ACPI events?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
