From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Alexey Starikovskiy <alexey_y_starikovskiy@linux.intel.com>
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, 6 Sep 2006 21:00:38 +0200 [thread overview]
Message-ID: <200609062100.39166.rjw@sisk.pl> (raw)
In-Reply-To: <44FEE0F5.9090404@linux.intel.com>
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
next prev parent reply other threads:[~2006-09-06 18:57 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
2006-09-06 19:00 ` Rafael J. Wysocki [this message]
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=200609062100.39166.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=alexey_y_starikovskiy@linux.intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=luming.yu@intel.com \
--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