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? Rafael > Rafael J. Wysocki wrote: > > On Tuesday, 5 September 2006 18:19, Alexey Starikovskiy wrote: > >> Please try a patch from #5534 bug report, it seems you have the same deadlock as all other HP users. > > > > Well, could you please tell me which comments are you referring to? > > > > The fans seem to work correctly on this box. > > > > Greetings, > > Rafael > > > > > >> Rafael J. Wysocki wrote: > >>> On Tuesday, 5 September 2006 08:47, Yu Luming wrote: > >>>> On Sunday 03 September 2006 17:23, Rafael J. Wysocki wrote: > >>>>> Hi, > >>>>> > >>>>> I'm having a strange issue with the 2.6.18-rc5 and -rc5-mm1 kernels and > >>>>> SUSE 10.1 on HPC nx6325 that kacpid is generating 4% of CPU load (on one > >>>>> core) in a continuous manner. > >>>> Please try to unload thermal module. > >>> albercik:~ # rmmod thermal > >>> > >>> [hanging? On another console:] > >>> albercik:~ # ps ax > >>> ... > >>> 4864 pts/0 D+ 0:00 rmmod thermal > >>> ... > >>> > >>>>> It sometimes helps if powersaved is restarted, but only for a short time. > >>>>> However, after restarting powersaved the kacpid-generated load sometimes > >>>>> jumps to 100% (on one core) and stays on this level. > >>>>> > >>>>> At the same time the battery is never reported to be 100% full (it stops > >>>>> at ~98% full and loading) and when I tried to unload the battery module, > >>>>> rmmod ended up in the D state. > >>>> what do you mean by "in the D state"? > >>> TASK_UNINTERRUPTIBLE (like above). > >>> > >>> Greetings, > >>> Rafael > >>> > >>> > >> - > >> 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 > >> > >> > > > - > 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 > > -- 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
