Re: 2.6.18-rc5 -rc5-mm1: kacpid continuously generating 4% CPU load on HPC nx6325 w/ SUSE 10.1

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Wednesday, 6 September 2006 21:00, Rafael J. Wysocki wrote:
> On Wednesday, 6 September 2006 16:53, Alexey Starikovskiy wrote:
> > There is an infinite loop in thermal GPE handler of these HP machines,
> > which could only be interrupted by thermal device poll. In this loop handler
> > sends Notify() to thermal zone, which, if executed, will cause the needed poll.
> > Problem is that this Notify() will be queued in the same kacpid workqueue,
> > which executes loop of the handler, so it has no chance to run -- we have a dead lock.
> > SUSE sets all thermal zones into polling mode, thus breaking the above
> > loop every 2-3 seconds or so (polling interval). At this moment all queued notifies
> > for thermal zone are free to run, and you see your 4% of cpu usage by kacpid.
> > There are several attempts to remove the above deadlock by either having a pool of threads (up to 10),
> > stealing work from single kacpid workqueue thread (Peters' patch), or executing notify()
> > events on separate kernel thread (my patch).
> > Peters' patch is already shipped in Ubuntu 6.06 kernel, mine was removed from -rc2 after
> > it broke Linus' Compaq n620c, which has slightly different loop in DSDT (global locks this time).
> > Peters' patch seems dangerous as it tampers with workqueue interface and solves the problem by brute force methods,
> > while mine had problem of possibly creating a classical fork DoS atack and creating threads during work of
> > suspend/resume -thus breaking it.
> > I just did one more attempt to solve this problem -- there is already patch to not defer execution of global lock
> > release (thus removing it from dead lock scenario of n620c), so the only dead lock could happen between execution of
> > Notify and whatever is on kacpid workqueue. Creation of second workqueue for notifies seems to solve problem with my
> > nx6125, while not breaking suspend and not creating threads dynamically.
> > 
> > Hope that explanation is usefull,
> 
> Sure it is, thanks a lot!
> 
> Could you please tell me where I can find your patch so I can test it here?

Ah, okay, I have found the (two) patches in Bug #5534.

They apparently fix the issue for me.

Thanks,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller