Date: Mon, 15 Feb 1999 00:24:46 -0700 From: Warner Losh <imp@village.org> To: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org> Cc: mike@smith.net.au, valsho@yahoo.com, mobile@FreeBSD.ORG, nate@mt.sri.com Subject: Re: apm & current Message-ID: <199902150724.AAA35191@harmony.village.org> In-Reply-To: Your message of "Mon, 15 Feb 1999 13:36:17 %2B0900." <199902150438.NAA07446@tasogare.imasy.or.jp> References: <199902150438.NAA07446@tasogare.imasy.or.jp> <199902142124.NAA05491@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199902150438.NAA07446@tasogare.imasy.or.jp> Mitsuru IWASAKI writes:
: If you want see this, please try to run this script
: as many as possible and tail -f /var/log/messages
: with the original code :-)
:
: #!/bin/sh
: while true
: do
: apm > /dev/null &
: done
I'll give that a try.
: Actually, these changes was started from standby. All of our
: laptops (Sharp PC-9329T, Toshiba SS3010 and Hitachi Chandra2) could
: not change to standby state all the time, like apm -Z -> LCD
: blinking 2 or 3 times -> resume immediately. We made alot of try &
: errors, and found out one of the solutions, to invoked by
: apm_timeout() in kernel has some advantages against APM BIOS call
: directry via ioctl. I don't think this is the best solution, there
: may be better ways.
OK. I've seen this too (the apm -Z resuming "soon"). I'm not sure
what caused that. I suspected at the time it was an interrupt or
timeout that caused the wakeup. Maybe the right solution would be to
mask the timeout interrupts before suspending, then unmask them after
we get back from a suspend. I think that there is a race here that
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:
Instead of:
if (apm_int(&eax, &ebx, &ecx, &edx)) {
printf("Entire system suspend failure: errcode = %ld\n",
0xff & (eax >> 8));
return 1;
}
return 0;
have
unsigned s = splhigh();
if (apm_int(&eax, &ebx, &ecx, &edx)) {
printf("Entire system suspend failure: errcode = %ld\n",
0xff & (eax >> 8));
splx(s);
return 1;
}
splx(s);
return 0;
This might be a much simpler solution. I don't recall, howeer, if
splhigh() really disables interrupts or just defers them until later.
It might be a rare case for cli/sti:
__asm __volatile("cli" : : : "memory");
if (apm_int(&eax, &ebx, &ecx, &edx)) {
printf("Entire system suspend failure: errcode = %ld\n",
0xff & (eax >> 8));
__asm __volatile("sti" : : : "memory");
return 1;
}
__asm __volatile("sti" : : : "memory");
return 0;
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...
: On suspend, some machies (DEC HiNote Ultra II. etc) had problem
: with resume from suspend. After apm -z, pressing resume button
: caused power off the entire system, never resumed :-(
: We couldn't see why this happened, but after made fix suspend
: code this problem has gone. The cause is still unkown...
: # I guess it related with i/o interrupt?
That's my guess also.
: Anyway, now apm -Z VS PMEV_STANDBYREQ event, apm -z VS
: PMEV_STANDBYREQ or some events are handled equally
: by APM device driver (I think that is the point).
I'm sorry, but I'm not sure what you are getting at here.
: 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.
: Could you understand what I tried to say?
: Sorry for my poor english.
Yes. You have communicated well enough that I understand most of what
the code changes are trying to accomplish.
Warner
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?199902150724.AAA35191>