Date: Sun, 14 Feb 1999 20:50:25 -0800 From: Mike Smith <mike@smith.net.au> To: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org> Cc: mike@smith.net.au, imp@village.org, valsho@yahoo.com, mobile@FreeBSD.ORG, nate@mt.sri.com Subject: Re: apm & current Message-ID: <199902150450.UAA07920@dingo.cdrom.com> In-Reply-To: Your message of "Mon, 15 Feb 1999 13:36:17 %2B0900." <199902150438.NAA07446@tasogare.imasy.or.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > : 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902150450.UAA07920>