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 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
