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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
