From owner-freebsd-mobile Sun Feb 14 23:22:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA17138 for freebsd-mobile-outgoing; Sun, 14 Feb 1999 23:22:44 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA17129 for ; Sun, 14 Feb 1999 23:22:42 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 10CIMR-0004TR-00; Mon, 15 Feb 1999 00:22:31 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.2/8.8.3) with ESMTP id AAA35191; Mon, 15 Feb 1999 00:24:47 -0700 (MST) Message-Id: <199902150724.AAA35191@harmony.village.org> To: Mitsuru IWASAKI Subject: Re: apm & current Cc: mike@smith.net.au, valsho@yahoo.com, mobile@FreeBSD.ORG, nate@mt.sri.com In-reply-to: Your message of "Mon, 15 Feb 1999 13:36:17 +0900." <199902150438.NAA07446@tasogare.imasy.or.jp> References: <199902150438.NAA07446@tasogare.imasy.or.jp> <199902142124.NAA05491@dingo.cdrom.com> Date: Mon, 15 Feb 1999 00:24:46 -0700 From: Warner Losh Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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