From owner-freebsd-mobile Mon Feb 15 11:18:26 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA17052 for freebsd-mobile-outgoing; Mon, 15 Feb 1999 11:18:26 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA17031 for ; Mon, 15 Feb 1999 11:18:23 -0800 (PST) (envelope-from iwasaki@jp.FreeBSD.org) Received: from localhost (ppp13.imasy.or.jp [202.227.24.23]) by tasogare.imasy.or.jp (8.9.3+3.1W/3.7W-tasogare/smtpfeed 0.92) with ESMTP id EAA25436; Tue, 16 Feb 1999 04:18:18 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Message-Id: <199902151918.EAA25436@tasogare.imasy.or.jp> To: imp@village.org Cc: iwasaki@jp.FreeBSD.org, mike@smith.net.au, valsho@yahoo.com, mobile@FreeBSD.ORG, nate@mt.sri.com Subject: Re: apm & current In-Reply-To: Your message of "Mon, 15 Feb 1999 00:24:46 -0700" <199902150724.AAA35191@harmony.village.org> References: <199902150724.AAA35191@harmony.village.org> 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: Tue, 16 Feb 1999 04:15:52 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 980905(IM100) Lines: 81 Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Just now, I understood why stanby was failed all the time, and how to change system state to standby w/o our patches. The console driver prevented our laptops from changing to standby state :-( In normal standby operation, we typed like this: % apm -Z(CR) [] <--- cursor position is here! and soon, % apm -Z % [] <--- prompt was displayed and cursor position have been moved! There was a race here. Following commands are almost equivalent to the effect of our patches from point of view of giving console driver enough time. % sleep 2 && apm -Z & Now I understand that our patch give console driver enough time to complete its process, then console driver quit disturbing standby. > the delay just codes around. Just a thought. Was that one of the > things that you tried? Or maybe we need just an splhigh() in > apm_suspend: [snip] > unsigned s = splhigh(); [snip] > __asm __volatile("cli" : : : "memory"); Yes, I already tried both of them. Using "cli" was implemented in apm_setup.s ("pushfl", "cli", "lcall", "setc [to get carry flag value]", then "popfl"). > But I worry that not all APM bioses can handle waking up from this > condition. The APM 1.2 document is silent on this issue, as far as I > can tell... As our conclusion, this cli hack (or splhigh()) doesn't make us happy, standby was still failed. And the situation was getting worse because sometime the system froze... > : Anyway, now apm -Z VS PMEV_STANDBYREQ event, apm -z VS Sorry, typo here. > : PMEV_STANDBYREQ or some events are handled equally PMEV_SUSPENDREQ > : by APM device driver (I think that is the point). > > I'm sorry, but I'm not sure what you are getting at here. What I was trying to explain is that; There are tow ways to suspend the system as you know, one is to execute command apm -z (or zzz) which posted to APM device driver via ioctl, another is pressing hotkeys (such as Fn+F12 on my system) or APM BIOS timeout which posted to APM device driver as APM events. The standby also. However, thier proccesses are quit different; [apm -z ] -> ioctl -> apmioctl -> apm_suspend -> apm_suspend_system -> apm_int -> apm_bios_call -> [suspend] [hotkeys] -> apm_timeout -> apm_processevent -> apm_getevent -> apm_suspend -> apm_suspend_system -> apm_int -> apm_bios_call -> [suspend] The patches is trying to change these sequence, and suspend operation to be handled equally by APM driver as follows; [apm -z ] -> ioctl -> apmioctl -> apm_suspend -> [register suspend request] [hotkeys] -> apm_timeout -> apm_processevent -> apm_getevent -> apm_suspend -> [register suspend request] After register suspend request, the rest of sequence is the same; [apm_timeout] -> apm_do_suspend -> apm_suspend_system -> apm_int -> apm_bios_call -> [suspend] And, I've forgotten to tell you that when we made that patches, I referred to the APM code from NetBSD and Linux. Especially NetBSD's one gave us alot of ideas. Both of them follows this style if I remember correctly. > : I believe that vm86 provide alot of advantage against > : apm_init.S especially on probing APM BIOS and debugging. > > Yes. It does. I've found things are more stable. Oh that work was done by you, great! Thanks alot and I must respect your efforts. # What time is it? Ah, I need to go to bed!...zzz...apm -z... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message