Date: Fri, 12 Sep 1997 20:56:01 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: kjk1@ukc.ac.uk (K.J.Koster) Cc: questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Do *you* have problems with floppies? Message-ID: <199709122056.NAA24445@usr08.primenet.com> In-Reply-To: <Pine.SV4.3.95.970912200119.3901B-100000@kestrel.ukc.ac.uk> from "K.J.Koster" at Sep 12, 97 08:04:41 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Personally, I suspect timing issues with the floppy driver; I assume > > you are using an unFIFO'ed NEC floppy controller. Floppy timing is > > a critical factor in hysterisis effects and overall reliability. > > I do have in fact a NEC floppy controller :) Most everyone does. The point was the "unFIFO'ed" part. > Umm. If timing is so critical, why do MS-DOS and Win311 work flawlessly > with it? I mean, they are hardly real-time OS-es? Because they are non-reentrant real-mode interrupt handlers. While a request to the floppy is in progress, they buzz-loop pending its completion, and so do not have the problem that they give a quantum to someone else, then need to service a condition on the device within a timing window smaller than the remaining quantum supports. Because the condition on the device needs to be serviced within a timing window, if you are running something that does not give back the quantum immediately, then you miss the window. The SCO Xenix floppy drivers (perhaps the best floppy drivers ever written for both speed and reliability and various format support) were all hand crafted x86 assembly, and had the necessary buzz loops to avoid the issue. They are also not very portable to anything but x86 architecture machines, and they consume an inordinate amount of CPU time in system mode to meet the timing constraints. Too much CPU time for modern user space CPU loads relative to anticipated system space loads. > Let me put it like this: if floppy timing _is_ so critical, the FreeBSD > floppy driver must be buggy not to adhere to it. Let me put it like this: the floppy controller design in general, and its interface to PC architecture in particular (which could have included seperate FIFO components) is intrinsically flawed. The correct way to resolve this problem generally is to use components with FIFOs instead of components without. The correct way for a multitasking OS to deal with this is *NOT* to drop into a buzz loop and to cease being a multitasking OS for the duration of the loop, as you are suggesting. The correct way for a multitasking OS to deal with this is to either prohibit the use of the floppy drive when the system is not in single user mode so that there are not timing preterbations caused by user processes (as you yourself noted: the installation floppy access works fine, and it does so for that reason), OR to employ RT extensions in the kernel and treat the floppy timing constraints as RT task constraints, and program the device driver accordingly. For an OS with few RT features, the only course of action is to prohibit the use of the floppy in multiuser mode. So consider yourself prohibited to single user mode until FreeBSD can integrate RT features. > On the other hand, I've never ad any trouble when I switched to mtools. > How's that? You have poor hardware. If you didn't, you would not be seeing the problem, and we wouldn't be having this conversation. I personally do not own poor hardware (I refuse to reward vendors of poor hardware with money by going out and buying it), for example, so I can't personally repeat your problem. Realize that if you are using the DOSFS and you are using mtools, both still use the same underlying driver. The block sizes read from the device by mtools are larger contiguous reads. This is (apparently) sufficient to mask the timing issues causing your problem under the file system, which accesses the device in 512b blocks. As a sidebar, the "ft" program does the same thing for floppy tapes that mtools does for floppy disks. If you are seriously interested in working around this problem in the kernel, I suggest you modify the floppy driver to read a track at a time, and use read-before-write, and also write a track at a time (this, by the way, is an example of a character driver exhibiting block-like behaviour despite the users impression that character devices are acharacter at a time -- see the recent SCSI tape drive block discussion). You should do write gathering in case someone trys to write in non-track incrementes, to reduce the number of actual reads and writes that take place. Together, all this would mask the hysteresis issues that other people are seeing with the floppy driver, as well. Overall, a moderately nice kludge -- but a kludge, nonetheless. For the floppy tape case, reserve two buffers, and switch between them at the timing windows. This will allow you to be able to resynchronize the tape at a write block boundry, and will eliminate the need for the "ft" program (though you will spend much time resynchronizing, and will be hard put to make the drive stream under any moderate system load). Other than that, get a good controller part, or wait for the RT enhancements that were recently discussed on this list. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709122056.NAA24445>