Re: Possible bug in ACPI

[Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>]

Andrew Morton wrote:
> On Sun, 03 Dec 2006 12:06:54 +0300
> Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com> wrote:
>
>   
>> This is a patch reverted by Linus from rc6-git2 because it broke his 
>> Compaq n620c, it refers to #5534 bug. Basically, kacpid deadlocks on 
>> some new HP notebooks, and all incoming requests would be queued until 
>> memory is over if this patch is not applied. On a bright side -- it's 
>> not a memory leak...
>> Patch, which works for Linus laptop and "looks acceptable" to Linus is 
>> the last in #5534 list.
>>     
>
> hm, if you say so.
I forwarded Linus' mail to you...
>   The description in that patch is nowhere near complete
> enough for me to be able to work out what it does.
>
>   
Will update.

> The sys_sched_yield() is particularly incomprehensible and needs good
> commenting.  You are, I hope, aware of the severe problems which yield()
> causes when the system is busy?  The process which calls it will get
> practically no CPU at all.
>
>   
On Linus' machine, as soon as we execute deferred work, it's GPE becomes 
enabled again and BIOS sends us a new event.
So kacpid is always ready to run, while kacpi_notify don't have a chance 
to run. sys_sched_yield() was added to
give kacpi_notify a chance to run.
I was thinking about lowering the priority of kacpid, is it better?
> Minor point: that patch has several unneded (and undesirable) casts of void*:
>
> +static void acpi_os_execute_notify(void *context)
> +{
> +	struct acpi_os_dpc *dpc = (struct acpi_os_dpc *)context;
> 	
> please remove those.
>