From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 5 21:49:02 2007 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 604E616A402 for ; Mon, 5 Mar 2007 21:49:02 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 490DE13C49D for ; Mon, 5 Mar 2007 21:49:02 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 9708 invoked from network); 5 Mar 2007 21:19:08 -0000 Received: from ppp-71-139-18-69.dsl.snfc21.pacbell.net (HELO ?10.0.5.55?) (nate-mail@71.139.18.69) by root.org with ESMTPA; 5 Mar 2007 21:19:08 -0000 Message-ID: <45EC8969.8060405@root.org> Date: Mon, 05 Mar 2007 13:19:37 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (X11/20070214) MIME-Version: 1.0 To: Bruce Evans References: <200703011612.07110.shoesoft@gmx.net> <20070305004000.B17935@delplex.bde.org> <45EB28A1.5010803@root.org> <200703042242.58748.shoesoft@gmx.net> <20070305142926.O2780@besplex.bde.org> In-Reply-To: <20070305142926.O2780@besplex.bde.org> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, Stefan Ehmann Subject: Re: notebook freezes X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2007 21:49:02 -0000 Bruce Evans wrote: > On Sun, 4 Mar 2007, Stefan Ehmann wrote: > >> On Sunday 04 March 2007 21:14, Nate Lawson wrote: >>> Bruce Evans wrote: >>>> [Trying to redirect this from current to acpi.] >>>> >>>> On Sun, 4 Mar 2007, Stefan Ehmann wrote: >>>>> On Sunday 04 March 2007 13:27, Bruce Evans wrote: >> ... >>>>>> Oops. If suspend/resume clobbers the RTC state (which we already >>>>>> have code >>>>>> to restore), then it can clobber the RTC index (which even the >>>>>> restoral >>>>>> code assumes is unclobbered). Try this fix. >> ... >>>>>> I don't know how any of this works with ACPI. AFAIK (not far), the >>>>>> resume >>>>>> hook is only called for APM. >>>>> >>>>> Yes, rtc_restore() doesn't get called. So the patch changes nothing >>>>> for me. >>> >>> Bruce's patch should work if you add "device pmtimer" to your kernel >>> config. That will allow pmtimer_resume() to call timer_restore() which >>> calls rtc_restore(). >>> >>> If that works for you, Bruce can commit it modulo style bugs. ;-) > > Ha, some mailer mangled all the tabs inconsistently after I sent it. In > the original version, there are only some style bugs in nearby comments > that I wrote long ago. (The comments are misformatted and have rotted, > but still provided hints that there are may be problems in the locking. > I don't the current locking of individual RTC accesses since that just > asks for races in sets of accesses.) > >> Oops, seems I somehow screwed up Bruce's patch on first try (pmtimer was >> already in my config). Probably the aftermath of the lunar eclipse :) >> >> On my second try, timer_restore really gets called and it also fixes my >> problem. > > Could you add some RTC accesses to determine exactly what state is > inconsistent? Something like the following: > > cur_rtc_reg = inb(IO_RTC); /* Sloppy locking. */ > printf("cur_rtc_reg = %02x, rtc_reg = %02x\n", cur_rtc_reg, rtc_reg); > rtc_reg = -1; > cur_rtc_statusa = rtcin(RTC_STATUSA); > printf(...); > cur_rtc_statusb = rtcin(RTC_STATUSB); > printf(...); > > Where should such cghecks be put in acpi code if a hook like pmtimer's > is not available or not understood? I don't understand. Every driver implements a DEVICE_RESUME() method and that is responsible for figuring out the device-specific issues for properly restoring the hw from any state, likely all state lost. > Where do timer updates on suspend/resume happen for acpi? pmtimer handles both (see NOTES) since DEVICE_RESUME() is called from both apm and acpi. > Someday I > need to figure out why my laptop (HP nx6325) clobbers the time when > its lid is closed. Suspend stuff mostly doesn't doesn't work. In > particular, closing the lid doesn't even turn off the screen, but it > does clobber the time given by the acpi timecounter by almost exactly > 1 second. The TSC timecounter doesn't lose like this but it loses in > other ways. Opening the lid doesn't change the time. I don't have > pmtimer configured, but pmtimer would mess up the time even more because > the RTC drifts relative to the correct time and inittodr() doesn't > sync with the RTC so it is always off by an average of -0.5 seconds. No idea -- is something running in SMM for a long time? I seem to remember you had access to an oscilloscope. Check out the cpu pin SMACT# when you close the lid. -- Nate