Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.cis.okstate.edu!news.ksu.ksu.edu!news.mid.net!crcnews.unl.edu!news.inetnebr.com!legba.synergy.net!imci2!news.internetMCI.com!newsfeed.internetmci.com!swrinde!news-relay.us.dell.com!news-relay.us.dell.com!not-for-mail From: james@raid.us.dell.com (James R. Van Artsdalen) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: EIDE driver - when? Date: 10 Mar 1996 12:00:11 -0600 Organization: Dell Computer Corporation Lines: 53 Message-ID: <4hv5bb$hg@raid.us.dell.com> References: <4gvg2m$ehq@oravannahka.Helsinki.FI> Reply-To: james@raid.us.dell.com (James R. Van Artsdalen) NNTP-Posting-Host: raid.us.dell.com In <4gvg2m$ehq@oravannahka.Helsinki.FI> Lasse Hannelius <hanneliu@cc.helsinki.fi> wrote: > Is there an EIDE (PIO 3/4) driver available anywhere? OS drivers don't deal with PIO mode settings. The BIOS configures the PIO access timing before booting and the OS just does PIO transfers. But there are other reasons for wanting a fancy IDE driver: see below. > Won't a new 5400rpm drive be severly hampered by the current driver? PIO timings only affect the transfer rate from the drive's buffer into the system. As long as PIO timings are fast enough to keep up with data going into the drive buffer (from the disk head), PIO timing should only affect overhead (a slow PIO timing that is still fast enough for the drive will cause higher CPU overhead even though drive throughput is not hurt). The main things to look for in an IDE driver are: 1. a PC-Tech work around. Many systems based on Intel's Plato platform have this chip. The bug is that the IRQ arrives early, before the last few bytes of data from the disk drive. If the systems takes the interrupt immediately and tries to start a new command, the system may fail. The interrupt must be deferred until after the PIO is complete. 2. A CMD workaround. First generation CMD IDE controllers have a bug that causes concurrent data transfers on both IDE channels to interfere with each other and corrupt data. The fix is to serialize transfers across both channels. One idea is to detect at driver init time whether the problem exists. Then, just before each REP INS or REP OUTS, mask the IRQ for the other IDE channel in the interrupt controller, and restore the interrupt controller mask bit after the PIO. 3. Multi-sector block I/O. In theory this should get slightly lower throughput than single-sector I/O. In practice many drives seem to get much better performance with multi-sector blocks. In any case multi-sector blocks should get lower OS overhead. 4. DMA. Triton-style IDE DMA would lower CPU overhead. 5. 32-bit PIO. Some IDE controllers support 32-bit I/O and work faster when 32-bit I/O is used (I know, theoretically it shouldn't be faster, but perhaps the chip has a weird design). Some of these may already be implemented: I wouldn't know, as I use SCSI exclusively with data I care about. -- James R. Van Artsdalen james@dell.com "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759-7299 512-728-8789