Date: Thu, 12 Aug 1999 10:35:08 +0900 From: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org> To: nate@mt.sri.com Cc: iwasaki@jp.freebsd.org, steveo@iol.ie, freebsd-current@FreeBSD.ORG, plm@xs4all.nl Subject: Re: recent apm changes Message-ID: <199908120131.KAA22707@tasogare.imasy.or.jp> In-Reply-To: Your message of "Wed, 11 Aug 1999 12:12:37 -0600" <199908111812.MAA00050@mt.sri.com> References: <199908111812.MAA00050@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Nate.
I'm sorry if my poor english troubled you.
> We should have no problems responding in this amount of time in FreeBSD,
> since we don't (didn't used to?) have any code that should cause
> significant delay in responding.
My understanding on system suspend code in FreeBSD is that once APM
driver get a system suspend request event from the BIOS, the driver is
hurry to put system into suspend state (execute suspend hooks and call
set power state function for suspend) as soon as possible without any
responses to the BIOS.
I think that this style is cool, I like, and no response to the BIOS
is not violating the APM specification at all, but there are many
BIOSes expecting response from driver. In Linux and NetBSD, they have
last request processing notification to the BIOS before transition into
suspend state. I guess they obtained the same conclusion to support
various BIOS implementations including buggy and bogus BIOSes.
That's why `suspending on Linux is OK, but on FreeBSD' like phenomenon
is there.... I'd like solve this if possible and need your help or
support.
From Linux code:
static void do_apm_timer(unsigned long unused)
{
int err;
static int pending_count = 0;
if (((standbys_pending > 0) || (suspends_pending > 0))
&& (apm_bios_info.version > 0x100)
&& (pending_count-- <= 0)) {
pending_count = 4;
err = apm_set_power_state(APM_STATE_BUSY);
if (err)
apm_error("busy", err);
}
From NetBSD code:
static void
apm_event_handle(sc, regs)
struct apm_softc *sc;
struct bioscallregs *regs;
{
int error;
struct bioscallregs nregs;
switch(regs->bx) {
case APM_USER_STANDBY_REQ:
DPRINTF(APMDEBUG_EVENTS, ("apmev: user standby request\n"));
if (apm_do_standby) {
if (apm_record_event(sc, regs->bx))
apm_userstandbys++;
apm_op_inprog++;
(void)apm_set_powstate(APM_DEV_ALLDEVS,
APM_LASTREQ_INPROG);
} else {
(void)apm_set_powstate(APM_DEV_ALLDEVS,
APM_LASTREQ_REJECTED);
/* in case BIOS hates being spurned */
apm_powmgt_enable(1);
}
break;
> > Last time, we didn't have `Last Request Processing Notification' to
> > APM BIOS at all for the second case.
>
> Huh? I don't see any mention of 'last request processing notification'
> anywhere above. Also, I don't believe the APM driver responds with a
Ah, details are described in `4. Advanced Power Managerment Software
Interface - 4.6.8 Set Power State'. `an appropriate Set Power State
call' includes 'last request processing notification' too.
They say:
Set Power State entry codes of CX=0004h and CX=0005h are used by the
APM Driver to respond to requests from the system BIOS for the
global Standby and Suspend states. The APM Driver uses the Last
Request Processing Notification (0004h) to indicate that it is
currently in the process of determining whether or not to reject the
request. This notification must be sent at least once every five
seconds after the APM driver receives the request by calling Get
Power Management Event. The APM driver must eventually end this
"busy" state by accepting the request, (calling Set Power State with
the appropriate state) or by rejecting the request using CX=0005h.
Thanks.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908120131.KAA22707>