Date: Tue, 16 Aug 2011 19:39:27 +0800 From: ambrosehuang ambrose <ambrosehua@gmail.com> To: Joe Schaefer <joesuf4@gmail.com> Cc: Alexander Motin <mav@freebsd.org>, hackers@freebsd.org Subject: Re: Clock stalls on Sabertooth 990FX Message-ID: <CAMwoQQ7_MgOBfKZJA=D9ezT48Ft305o6C85CAwLeicM6mV4Mjg@mail.gmail.com> In-Reply-To: <CAOzHqcJLwVnGunws5HfAVnHqm2wtroRhfwzxOeJibiVL9ypCMA@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
> ===================================================================
> --- 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@gmail.com> wrote:
> > On Mon, Aug 15, 2011 at 5:47 PM, Joe Schaefer <joesuf4@gmail.com> wrote:
> >> 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>
> wrote:
> >>>>>
> >>>>> On 15.08.2011 23:57, Joe Schaefer wrote:
> >>>>>>
> >>>>>> On Mon, Aug 15, 2011 at 4:35 PM, Alexander Motin<mav@freebsd.org>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> On 15.08.2011 22:18, Joe Schaefer wrote:
> >>>>>>>>
> >>>>>>>> On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaefer<joesuf4@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapon<avg@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;
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMwoQQ7_MgOBfKZJA=D9ezT48Ft305o6C85CAwLeicM6mV4Mjg>