From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 5 10:40:57 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 926B216A401 for ; Mon, 5 Mar 2007 10:40:57 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id F014C13C4A8 for ; Mon, 5 Mar 2007 10:40:56 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 05 Mar 2007 10:40:55 -0000 X-Provags-ID: V01U2FsdGVkX18sNigEQtws3lgOQe8yjwFPmkrOEz2OI5citB1wkz 5irRbF0Cyc3ID6 From: Stefan Ehmann To: Bruce Evans In-Reply-To: <20070305201904.K21224@delplex.bde.org> 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> <20070305201904.K21224@delplex.bde.org> Content-Type: text/plain Date: Mon, 05 Mar 2007 11:40:49 +0100 Message-Id: <1173091249.1276.1.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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 10:40:57 -0000 On Mon, 2007-03-05 at 20:39 +1100, Bruce Evans wrote: > On Mon, 5 Mar 2007, 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 > > Thanks. 29 and 42 are unclobbered, but ff is just invalid. Maybe it is > what the BIOS writes to indicate invalidity. 0xc is the register usually > accessed (RTC_INTR). > > Now I want to know what is the result of using this invalid index. > Read through this index using inb(IO_RTC + 1) and rtcin(rtc_reg) before > changing rtc_reg (the results should be the same). On my VIA amd64 > system, the result of rtcin(0xff) is 0xff. Probably nothing there. > This is is the worst possible result, since it ensures the problem > pointed out in my commit of the initial fix -- rtcintr() will spin > forever if it is called before rtc_restore(), waiting for one of > the const bits in the 0xff result to become unset. It's 0xc8 here.