Date: Fri, 29 Dec 95 23:53 WET From: uhclem@nemesis.lonestar.org (Frank Durda IV) To: hackers%freebsd.org@rwsystr.lonestar.org, jkh%time.cdrom.com@rwsystr.lonestar.org Cc: uhclem@nemesis.lonestar.org Subject: EIDE support (was Re: Lowend support! ) Message-ID: <m0tVuEn-000CnFC@nemesis.lonestar.org>
next in thread | raw e-mail | index | archive | help
[0]What work remains to be done? I note that we don't support EIDE disks [0]for example. In what way can we folks here help? If you had asked this question two months ago, the answer would have been a lot nicer. Now, anyone following the EIDE situation in the retail channel probably wouldn't want to touch the EIDE project at all. There are now two things that make EIDE support a big pain. Even when there was only one known problem, Microsoft decided to not enable EIDE features in Windows '95. Here are the big issues as of last week: 1. The EIDE interface chip in hundreds of thousands of motherboards from Intel, which ended up in Gateway, AST, Packard Bell and probably a dozen other brands of computer you know has a serious bug in it. When the enhanced IDE features are enabled, the chip gets out of sync, and transfers the wrong data once in a while. A byte here, a byte there. I believe the chip was made by PC-TECH, and probably exists in many non-Intel boards as well. Microsofts' solution to this problem was to completely disable EIDE support in Windows '95. Intel is supposedly providing a DOS TSR that overrides the BIOS drivers for people running DOS or Windows 3.x, so that the BIOS can't enable the EIDE functions that are broken. Intel is also making BIOS updates available to some boards that also disable the EIDE support, leaving the user with conventional IDE performance. Intel does have a lot of information on this problem on their WWW site, but they are pretty evasive about how they are "fixing" the hardware problem with software. No wonder. That makes anyone who is thinking about writing additional code which turns on EIDE functions which will then corrupts peoples' hard disks think twice. It seems like the unpopular thing to do. But wait, there is more. 2. We've all heard it rumored for the past six years: If you have one IDE drive and you buy a second one to connect to the same interface, "it would be a lot better for you" (nudge, nudge, wink wink) if you bought the second drive from the vendor who made the first drive. A lot of people thought this was just marketing talk from the various drive vendors, hoping to lock you into their drives, and some people actually did have trouble getting the master and slave configurations working right. Sometimes the old drive would have to stay as Master or sometimes you would be forced to make it the Slave to get things working, but after that things "seemed" OK. But these problems were purely "plain IDE" incompatibilities. Then comes a rumor several weeks ago first in a couple of the trade rags that the EIDE interface pushed by Western Digital and Seagate IS NOT compatible with the ATA-2 standard (that is supposed to be the same thing but official) pushed by Conner, Maxtor and others. Then comes more official looking memos to OEMs from the various vendors confirming the situation, but putting the various corporate spins on who is to blame and why this OEM "is right" and that OEM "is wrong", and how big or small the problem really is. What it seems to boil down to is that if you have a EIDE-compliant drive and a ATA-2-compliant drive on the same IDE/EIDE host interface and you are using the EIDE/ATA-2 features (instead of running the drives in plain IDE mode), particularly if you enable DMA transfers, data on the drive NOT being accessed can be corrupted by transfers to and from the active drive. Some other non-DMAish functions also cause data transfer corruption, so avoiding DMA functions isn't good enough. The "solution" to avoid corruption from the vendors who even admit there is a problem: (A) don't allow EIDE and ATA-2 drives to be mixed in a system, OR (B) (get this) don't use any of the EIDE or ATA-2 features, including the use of IDE CD-ROM drives on interfaces that also have hard disk drives attached. Now I have been told by one drive vendor that even avoiding all the EIDE and ATA-2 extensions isn't good enough for some drive combinations, so you may not be able to mix at all. (ATA-2 hard disks and IDE CD-ROM combos seem OK, at least no one has said there is a problem on that combination yet.) Now, right now I don't know anybody who has gotten the same story twice from the drive vendors on this, so we should not assume all is lost for IDE in general, although if I was selling SCSI drives I would be chuckling quietly about now. Some retailers that are 100% Seagate/Western Digital shops (Computer City) or mainly Maxtor shops (COMP USA) are also sweating this issue, since computers sold by their stores may not have the same type IDE drive (EIDE vs ATA-2) as the one they principally sell as a "2nd" drive upgrade. These guys have a lot more to lose on this issue. Oh, the associated claim in one of the trade rags that corruption occurred even if you had a EIDE drive on the primary host IDE interface as Master, and you had an ATA-2 drive on the secondary host IDE interface as Master appears to be bogus. No vendor has even thought twice about denying that possibility. If after all the finger-pointing, denials, and leaked confirmations calm down and we get truthful and a halfway consistent explanation of the problem, maybe EIDE/ATA-2 can be salvaged. For the FreeBSD project, right now it sounds like EIDE/ATA-2 extensions are really dangerous for us to enable on just anybodys system. In my opinion, at the very least any EIDE/ATA-2 functions that are implemented should not be enabled automatically (remember, even Microsoft is not turning them on), and we must require the deliberate setting of a parameter or rebuilding the kernel before the EIDE/ATA-2 functions become active. Frank Durda IV uhclem@nemesis.lonestar.org Running with root/swap on a Western Digital EIDE drive and everything else on Barracudas. No more IDE drives for me!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0tVuEn-000CnFC>