Date: Mon, 05 Mar 2007 11:40:49 +0100 From: Stefan Ehmann <shoesoft@gmx.net> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-acpi@freebsd.org Subject: Re: notebook freezes Message-ID: <1173091249.1276.1.camel@localhost> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1173091249.1276.1.camel>