From owner-freebsd-amd64@FreeBSD.ORG Tue Dec 2 19:26:55 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 DE0BD106567C; Tue, 2 Dec 2008 19:26:55 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id B07498FC19; Tue, 2 Dec 2008 19:26:54 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 228634412; Tue, 02 Dec 2008 21:26:53 +0200 Message-ID: <49358BED.3030903@FreeBSD.org> Date: Tue, 02 Dec 2008 21:26:37 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.17 (X11/20081029) MIME-Version: 1.0 To: Nate Lawson References: <1224616985.00027652.1224606603@10.7.7.3> <1224728582.00028075.1224715806@10.7.7.3> <4932F34C.1040804@FreeBSD.org> <200812021243.08513.jkim@FreeBSD.org> <49358684.7010508@FreeBSD.org> <49358A3F.7020701@root.org> In-Reply-To: <49358A3F.7020701@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: peter@FreeBSD.org, freebsd-acpi@FreeBSD.org, freebsd-amd64@FreeBSD.org, Jung-uk Kim 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 19:26:56 -0000 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 -- Alexander Motin