Re: Possible bug in ACPI

[Andrew Morton <akpm@osdl.org>]

On Sun, 03 Dec 2006 12:30:52 +0300
Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com> wrote:

> 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...

I didn't receive it.

> >   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?

It all sounds horridly hacky, but I don't understand the problem well
enough to be able to recommend any solutions.  That's why I was hoping for
a decent description of the patch.

How does it relate to this? http://lkml.org/lkml/2006/8/8/336

> > 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.
> >   

I'll take that as an "OK" ;)