From owner-freebsd-mobile Sun Feb 14 20:55:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA00778 for freebsd-mobile-outgoing; Sun, 14 Feb 1999 20:55:17 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from dingo.cdrom.com (castles146.castles.com [208.214.165.146]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA00771 for ; Sun, 14 Feb 1999 20:55:15 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id UAA07920; Sun, 14 Feb 1999 20:50:25 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902150450.UAA07920@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Mitsuru IWASAKI cc: mike@smith.net.au, imp@village.org, valsho@yahoo.com, mobile@FreeBSD.ORG, nate@mt.sri.com Subject: Re: apm & current In-reply-to: Your message of "Mon, 15 Feb 1999 13:36:17 +0900." <199902150438.NAA07446@tasogare.imasy.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Feb 1999 20:50:25 -0800 From: Mike Smith 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. The APM segments are correctly set up in the #ifdef VM86 case in apmprobe. They definitely should not be set up anywhere outside of the APM code. > > > : - 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. Ah, you're concerned with apm_bios_call not being reentrant. Understood, and yes, it should use a simple lock and sleep on it. > > > : - 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. I'm primarily concerned with I/O that may be pending when the timeout occurs. I think that the suspend operation should spin waiting for I/O that's in progress to complete. > Could you understand what I tried to say? > Sorry for my poor english. No problems at all, and thankyou very much for taking the effort to work on this code and talk about it. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message