Clock stalls on Sabertooth 990FX

Joe Schaefer joesuf4 at gmail.com
Tue Aug 16 13:59:39 UTC 2011 

On Tue, Aug 16, 2011 at 7:39 AM, ambrosehuang ambrose
<ambrosehua at gmail.com> wrote:
>
>
> 2011/8/16 Joe Schaefer <joesuf4 at gmail.com>
>>
>> FWIW here's a patch I needed to get buildworld to complete against head
>> (as of today):
>>
>> Index: secure/libexec/ssh-keysign/Makefile
>> ===================================================================
>> --- secure/libexec/ssh-keysign/Makefile (revision 224899)
>> +++ secure/libexec/ssh-keysign/Makefile (working copy)
>> @@ -1,7 +1,7 @@
>>  # $FreeBSD$
>>
>>  PROG=  ssh-keysign
>> -SRCS=  ssh-keysign.c readconf.c roaming_dummy.c
>> +SRCS=  ssh-keysign.c buffer.c readconf.c roaming_dummy.c
>>  MAN=   ssh-keysign.8
>>  CFLAGS+=-I${SSHDIR} -include ssh_namespace.h
>>  .if defined(ENABLE_SUID_SSH)
>> Index: sys/dev/acpica/acpi_hpet.c
>>
>>
>> On Mon, Aug 15, 2011 at 6:23 PM, Joe Schaefer <joesuf4 at gmail.com> wrote:
>> > 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.
>> >
>
> it maybe help, I used to come across a bug on Linux with regard to HPET,
> some northbridge chipset (maybe amd's, where
> HPET sit on) has a problem, that writes to  compatitor regs will not take
> effect immediately, you need a read to reg to flush it;

So far the patch performs flawlessly for me.  I'm tempted to reenable turbo
mode just for kicks (someday, not today- delighted with the uptime!)

More information about the freebsd-hackers mailing list