GPE handler livelock

[John Baldwin]

On Saturday 05 January 2008 07:47:12 pm Nate Lawson wrote:
> John Baldwin wrote:
> > np.  Btw, on another note, I've finally tracked down the weird hangs my 
laptop 
> > has on updated HEAD to something in the GPE handling related to updates to 
> > ACPI in the past year.  I'm still digging, but you can look at 
> > www.freebsd.org/~jhb/gpe/ and use the modified schedgraph.py there on the 
> > ktr5.out to see what happens when my laptop stops running userland 
processes.  
> > It appears to be spending all its time running a GPE handler for a thermal 
> > event.
> 
> Thanks for digging into this.  I reviewed this and am trying to figure
> out why the _L00 handler never completes.  It keeps getting preempted by
> the next one.  To help track this down, try removing these two lines
> from the _L00 method and recompile your ASL:
> 
>     Acquire (\_TZ.C173, 0xFFFF)
>     ...
>     Release (\_TZ.C173)
> 
> For others who have this problem, instructions on how to recompile and
> load your custom ASL can be found here (11.16.4 and 5):
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html

Err, taskqueue threads run tasks synchronously, it's just running repeatedly, 
almost as if the GPE never turns off once it is asserted.  If you grab 
ktr6.out and the latest schedgraph.py it adds extra handling for tracking 
ACPI mutexes.  It gives each Mutex its own line in the display showing when 
it is held, contested, or idle.  The mutexes are never contested, so I don't 
think that is the issue.  When I get some more time I'm going to instrument 
the GPE enabling/disabling stuff.

-- 
John Baldwin