Date: Mon, 15 Feb 1999 13:36:17 +0900 From: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org> 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 Message-ID: <199902150438.NAA07446@tasogare.imasy.or.jp> 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>
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. > > : - 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902150438.NAA07446>