Date: Sun, 04 Mar 2007 12:14:25 -0800 From: Nate Lawson <nate@root.org> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-acpi@freebsd.org, Stefan Ehmann <shoesoft@gmx.net> Subject: Re: notebook freezes Message-ID: <45EB28A1.5010803@root.org> In-Reply-To: <20070305004000.B17935@delplex.bde.org> References: <200703011612.07110.shoesoft@gmx.net> <200703021619.33755.shoesoft@gmx.net> <20070304230346.O7298@besplex.bde.org> <200703041359.52213.shoesoft@gmx.net> <20070305004000.B17935@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>> On Fri, 2 Mar 2007, Stefan Ehmann wrote: >>>> On Thursday 01 March 2007 16:12, Stefan Ehmann wrote: >>>>> My few days old -current freezes if I press Fn-F6 (this is the >>>>> combination to adjust display brightness) if I've done a >>>>> suspend/resume >>>>> before. Directly after boot it works fine. >>>> >>>> ... >>>> So I did a binary search. >>>> >>>> src/sys/i386/isa/clock.c r1.231 causes my notebook to freeze. >>>> >>>> Reverting this change in a CURRENT from today fixes the problem. >>>> >>>> The notebook is still pingable in this state. I experienced some other >>>> random hangs recently but don't know yet if those are related. >>> >>> 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. >>> >>> %%% >>> Index: clock.c >>> =================================================================== >>> RCS file: /home/ncvs/src/sys/i386/isa/clock.c,v >>> retrieving revision 1.234 >>> diff -u -2 -r1.234 clock.c >>> --- clock.c 4 Mar 2007 04:55:19 -0000 1.234 >>> +++ clock.c 4 Mar 2007 11:58:00 -0000 >>> @@ -580,4 +582,5 @@ >>> /* Restore all of the RTC's "status" (actually, control) >>> registers. */ >>> /* XXX locking is needed for RTC access. */ >>> + rtc_reg = -1; >>> writertc(RTC_STATUSB, RTCSB_24HR); >>> writertc(RTC_STATUSA, rtc_statusa); >>> %%% >>> >>> A similar fix might be needed for amd64, but amd64 doesn't have a resume >>> hook for putting it in. The RTC index might get clobbered even if the >>> data registers aren't. >>> >>> 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. ;-) -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45EB28A1.5010803>