notebook freezes

[Stefan Ehmann]

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.