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