GPE handler livelock

[John Baldwin]

On Thursday 10 January 2008 10:15:29 am John Baldwin wrote:
> 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.

Update to note that it did not fix the issue I have with powerd.  However
debug.cpufreq.lowest does seem to help my issues with powerd.

-- 
John Baldwin