From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 10:21:33 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF7D9106566B; Sat, 21 Aug 2010 10:21:33 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6794C8FC08; Sat, 21 Aug 2010 10:21:32 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA14094; Sat, 21 Aug 2010 13:21:30 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OmlCc-0006F2-LD; Sat, 21 Aug 2010 13:21:30 +0300 Message-ID: <4C6FA8A9.3040606@icyb.net.ua> Date: Sat, 21 Aug 2010 13:21:29 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Doug Barton References: <4C6F772A.5020703@icyb.net.ua> <4C6F7BD1.4030009@icyb.net.ua> <4C6F9DD4.3050205@icyb.net.ua> In-Reply-To: <4C6F9DD4.3050205@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-current@FreeBSD.org Subject: Re: Latest intr problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 10:21:33 -0000 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