From owner-freebsd-current  Wed Aug 11 18:32:50 1999
Delivered-To: freebsd-current@freebsd.org
Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5])
	by hub.freebsd.org (Postfix) with ESMTP id 04ABF14E0D
	for <freebsd-current@FreeBSD.ORG>; Wed, 11 Aug 1999 18:32:43 -0700 (PDT)
	(envelope-from iwasaki@jp.FreeBSD.org)
Received: from localhost (isdnb47.imasy.or.jp [202.227.24.175])
	by tasogare.imasy.or.jp (8.9.3+3.2W/3.7W-tasogare/smtpfeed 1.01) with ESMTP id KAA22707;
	Thu, 12 Aug 1999 10:31:25 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
Message-Id: <199908120131.KAA22707@tasogare.imasy.or.jp>
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
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>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Thu, 12 Aug 1999 10:35:08 +0900
From: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org>
X-Dispatcher: imput version 980905(IM100)
Lines: 88
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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