Skip site navigation (1)Skip section navigation (2)
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
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>