RE: kacpi_notify?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux