Date: Fri, 28 Dec 2007 18:48:04 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: acpi@freebsd.org, njl@freebsd.org Subject: Re: An issue with powerd.. Message-ID: <20071228164804.GU57756@deviant.kiev.zoral.com.ua> In-Reply-To: <200712271449.58285.jhb@freebsd.org> References: <200712271449.58285.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--WeyQLTZFbZxVv3E0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 27, 2007 at 02:49:57PM -0500, John Baldwin wrote: > So I've had some issues where I get weird hangs when I run with powerd en= abled=20 > on my laptop and I think I've finally tracked it down. Note that this is= on=20 > an older current with the older EC code, but the design flaw in powerd is= =20 > still relevant even if the new EC code makes my laptop happier (I'm tryin= g to=20 > update my laptop to more recent HEAD, but there's some weird scheduling b= ug=20 > that I haven't fixed yet in newer stuff). >=20 > Anyways, I was trying to debug the weird hangs I had when running with po= werd=20 > (machine would go unresponsive and fans would spin up, and after a variab= le=20 > number of seconds it would come back and all the pending input (mouse=20 > movements, keypresses, etc.) would be processed). I added some code to t= rack=20 > how long it takes for GPE's to run that would print out on the console if= one=20 > took more than 750ms as I had a feeling that something with ACPI was maki= ng=20 > the system busy. >=20 > It was also far worse in console mode than in X. In console mode I found= that=20 > sometimes the system would never "come back". >=20 > So I was running in console mode recently with my timing patches and noti= ced=20 > that when it hung it started warning about GPE events taking several=20 > _seconds_ to process, e.g. 2-3 seconds, or in some cases up to _30_ secon= ds. =20 > So, my theory is that powerd has lowered my CPU all the way down to 100mh= z=20 > (easy to reproduce in non-X, just let the box sit with no apps running) a= nd=20 > that for some reason the machine ends up in a "GPE storm" where it is=20 > spending all its time handling GPE's and never has any CPU left for userl= and=20 > apps (due to being at 100mhz). The problem then is that powerd never run= s to=20 > bump my CPU up to some reasonable speed. >=20 > In fact, anytime a completely idle box suddently gets a lot of kernel wor= k=20 > (e.g. a sudden flow of packets) it could in theory end up trying to handl= e=20 > all this work at the reduced speed since the work has a higher priority t= han=20 > the powerd process. To that end, I think that at least part of powerd ne= eds=20 > to be in the kernel, or at least that the kernel should be more proactive= =20 > about bumping the speed up when it resumes from Cx due to an interrupt. = A=20 > simple policy would be to bump up to full speed for any non-clock interru= pt=20 > (possibly bumping up for a clock interrupt if we wake up softclock as wel= l). >=20 > Thoughts? I have an issue that I believe is similar to what you described. In my case, running X (with a bunch of xterm and fvwm2) and powerd causes immediate hang when ath(4) interface is turned up and no AP is in air. When some AP is present, it takes much more time, but eventually the system still hung. Running powerd without X or X without powerd, or not running ath0 provides rock-solid machine. The laptop has no built-in com-port, neither it has a firewire. I would be glad to test the change. --WeyQLTZFbZxVv3E0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHdSjDC3+MBN1Mb4gRAk5DAJwMv+8HOop4LPj4/Dn+OJkLmavHPgCfZdfH mRixdXl+nyhqQhi2iONDgtE= =UbWg -----END PGP SIGNATURE----- --WeyQLTZFbZxVv3E0--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071228164804.GU57756>