Latest intr problems

Andriy Gapon avg at icyb.net.ua
Sat Aug 21 15:28:46 UTC 2010


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.

> Alexander and I recommended
> that he try different clocks, and just recently, for example, he wrote
> that he had used:
> 
> loader.conf
> hint.apic.0.clock="0"
> hint.atrtc.0.clock="0"
> hint.attimer.0.clock="0"
> hint.hpet.0.legacy_route="1"

Well, I don't see much point in doing the above in this situation.

> machdep.disable_rtc_set="1"
> kern.eventtimer.timer2="HPET"
> kern.eventtimer.timer1="NONE" (Or, if available, HPET1, ...)

So, what was actually used here?
I don't think that NONE is a good idea.

> kern.eventtimer.singlemul="1"
> 
> sysctl.conf:
> kern.timecounter.hardware=HPET
> 
> and reported that it did not help.  The HPET doesn't usually suffer
> from the problem that you are describing, right?

Right.
Still I would prefer that Doug would do the cleaner experiment(s) that I
suggested.  And if the problem persists then elimination of LAPIC timer would
make the picture clearer (for me).

P.S.
I still think that KTR+schedgraph would be the best tool here.

-- 


More information about the freebsd-current mailing list