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

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

[Rafael J. Wysocki]

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.

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.

Greetings,
Rafael


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

-- 
VGER BF report: U 0.5

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

[Yu Luming]

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.

>
>  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"?

-- 
Thanks,
Luming

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

[Rafael J. Wysocki]

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


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

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

[Alexey Starikovskiy]

Please try a patch from #5534 bug report, it seems you have the same deadlock as all other HP users.

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
> 
> 

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

[Rafael J. Wysocki]

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

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

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

[Rafael J. Wysocki]

On Tuesday, 5 September 2006 22:24, 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.

Apparently I was wrong.

I used the patch from Bug #5534 Comment #95 and it seems to have fixed the
kacpid issue.  Also, I'm now able to remove the ACPI modules.

Thanks a lot for the hint!

Greetings,
Rafael

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

[Alexey Starikovskiy]

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,
Regards,
	Alex.



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

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

[Rafael J. Wysocki]

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

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

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

[Rafael J. Wysocki]

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