Date: Tue, 2 Dec 2008 15:59:05 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-amd64@freebsd.org Cc: Alexander Motin <mav@freebsd.org>, freebsd-acpi@freebsd.org, peter@freebsd.org, Nate Lawson <nate@root.org> Subject: Re: Semi-working patch for amd64 suspend/resume Message-ID: <200812021559.05492.jhb@freebsd.org> In-Reply-To: <49358BED.3030903@FreeBSD.org> References: <1224616985.00027652.1224606603@10.7.7.3> <49358A3F.7020701@root.org> <49358BED.3030903@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200812021559.05492.jhb>