GPE handler livelock

John Baldwin jhb at freebsd.org
Thu Jan 10 07:45:14 PST 2008


On Monday 07 January 2008 06:47:48 pm Nate Lawson wrote:
> This makes sense.  For the _L00 method in question, it runs 2 notifies
> before it completes.  So in our queue, that would be:
> 
> T1: GPE:_L00
>     [_LOO method runs, GPE removed]
>     [_L00 queues 2 more Notifies]
> T2: Notify, Notify
>     [_L00 completes]
> 
> Right now, there is nothing in our code to synchronize _L00's completion
> with completion of the Notifys.  In fact, _L00 finishes before the
> Notifys run.  Also, if another GPE comes in while this GPE is running,
> it will be queued in front of the Notifys and so would execute first.
> 
> So I think with just your evgpe.c change, we will defer re-enabling the
> GPE until after the queued Notifys complete since the re-enable task
> will be queued at the same priority.
> 
> The only remaining concern I have is if another GPE comes in before one
> or both Notifys run, it will be inserted at the head of the queue.  So
> as a hack, I'm setting the priority of these to be equal.
> 
> Yousif, please try the attached patch and don't load a custom ASL.

This patch appears to work for me in my testing.  I think this might also
explain the weird hangs I reported seeing when running on battery with
powerd on older kernels, but I haven't tested that case yet.

-- 
John Baldwin


More information about the freebsd-acpi mailing list