Date: Tue, 5 May 1998 07:39:23 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: hasty@rah.star-gate.com (Amancio Hasty) Cc: chuckr@Glue.umd.edu, luigi@labinfo.iet.unipi.it, Nicolas.Souchu@prism.uvsq.fr, freebsd-hackers@FreeBSD.ORG Subject: Re: ISA PnP / snd PnP developments? Message-ID: <199805050739.AAA16950@usr02.primenet.com> In-Reply-To: <199805032004.NAA01429@rah.star-gate.com> from "Amancio Hasty" at May 3, 98 01:04:32 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> We don't use bios calls for drivers however very recently someone checked in > code to make bios calls which can come in handy for video adapters video > modes. Making INT 10 calls is generally a bad idea. It requires taking down most of the outstanding operations manually from the kernel side, in the expectation of CLI/STI/etc.. This is because it is common practice for video cards with DRAM, and some with "VRAM" (dual ported RAM) that have inherited BIOS code from a DRAM card, to disable all interrupts while doing any INT 10 processing. Specifically, I worked for a company that produced terminal emulators, and one of the modes it could operate in was a direct INT 10 call based interface (for compatability, without new drivers, with new hardware as it was released; it was a support stop-gap -- I design software for minimal engineering involvement in the support process, for the obvious reason that I am an engineer 8-)). We found an interesting problem, specifically with British Telecom and French Ministry of Defense users of the product. It seems that keybuk.com and keybfr.com both trap the keyboard interrupt, and will process to completion, but are very timing sensitive. Because of the elongated timing of input processing (and, truly, the stupid way the keyboard driver wedges were glued in), when the local keyboard driver was installed, we would lose keystrokes. Without the local keyboard driver installed, we did not lose keystrokes. The culprit was the Paradise(tm) and ATI(tm) VGA cards in the machines that were being used at the installations. Their INT 10 BIOS would disable interrupts, wait for a vertical blanking interval, and do the data writes during the interval to avoid producing visible artifacts. Because they wanted to not be interrupted between the time they saw the vertical retrace, and the time they did their work, they disabled all interrupts. While this may be an acceptable thing to happen on a single user system, it's *NOT* an acceptable thing to happen whenever the screen saver (for example) kicks in on your NFS server (please, no whining about "NFS servers should be embedded systems without video or keyboards, and with a DEC VT102P and a DECWriter attached to the 'P' for printing the console output on paper"). If you must complain about my example, then I'll point out that it's not acceptable, either, to lose PPP syncronization and drop your window size and compression into the toilet on a single user FreeBSD box, just because you type ctl-alt-+ on the console to change display resoloution to better view the 640x480 WWW page on your normally 1600x1200 resoloution screen. I would think long and hard about the circumstances under which you let an INT 10 call be made. The other calls ar not so timing critical (well, a floppy tape drive running program would probably fail, too), but INT 10 is a bear, if you emulate STI/CTI via VMM traps and CR4, where available. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805050739.AAA16950>