Date: Tue, 16 Aug 2011 09:59:38 -0400 From: Joe Schaefer <joesuf4@gmail.com> To: ambrosehuang ambrose <ambrosehua@gmail.com> Cc: Alexander Motin <mav@freebsd.org>, hackers@freebsd.org Subject: Re: Clock stalls on Sabertooth 990FX Message-ID: <CAOzHqcLaeN%2BPoE8s=eXyWVcXvV5YZ0AhiZOptS%2BLys=byLWcMA@mail.gmail.com> In-Reply-To: <CAMwoQQ7_MgOBfKZJA=D9ezT48Ft305o6C85CAwLeicM6mV4Mjg@mail.gmail.com> 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> <CAOzHqcKJRSDZ6uUtdFN8Wovi5L70YM=EBzdyy2p63qYbJqH%2BwA@mail.gmail.com> <CAOzHqcK1PbqV5S5tFG6uAwn5wGj0EXW67YSfw%2B8NRpkUC5dWqw@mail.gmail.com> <CAOzHqcJLwVnGunws5HfAVnHqm2wtroRhfwzxOeJibiVL9ypCMA@mail.gmail.com> <CAMwoQQ7_MgOBfKZJA=D9ezT48Ft305o6C85CAwLeicM6mV4Mjg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 16, 2011 at 7:39 AM, ambrosehuang ambrose
<ambrosehua@gmail.com> wrote:
>
>
> 2011/8/16 Joe Schaefer <joesuf4@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
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> --- secure/libexec/ssh-keysign/Makefile (revision 224899)
>> +++ secure/libexec/ssh-keysign/Makefile (working copy)
>> @@ -1,7 +1,7 @@
>> =C2=A0# $FreeBSD$
>>
>> =C2=A0PROG=3D =C2=A0ssh-keysign
>> -SRCS=3D =C2=A0ssh-keysign.c readconf.c roaming_dummy.c
>> +SRCS=3D =C2=A0ssh-keysign.c buffer.c readconf.c roaming_dummy.c
>> =C2=A0MAN=3D =C2=A0 ssh-keysign.8
>> =C2=A0CFLAGS+=3D-I${SSHDIR} -include ssh_namespace.h
>> =C2=A0.if defined(ENABLE_SUID_SSH)
>> Index: sys/dev/acpica/acpi_hpet.c
>>
>>
>> On Mon, Aug 15, 2011 at 6:23 PM, Joe Schaefer <joesuf4@gmail.com> wrote:
>> > On Mon, Aug 15, 2011 at 5:47 PM, Joe Schaefer <joesuf4@gmail.com> wrot=
e:
>> >> 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=A0wrote:
>> >>>>>
>> >>>>> 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 chroni=
c
>> >>>>>>>>>>> load
>> >>>>>>>>>>> the clock will stop running periodically until the machine
>> >>>>>>>>>>> eventually
>> >>>>>>>>>>> completely
>> >>>>>>>>>>> freezes. =C2=A0Note: during these stalls the kernel is still
>> >>>>>>>>>>> running,
>> >>>>>>>>>>> the
>> >>>>>>>>>>> machine is still
>> >>>>>>>>>>> mostly responsive, it's just that the clock is frozen in tim=
e.
>> >>>>>>>>>>>
>> >>>>>>>>>>> I've disabled Turbo mode in the bios and toyed with just abo=
ut
>> >>>>>>>>>>> every
>> >>>>>>>>>>> other setting but nothing seems to resolve this problem.
>> >>>>>>>>>>> =C2=A0Based 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). =C2=A0Runn=
ing
>> >>>>>>>>>>> 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
>> >>>>>>>>> =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 will=
ing
>> >>>>>>>> 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 yo=
u
>> >>>>>>> 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 o=
n
>> >>>>>> 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 t=
he
>> >>>> eventtimer at HPET.
>> >>>
>> >>> I mean trying eventtimer HPET and different timecounters.
>> >>
>> >> Doesn't seem to help. =C2=A0Eventtimer HPET and timecounter ACPI-fast=
still
>> >> stalls.
>> >>
>> >>>
>> >>> If changing timecounter won't help, try please this patch:
>> >>>
>> >>> --- acpi_hpet.c.prev =C2=A0 =C2=A02010-12-25 11:28:45.000000000 +020=
0
>> >>> +++ 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(s=
c->mem_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->next);
>> >>> =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_r=
ead_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)=C2=A0has a problem, that writes to =C2=A0compatitor regs wil=
l 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!)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOzHqcLaeN%2BPoE8s=eXyWVcXvV5YZ0AhiZOptS%2BLys=byLWcMA>