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>