Clock stalls on Sabertooth 990FX
Joe Schaefer
joesuf4 at gmail.com
Mon Aug 15 22:23:47 UTC 2011
On Mon, Aug 15, 2011 at 5:47 PM, Joe Schaefer <joesuf4 at gmail.com> wrote:
> On Mon, Aug 15, 2011 at 5:23 PM, Alexander Motin <mav at freebsd.org> wrote:
>> On 16.08.2011 00:13, Joe Schaefer wrote:
>>>
>>> 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.
>>
>> I mean trying eventtimer HPET and different timecounters.
>
> Doesn't seem to help. Eventtimer HPET and timecounter ACPI-fast still stalls.
>
>>
>> If changing timecounter won't help, try please this patch:
>>
>> --- acpi_hpet.c.prev 2010-12-25 11:28:45.000000000 +0200
>> +++ acpi_hpet.c 2011-05-11 14:30:59.000000000 +0300
>> @@ -190,7 +190,7 @@ restart:
>> bus_write_4(sc->mem_res, HPET_TIMER_COMPARATOR(t->num),
>> t->next);
>> }
>> - if (fdiv < 5000) {
>> + if (1 || fdiv < 5000) {
>> bus_read_4(sc->mem_res, HPET_TIMER_COMPARATOR(t->num));
>> now = bus_read_4(sc->mem_res, HPET_MAIN_COUNTER);
>>
>> --
>> Alexander Motin
>
> Will do next.
>
Patch applied. Running with HPET eventtimer and no stalls during
make buildworld -j12.
More information about the freebsd-hackers
mailing list