From owner-freebsd-amd64@FreeBSD.ORG Tue Dec 2 21:15:13 2008 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E646C1065825; Tue, 2 Dec 2008 21:15:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6C3538FC1B; Tue, 2 Dec 2008 21:15:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mB2LEsxK011443; Tue, 2 Dec 2008 16:15:07 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-amd64@freebsd.org Date: Tue, 2 Dec 2008 15:59:05 -0500 User-Agent: KMail/1.9.7 References: <1224616985.00027652.1224606603@10.7.7.3> <49358A3F.7020701@root.org> <49358BED.3030903@FreeBSD.org> In-Reply-To: <49358BED.3030903@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812021559.05492.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 02 Dec 2008 16:15:07 -0500 (EST) X-Virus-Scanned: ClamAV 0.93.1/8712/Tue Dec 2 12:14:43 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Alexander Motin , freebsd-acpi@freebsd.org, peter@freebsd.org, Nate Lawson Subject: Re: Semi-working patch for amd64 suspend/resume X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2008 21:15:14 -0000 On Tuesday 02 December 2008 02:26:37 pm Alexander Motin wrote: > Nate Lawson wrote: > >> The only strange effect I have noticed was incorrect CPU time some > >> processes got: > >> %ps ax > >> PID TT STAT TIME COMMAND > >> 12 ?? WL 280503:38,05 [intr] > >> 1430 ?? Ss 280503:38,34 icewm > >> > >> But I think it is more timer driver related then resume itself. > > > > If you are using the LAPIC timer (default), it won't be running properly > > during resume. However, this wide discrepancy seems to indicate that > > the timer state is not being resumed properly. What if you use the ACPI > > timer (hw.timecounter.* I think are the sysctls)? > > As I understand, I am now using LAPIC timer for HZ generation, ACPI-fast > as time source and TSC as kernel DELAY() source. > > %sysctl -a | grep timecounter > kern.timecounter.tick: 1 > kern.timecounter.choice: TSC(-100) ACPI-fast(1000) HPET(900) i8254(0) > dummy(-1000000) > kern.timecounter.hardware: ACPI-fast > kern.timecounter.nsetclock: 3 > kern.timecounter.ngetmicrotime: 353840 > kern.timecounter.ngetnanotime: 481 > kern.timecounter.ngetbintime: 0 > kern.timecounter.ngetmicrouptime: 2014472 > kern.timecounter.ngetnanouptime: 8950060 > kern.timecounter.ngetbinuptime: 419099 > kern.timecounter.nmicrotime: 1460084 > kern.timecounter.nnanotime: 40830 > kern.timecounter.nbintime: 1500942 > kern.timecounter.nmicrouptime: 2210 > kern.timecounter.nnanouptime: 21 > kern.timecounter.nbinuptime: 1988392 > kern.timecounter.stepwarnings: 0 > kern.timecounter.tc.i8254.mask: 65535 > kern.timecounter.tc.i8254.counter: 46767 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.i8254.quality: 0 > kern.timecounter.tc.HPET.mask: 4294967295 > kern.timecounter.tc.HPET.counter: 3274417396 > kern.timecounter.tc.HPET.frequency: 14318180 > kern.timecounter.tc.HPET.quality: 900 > kern.timecounter.tc.ACPI-fast.mask: 16777215 > kern.timecounter.tc.ACPI-fast.counter: 14616414 > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > kern.timecounter.tc.ACPI-fast.quality: 1000 > kern.timecounter.tc.TSC.mask: 4294967295 > kern.timecounter.tc.TSC.counter: 3757339660 > kern.timecounter.tc.TSC.frequency: 2394021468 > kern.timecounter.tc.TSC.quality: -100 > kern.timecounter.smp_tsc: 0 > kern.timecounter.invariant_tsc: 1 > > There is sure some problem with LAPIC: > %vmstat -i > interrupt total rate > ..... > irq257: bge0 70774 29 > cpu1: timer 17600 7 > cpu1: timer 27617 11 > cpu1: timer 15849 6 > cpu1: timer 15413 6 > cpu1: timer 877180 367 > Total 2284801 957 Oh, it's getting a new counter on each resume. That is a bug. Ah, I think the AP's are using lapic_setup(1) when they should be using lapic_setup(0) during a resume. -- John Baldwin