Date: Tue, 18 Nov 1997 20:11:13 -0700 From: Nate Williams <nate@mt.sri.com> To: HAMADA Naoki <hamada@astec.co.jp> Cc: Nate Williams <nate@mt.sri.com>, freebsd-mobile@FreeBSD.org Subject: Re: APM and Compaq Contura 400CX Message-ID: <199711190311.UAA04160@mt.sri.com> In-Reply-To: <ixu3d9fv49.fsf@astec.co.jp> References: <Pine.BSF.3.96.971118172917.29329A-100000@kn6-045.ktvlpr.inet.fi> <199711182043.NAA03016@mt.sri.com> <ixu3d9fv49.fsf@astec.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
> >This is no good. I could easily fix this, but I'm not sure what's the > >best way to do this and still maintain compatability with other > >machines/specificiations. Fixing it to work on your machine may break > >it on other machines. :( > > Compaq seems to have some different idea to cope with APM. When the > APM driver sends APM_SETPWSTATE command which sets the state to > PMST_SUSPEND, the APM BIOS generates PMEV_STANDBYREQ event. Ahh, I see. Thanks for the clarification. Currently, FreeBSD doesn't support 'standby', and only does a full suspend. > Then > FreeBSD's APM driver invokes apm_suspend(), which is quite strange > because the bios requires not suspend but standby. Right, but we don't support it. > The APM driver > sends APM_SETPWSTATE command, and the APM BIOS generates > PMEV_STANDBYREQ event, so, alas, it loops infinitely until the stack > corrupts. *sigh* > Ignoring spurious PMEV_STANDBYREQ is another solution, but it must be > far from the right thing. It is, but it is probably the 'correct' things to do for now until we implement STANDBY. It should be pretty easy to implement STANDBY, but no-one has taken the time to do it, and I'm working on pccardd right now, so I'm not going to get to it anytime soon. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711190311.UAA04160>