Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Aug 2011 17:47:39 -0400
From:      Joe Schaefer <joesuf4@gmail.com>
To:        Alexander Motin <mav@freebsd.org>
Cc:        hackers@freebsd.org
Subject:   Re: Clock stalls on Sabertooth 990FX
Message-ID:  <CAOzHqcKJRSDZ6uUtdFN8Wovi5L70YM=EBzdyy2p63qYbJqH%2BwA@mail.gmail.com>
In-Reply-To: <4E498E3D.7050100@FreeBSD.org>
References:  <CAOzHqcJMWrO1Q-v8WpzxnyB0-TMQvVaBC9WQ6Qf_CkK_FtT3VA@mail.gmail.com> <mailpost.1313435952.4224912.75598.mailing.freebsd.hackers@FreeBSD.cs.nctu.edu.tw> <4E498326.2060308@FreeBSD.org> <CAOzHqcK3HMY=-7iNX05W43B=W5NP_bDWcJdDZ%2BEXk_Z%2BAdfAOw@mail.gmail.com> <4E4988F0.7060000@FreeBSD.org> <CAOzHqcK1_vkG6s7%2BgLGKx_kw7o1BVmyYKdxgK07FvadPMQkVUw@mail.gmail.com> <4E498E3D.7050100@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 15, 2011 at 5:23 PM, Alexander Motin <mav@freebsd.org> wrote:
> On 16.08.2011 00:13, Joe Schaefer wrote:
>>
>> On Mon, Aug 15, 2011 at 5:00 PM, Alexander Motin<mav@freebsd.org> =C2=A0=
wrote:
>>>
>>> On 15.08.2011 23:57, Joe Schaefer wrote:
>>>>
>>>> On Mon, Aug 15, 2011 at 4:35 PM, Alexander Motin<mav@freebsd.org>
>>>> =C2=A0wrote:
>>>>>
>>>>> On 15.08.2011 22:18, Joe Schaefer wrote:
>>>>>>
>>>>>> On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaefer<joesuf4@gmail.com>
>>>>>> =C2=A0wrote:
>>>>>>>
>>>>>>> On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapon<avg@freebsd.org>
>>>>>>> =C2=A0wrote:
>>>>>>>>
>>>>>>>> on 13/08/2011 20:16 Joe Schaefer said the following:
>>>>>>>>>
>>>>>>>>> Brand new machine with a Phenom II X6 1100T and under chronic loa=
d
>>>>>>>>> the clock will stop running periodically until the machine
>>>>>>>>> eventually
>>>>>>>>> completely
>>>>>>>>> freezes. =C2=A0Note: during these stalls the kernel is still runn=
ing,
>>>>>>>>> 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. =C2=A0Ba=
sed 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 t=
he
>>>>>>>>> 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). =C2=A0Running h=
ead now
>>>>>>>>> with
>>>>>>>>> a dtrace enabled kernel.
>>>>>>>>>
>>>>>>>>> Suggestions?
>>>>>>>>
>>>>>>>> On head, start with checking what source is used for driving clock=
s:
>>>>>>>> sysctl kern.eventtimer
>>>>>>>
>>>>>>> % sysctl kern.eventtimer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0[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
>>>>>>
>>>>>> =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>>> Changing this to "i8254" seems to have resolved the stalls.
>>>>>> I'm running buildworld -j12 without issue. =C2=A0More 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. =C2=A0I 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. =C2=A0Just so I'm clear, you'=
d
>>>> like me to tweak
>>>> kern.timecounter.hardware as well? =C2=A0(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 stal=
ls.

>
> If changing timecounter won't help, try please this patch:
>
> --- acpi_hpet.c.prev =C2=A0 =C2=A02010-12-25 11:28:45.000000000 +0200
> +++ acpi_hpet.c 2011-05-11 14:30:59.000000000 +0300
> @@ -190,7 +190,7 @@ restart:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bus_write_4(sc->me=
m_res, HPET_TIMER_COMPARATOR(t->num),
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0t->n=
ext);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> - =C2=A0 =C2=A0 =C2=A0 if (fdiv < 5000) {
> + =C2=A0 =C2=A0 =C2=A0 if (1 || fdiv < 5000) {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bus_read_4(sc->mem=
_res, HPET_TIMER_COMPARATOR(t->num));
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0now =3D bus_read_4=
(sc->mem_res, HPET_MAIN_COUNTER);
>
> --
> Alexander Motin

Will do next.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOzHqcKJRSDZ6uUtdFN8Wovi5L70YM=EBzdyy2p63qYbJqH%2BwA>