Date: Thu, 10 Jan 2008 10:15:29 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-acpi@freebsd.org Cc: Alexey Starikovskiy <astarikovskiy@suse.de>, "Moore, Robert" <robert.moore@intel.com> Subject: Re: GPE handler livelock Message-ID: <200801101015.29669.jhb@freebsd.org> In-Reply-To: <4782BA24.8030703@root.org> References: <200712311556.lBVFuVZf030567@freefall.freebsd.org> <4782A051.3050107@suse.de> <4782BA24.8030703@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801101015.29669.jhb>