From owner-freebsd-mobile Sun Feb 14 20:39:01 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA29324 for freebsd-mobile-outgoing; Sun, 14 Feb 1999 20:39:01 -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 UAA29319 for ; Sun, 14 Feb 1999 20:38:59 -0800 (PST) (envelope-from iwasaki@jp.FreeBSD.org) Received: from localhost (ppp2.imasy.or.jp [202.227.24.12]) by tasogare.imasy.or.jp (8.9.3+3.1W/3.7W-tasogare/smtpfeed 0.92) with ESMTP id NAA07446; Mon, 15 Feb 1999 13:38:44 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Message-Id: <199902150438.NAA07446@tasogare.imasy.or.jp> To: mike@smith.net.au Cc: imp@village.org, iwasaki@jp.FreeBSD.org, valsho@yahoo.com, mobile@FreeBSD.ORG, nate@mt.sri.com Subject: Re: apm & current In-Reply-To: Your message of "Sun, 14 Feb 1999 13:24:43 -0800" <199902142124.NAA05491@dingo.cdrom.com> References: <199902142124.NAA05491@dingo.cdrom.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: Mon, 15 Feb 1999 13:36:17 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 980905(IM100) Lines: 89 Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > : Adding to this, I noticed many other problems in apm code, such as > > : - Fixed segment description for APM. The limit granularity should be > > : specified in bytes, not pages. > > > > This looks good. > > I curse myself for missing the patch here. The segment limits are only > ever specified in bytes as far as I can tell; we should be using vm86 > all the time to get the APM information now. The proper way to fix this is to correct APM entry of gdt_segs[] in /sys/i386/i386/machdep.c, I think. > > : - Try to limit the number of apm_bios_call() executing to only one > > : at the same time, watching busy state made by previous call and > > : waiting if necessary. > > > > I wonder how this can happen, but it couldn't hurt. > > It can't happen, until the SMP giant kernel lock goes away, and at that > point it should be fixed to use a suitable SMP locking construct. > Don't add any other code to obfuscate this. The APM BIOS calls invoked by apm_timeout() every seconds VS BIOS calls via ioctl invoked by other APM application like wmapm (WindowMaker stuff) or apm(8) seem to bump, but it is no serious matter as Warner Losh mentioned. I saw this symptom on 2.2.8 with PAO, but never seen on 3.0 so far. 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 > > : - Made apm_suspend() and apm_standby() be invoked by apm_timeout() in order to > > : obtain stablities. > > > > What stabilities are these? I'm curious. > > Likewise. I'm not sure that hanging these off apm_timeout is bad, but > I'm puzzled as to what this hopes to gain. It strikes me that this > may result in pending disk I/O etc. which will be lost by the suspend/ > standby. 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. 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? 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). > > : - Added adjustment for segment size limits informed by APM BIOS. Following > > : patch for apm_init.S and make in /sys/i386/apm/apm_init/ to generate > > : apm_init.inc are required if VM86 isn't enabled in your kernel. > > > > These look good to me. > > They're redundant; vm86 should be non-optional. I think so too on 3.0/4.0, but 2.2.8... I believe that vm86 provide alot of advantage against apm_init.S especially on probing APM BIOS and debugging. Could you understand what I tried to say? Sorry for my poor english. # BTW, I'm quite new for PAO code :-) , don't know # well the history and technical details on PAO, # so please don't give me quiestions on this point. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message