From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 15 21:13:54 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 694A0106566C; Mon, 15 Aug 2011 21:13:54 +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 125DE8FC1C; Mon, 15 Aug 2011 21:13:53 +0000 (UTC) Received: by vxh11 with SMTP id 11so5569066vxh.13 for ; Mon, 15 Aug 2011 14:13:53 -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=etoGHJknhagQ7rDRBZHUSe/lY4t6mA1L6G7sa6/V7i0=; b=aQ8/gdAFwfyA/qf5k1Ax3JIQBbUaP520yqQJvgq8lRu/qW9gu+p279IhqbcanNeteW RPM4ojNxeGErSSQKOinZLkyyTFS/ozEHv9OXT4Ya1CRXG5LSR7zEHjQvOh4tdvBtBZdC wcgniolhEW5hnF+7qffsdvSxFE+5K/Bmn31R0= MIME-Version: 1.0 Received: by 10.220.95.132 with SMTP id d4mr483404vcn.69.1313442833201; Mon, 15 Aug 2011 14:13:53 -0700 (PDT) Received: by 10.220.190.7 with HTTP; Mon, 15 Aug 2011 14:13:53 -0700 (PDT) In-Reply-To: <4E4988F0.7060000@FreeBSD.org> References: <4E498326.2060308@FreeBSD.org> <4E4988F0.7060000@FreeBSD.org> Date: Mon, 15 Aug 2011 17:13:53 -0400 Message-ID: From: Joe Schaefer To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: 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: Mon, 15 Aug 2011 21:13:54 -0000 On Mon, Aug 15, 2011 at 5:00 PM, Alexander Motin wrote: > On 15.08.2011 23:57, Joe Schaefer wrote: >> >> On Mon, Aug 15, 2011 at 4:35 PM, Alexander Motin =C2=A0= wrote: >>> >>> 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 chronic load >>>>>>> the clock will stop running periodically until the machine eventual= ly >>>>>>> completely >>>>>>> freezes. =C2=A0Note: during these stalls the kernel is still runnin= g, 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 ever= y >>>>>>> other setting but nothing seems to resolve this problem. =C2=A0Base= d 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=A0Running hea= d 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 =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 HP= ET >>> 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. > >>> Also, please check whether kern.timecounter.tc.X.counter value changes >>> for >>> the selected timercounter and whether you are receiving timer interrupt= s >>> in >>> `vmstat -i` Yep.