From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 5 21:50:28 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 8981C16A508 for ; Mon, 5 Mar 2007 21:50:28 +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 5861113C441 for ; Mon, 5 Mar 2007 21:50:28 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 9839 invoked from network); 5 Mar 2007 21:20:47 -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:20:47 -0000 Message-ID: <45EC89CD.5050907@root.org> Date: Mon, 05 Mar 2007 13:21:17 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (X11/20070214) MIME-Version: 1.0 To: Stefan Ehmann 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> <1173084724.1850.3.camel@localhost> In-Reply-To: <1173084724.1850.3.camel@localhost> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org 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:50:28 -0000 Stefan Ehmann wrote: > On Mon, 2007-03-05 at 15:21 +1100, Bruce Evans wrote: >> On Sun, 4 Mar 2007, Stefan Ehmann wrote: >>> 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(...); >> > > Putting this on top of rtc_resume, I get this on resume (all values are > hexadecimal): > > cur_rtc_reg = ff, rtc_reg = 0c > cur_rtc_statusa = 29 > cur_rtc_statusb = 42 Yes, that's what I expected. Reads from uninitialized regions of the southbridge usually return all 1's. PCI config registers usually show the same thing on resume until reprogrammed. The solution is to not assume anything about the state of the RTC in the resume method and always reprogram all the registers as if it was coming up from hard power off. -- Nate