Date: Tue, 16 Feb 1999 04:15:52 +0900 From: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org> 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 Message-ID: <199902151918.EAA25436@tasogare.imasy.or.jp> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902151918.EAA25436>