public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Alexey Starikovskiy <alexey_y_starikovskiy@linux.intel.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Yu Luming <luming.yu@intel.com>,
	Linux ACPI <linux-acpi@vger.kernel.org>,
	Stefan Seyfried <seife@suse.de>
Subject: Re: 2.6.18-rc5 -rc5-mm1: kacpid continuously generating 4% CPU load on HPC nx6325 w/ SUSE 10.1
Date: Wed, 06 Sep 2006 18:53:41 +0400	[thread overview]
Message-ID: <44FEE0F5.9090404@linux.intel.com> (raw)
In-Reply-To: <200609052224.58749.rjw@sisk.pl>

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

  parent reply	other threads:[~2006-09-06 14:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-03  9:23 2.6.18-rc5 -rc5-mm1: kacpid continuously generating 4% CPU load on HPC nx6325 w/ SUSE 10.1 Rafael J. Wysocki
2006-09-05  6:47 ` Yu Luming
2006-09-05 11:13   ` Rafael J. Wysocki
2006-09-05 16:19     ` Alexey Starikovskiy
2006-09-05 20:24       ` Rafael J. Wysocki
2006-09-05 21:48         ` Rafael J. Wysocki
2006-09-06 14:53         ` Alexey Starikovskiy [this message]
2006-09-06 19:00           ` Rafael J. Wysocki
2006-09-06 21:03             ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44FEE0F5.9090404@linux.intel.com \
    --to=alexey_y_starikovskiy@linux.intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=luming.yu@intel.com \
    --cc=rjw@sisk.pl \
    --cc=seife@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox