Clock stalls on Sabertooth 990FX

[Joe Schaefer]

On Mon, Aug 15, 2011 at 5:00 PM, Alexander Motin <mav at freebsd.org> wrote:
> On 15.08.2011 23:57, Joe Schaefer wrote:
>>
>> On Mon, Aug 15, 2011 at 4:35 PM, Alexander Motin<mav at freebsd.org>  wrote:
>>>
>>> On 15.08.2011 22:18, Joe Schaefer wrote:
>>>>
>>>> On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaefer<joesuf4 at gmail.com>
>>>>  wrote:
>>>>>
>>>>> On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapon<avg at freebsd.org>
>>>>>  wrote:
>>>>>>
>>>>>> on 13/08/2011 20:16 Joe Schaefer said the following:
>>>>>>>
>>>>>>> Brand new machine with a Phenom II X6 1100T and under chronic load
>>>>>>> the clock will stop running periodically until the machine eventually
>>>>>>> completely
>>>>>>> freezes.  Note: during these stalls the kernel is still running, the
>>>>>>> machine is still
>>>>>>> mostly responsive, it's just that the clock is frozen in time.
>>>>>>>
>>>>>>> I've disabled Turbo mode in the bios and toyed with just about every
>>>>>>> other setting but nothing seems to resolve this problem.  Based on
>>>>>>> the
>>>>>>> behavior
>>>>>>> of the machine (just making buildworld will eventually kill it,
>>>>>>> upping
>>>>>>> the -j flag
>>>>>>> just kills it faster), I'm guessing it has something to do with the
>>>>>>> Digi+ VRM features
>>>>>>> but again nothing I've tried modifying in the bios seems to help.
>>>>>>>
>>>>>>> I've tried both 8.2-RELEASE and FreeBSD 9 (head).  Running head now
>>>>>>> with
>>>>>>> a dtrace enabled kernel.
>>>>>>>
>>>>>>> Suggestions?
>>>>>>
>>>>>> On head, start with checking what source is used for driving clocks:
>>>>>> sysctl kern.eventtimer
>>>>>
>>>>> % sysctl kern.eventtimer                                  [master]
>>>>> kern.eventtimer.choice: HPET(450) HPET1(450) HPET2(450) LAPIC(400)
>>>>> i8254(100) RTC(0)
>>>>> kern.eventtimer.et.LAPIC.flags: 15
>>>>> kern.eventtimer.et.LAPIC.frequency: 0
>>>>> kern.eventtimer.et.LAPIC.quality: 400
>>>>> kern.eventtimer.et.HPET.flags: 3
>>>>> kern.eventtimer.et.HPET.frequency: 14318180
>>>>> kern.eventtimer.et.HPET.quality: 450
>>>>> kern.eventtimer.et.HPET1.flags: 3
>>>>> kern.eventtimer.et.HPET1.frequency: 14318180
>>>>> kern.eventtimer.et.HPET1.quality: 450
>>>>> kern.eventtimer.et.HPET2.flags: 3
>>>>> kern.eventtimer.et.HPET2.frequency: 14318180
>>>>> kern.eventtimer.et.HPET2.quality: 450
>>>>> kern.eventtimer.et.i8254.flags: 1
>>>>> kern.eventtimer.et.i8254.frequency: 1193182
>>>>> kern.eventtimer.et.i8254.quality: 100
>>>>> kern.eventtimer.et.RTC.flags: 17
>>>>> kern.eventtimer.et.RTC.frequency: 32768
>>>>> kern.eventtimer.et.RTC.quality: 0
>>>>> kern.eventtimer.periodic: 0
>>>>> kern.eventtimer.timer: HPET
>>>>
>>>>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> Changing this to "i8254" seems to have resolved the stalls.
>>>> I'm running buildworld -j12 without issue.  More than willing
>>>> to test out a patch or two against head if anyone's still
>>>> interested, otherwise I've thrown the change into loader.conf
>>>> and will move along quietly.
>>>
>>> 8.2-RELEASE you've mentioned doesn't have event timers subsystem and HPET
>>> timer driver. That makes me think it is strange at least. Can you try
>>> also
>>> LAPIC timer and do alike experiments with kern.timeocunter?
>>
>> My problems with 8.2-RELEASE may have been network based.  I don't recall
>> precisely if the clock was stalling there, my guess is no based on
>> what you wrote.
>>
>> I'll test LAPIC next ... so far so good.  Just so I'm clear, you'd
>> like me to tweak
>> kern.timecounter.hardware as well?  (Currently it's HPET).
>
> Yes. Instead. Ticking clock depends on both timecounter and eventtimer.

Haven't found a combination that hangs my machine other than with the
eventtimer at HPET.

>
>>> Also, please check whether kern.timecounter.tc.X.counter value changes
>>> for
>>> the selected timercounter and whether you are receiving timer interrupts
>>> in
>>> `vmstat -i`

Yep.