Latest intr problems

[b. f.]

On 8/23/10, John Baldwin <jhb at freebsd.org> wrote:
> On Saturday, August 21, 2010 11:28:41 am Andriy Gapon wrote:
>> on 21/08/2010 16:04 b. f. said the following:
>> > Andriy Gapon wrote:
>> >> 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
>> >
>> > I don't think this accounts for all of his problems, unless his
>> > machine has an unusual configuration.
>>
>> Well, let's try to not muddy the waters prematurely.
>
> It could easily account for it.  If the lapic is going to sleep in C3, then
> you are actually missing statclock interrupts and likely screwing up the
> accounting (idle threads wouldn't accumulate "time" correctly for example).
> Even though his system really isn't spending a lot of time executing
> interrupts, the cp_time[] values would be skewed and wrong.

Right, I can easily see how it is _a_ problem.  I remembered that it
was the reason Alexander gave for reviving the use of the rtc and the
i8254 as eventtimers/timecounters, and it's partly why I suggested
switching clock sources earlier.   My point in my reply to Andriy was
that Doug had reported similar problems  when the hpet was the sole
eventtimer/timecounter, and also when the i8254 was the only one,
which suggested that there were other problems, too.  But then Doug
also assured me that he was satisfied that usb wasn't the source of
the problem, where now he and Andriy seem to think it plays a primary
role, so I give up.  I only hope that new interrupt-handling that you
are working on makes the system less susceptible to these kinds of
problems.

b.