Skip site navigation (1)Skip section navigation (2)
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>