Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Aug 2010 00:55:41 -0700
From:      Doug Barton <dougb@FreeBSD.org>
To:        Andriy Gapon <avg@icyb.net.ua>
Cc:        freebsd-current@FreeBSD.org
Subject:   Re: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related
Message-ID:  <4C72297D.90104@FreeBSD.org>
In-Reply-To: <4C722209.1020405@icyb.net.ua>
References:  <4C71E858.90009@FreeBSD.org> <4C721334.1050000@icyb.net.ua> <4C7219B2.4070303@FreeBSD.org> <4C722209.1020405@icyb.net.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On 8/23/2010 12:23 AM, Andriy Gapon wrote:
> on 23/08/2010 09:48 Doug Barton said the following:
>> On 08/22/2010 23:20, Andriy Gapon wrote:
>>> on 23/08/2010 06:17 Doug Barton said the following:
>>>
>>>> http://people.freebsd.org/~dougb/intr-out-3.txt
>>>
>>> So, hm, npviewer.bin eats all the CPU time?
>>
>> No, the odd bits of that one are the fact that the intr threads irq17, irq256,
>> and irq20; are showing up at all, and/or showing up with more than a fraction of
>> a percent of cpu time.
>
> DTrace output doesn't show anything abnormal for those, but it does show that
> those interrupts do happen and those drivers do work.
> E.g. there is hdac (sound) activity [irq256: hdac0] and wireless activity
> [irq17: wpi0]. irq20 is hpet + usb.
>
> So did you do anything wireless?  Did you play sound?

Yes. My laptop is using wireless exclusively, and the streaming/flash 
video was attempting to play sound, but given that it was starved for 
resources the video and the audio were both very choppy.

> The %WCPU may be _reported_ higher than what it actually is due to other issues
> with your system (high load by npviewer.bin, HPET+USB interrupt sharing, C3 with
> LAPIC timer).
>
>> Usually they don't, and the fact that they did at that
>> point in time was indicative of the fact that the "runaway intr" problem was
>> happening. _Incidentally_ npviewer.bin was taking up more cpu than it usually
>> does, but I think that's another symptom of the underlying problem.
>
> In complex systems it's not always trivially obvious what's incidental and
> what's not.

Yep, sorry, no reason for you to have read my mind there. :)

> Well, I just interpreted the DTrace output you gave.

Right-o. I am about 80% ready to take the old HD out and put the new one 
in and start installing, at which point I'm going to set up the 
schedgraph stuff which will hopefully give more useful information.

Meanwhile, with the combination of ULE, no powerd, and cx_lowest=C1 I 
was able to watch 2 movies streaming over flash, plus do backups to 
various USB drives, read mail, etc. etc. for several hours; all without 
a hiccup. So clearly (in my mind at least) there is a problem with 
powerd, at least in the situation like mine where there is IRQ 
contention for HPET. I forgot to mention that in my previous testing 
today I tried running just powerd (not changing cx_lowest) and I when 
intr started running away I could "solve" the problem by killing powerd. 
The intr process went back to normal, and I could go back to doing what 
I was doing without having to reboot again.


anyways thanks again,


Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C72297D.90104>