Date: Thu, 04 Dec 2008 01:37:03 +0200 From: Alexander Motin <mav@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: freebsd-acpi@freebsd.org, freebsd-amd64@freebsd.org, peter@freebsd.org Subject: Re: Semi-working patch for amd64 suspend/resume Message-ID: <4937181F.5000009@FreeBSD.org> In-Reply-To: <20081203210228.R1989@delplex.bde.org> 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> <49358BED.3030903@FreeBSD.org> <20081203210228.R1989@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > On Tue, 2 Dec 2008, 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. > > CPU times use mainly the cpu_ticker (TSC on i386), and the cpu_ticker code > has always been broken if the frequency changes a lot. The main bugs that > I know about are: Latest CPUs, including mine, does not change TSC frequency with EST and Cx states. So I think it is not frequency problem. I haven't checked if it specially handled, but I think, that when system suspended, timers may not be just stopped, but could also be reseted. If CPU looses all it's context, why should it keep some timer state? If timer reseted - it's value probably will go back, that may be seen as negative overflow. Here is some more related error messages I have found on resume: kernel: calcru: runtime went backwards from 5095 usec to 12 usec for pid 1544 (sh) kernel: calcru: runtime went backwards from 4704 usec to 12 usec for pid 1544 (sh) kernel: calcru: runtime went backwards from 1279 usec to 2 usec for pid 1543 (sh) kernel: calcru: runtime went backwards from 4180 usec to 9 usec for pid 1511 (moused) kernel: calcru: runtime went backwards from 11869 usec to 26 usec for pid 1435 (csh) kernel: calcru: runtime went backwards from 46399 usec to 102 usec for pid 1435 (csh) kernel: calcru: runtime went backwards from 4377 usec to 9 usec for pid 1434 (su) kernel: calcru: runtime went backwards from 10097 usec to 22 usec for pid 1432 (csh) -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4937181F.5000009>