Date: Sat, 21 Aug 2010 13:21:29 +0300 From: Andriy Gapon <avg@icyb.net.ua> To: Doug Barton <dougb@FreeBSD.org> Cc: Alexander Motin <mav@FreeBSD.org>, freebsd-current@FreeBSD.org Subject: Re: Latest intr problems Message-ID: <4C6FA8A9.3040606@icyb.net.ua> In-Reply-To: <4C6F9DD4.3050205@icyb.net.ua> References: <alpine.BSF.2.00.1008201701001.19740@qbhto.arg> <4C6F772A.5020703@icyb.net.ua> <4C6F7BD1.4030009@icyb.net.ua> <alpine.BSF.2.00.1008210028530.1718@qbhto.arg> <4C6F9DD4.3050205@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
on 21/08/2010 12:35 Andriy Gapon said the following: > I feel like you might be having a problem with clocks... FWIW, I am reading this document http://edc.intel.com/Link.aspx?id=1484 and I see this sentence: "All of the clocks in the processor core are stopped in the C3 state". I see that you have C3 state enabled and it's regularly entered: dev.cpu.0.cx_usage: 0.00% 5.51% 94.48% last 305us Also I see that LAPIC timer is used as timer1 (hardclock) on your system: kern.eventtimer.timer1: LAPIC I believe that this might be the explanation of what you see, but I am not sure. One indication that this might be the case is high degree of aliasing between hardclock and statclock interrupts as per my interpretation of the dtrace information. You can test by either avoiding C3 state (via cx_lowest) or configuring some other timer as kern.eventtimer.timer1 P.S. I think that timer selection code and/or Cx configuration code could/should be smarter about things like that. After all ET_FLAGS_C3STOP is set for your LAPIC timer. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C6FA8A9.3040606>