From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 16 13:59:39 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0F03106564A; Tue, 16 Aug 2011 13:59:39 +0000 (UTC) (envelope-from joesuf4@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3BD988FC18; Tue, 16 Aug 2011 13:59:38 +0000 (UTC) Received: by vxh11 with SMTP id 11so6204158vxh.13 for ; Tue, 16 Aug 2011 06:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6WUt/WSgWlmuqbdbVdiqYpapTTFdLcrmBeKSz9tbHW8=; b=obz6zlizDg0wdW+BTl2gRqSfoG7t3CGy9utNr/+pd/WKhoIDCQI+KVWM3wjGMWFC5w MkxnwQ+xL6p2v0cNfMCFWPPSIR7CBqojPf+QCYwB7uu2uKj4IzHk6B5KhGMZHMVp1iqv gMCIeNFppC4xPPzrkwUJQhPv6ObNwY1hM9d0E= MIME-Version: 1.0 Received: by 10.220.107.12 with SMTP id z12mr529082vco.129.1313503178417; Tue, 16 Aug 2011 06:59:38 -0700 (PDT) Received: by 10.220.186.10 with HTTP; Tue, 16 Aug 2011 06:59:38 -0700 (PDT) In-Reply-To: References: <4E498326.2060308@FreeBSD.org> <4E4988F0.7060000@FreeBSD.org> <4E498E3D.7050100@FreeBSD.org> Date: Tue, 16 Aug 2011 09:59:38 -0400 Message-ID: From: Joe Schaefer To: ambrosehuang ambrose Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Alexander Motin , hackers@freebsd.org Subject: Re: Clock stalls on Sabertooth 990FX X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 13:59:39 -0000 On Tue, Aug 16, 2011 at 7:39 AM, ambrosehuang ambrose wrote: > > > 2011/8/16 Joe Schaefer >> >> 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 wrote: >> > On Mon, Aug 15, 2011 at 5:47 PM, Joe Schaefer wrot= e: >> >> On Mon, Aug 15, 2011 at 5:23 PM, Alexander Motin >> >> wrote: >> >>> On 16.08.2011 00:13, Joe Schaefer wrote: >> >>>> >> >>>> On Mon, Aug 15, 2011 at 5:00 PM, Alexander Motin >> >>>> =C2=A0wrote: >> >>>>> >> >>>>> On 15.08.2011 23:57, Joe Schaefer wrote: >> >>>>>> >> >>>>>> On Mon, Aug 15, 2011 at 4:35 PM, Alexander Motin >> >>>>>> =C2=A0wrote: >> >>>>>>> >> >>>>>>> On 15.08.2011 22:18, Joe Schaefer wrote: >> >>>>>>>> >> >>>>>>>> On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaefer >> >>>>>>>> =C2=A0wrote: >> >>>>>>>>> >> >>>>>>>>> On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapon >> >>>>>>>>> =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!)