Date: Tue, 2 Jan 1996 15:15:51 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: uhclem@nemesis.lonestar.org (Frank Durda IV) Cc: hackers@freebsd.org, jkh@time.cdrom.com, uhclem@nemesis.lonestar.org Subject: Re: EIDE support (was Re: Lowend support! ) Message-ID: <199601022215.PAA12795@phaeton.artisoft.com> In-Reply-To: <m0tVuEn-000CnFC@nemesis.lonestar.org> from "Frank Durda IV" at Dec 29, 95 11:53:00 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. Wrong. They are enabled by default. You must: o Start menu o Select "Settings" SubMenu o Select submenu item "Control Panel" o Double click the "System" control panel item o Click the "Performance" tab o Click the "File system..." button under the "Advanced Settings" tab group to bring up the "File System Properties" dialog o Click the "Troubleshooting" tab o Click the checkbox to cause a checkmark to appear to the left of the "Disable all 32 bit protect-mode disk drivers" o Click the "Apply" button o Click the "OK" button o Acknowledge all the windows closed and let it reboot your system This will disable the EIDE feature that triggers the well known bug. I had to do this 3 days ago on my dad's computer. > 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. It is the RZ1000 chip. It is used in approximately 1/3 of all EIDE controllers. The actual problem is that a disk interrupt received during a DMA will cause the DMA to silently fail. This was discussed to death in the comp.sys.intel news group. > Microsofts' solution to this problem was to completely disable EIDE > support in Windows '95. Was to make *you* disable it. One of the reasons we just got a Microsoft support center here in Tucson. > 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. Right. The "fix" is to disable overlaping (some BIOS's that can set it call it "interleaved") I/O to the controller. > 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. The main EIDE feature is its ability to do CDROM. It does this by pushing SCSI commands to the CDROM over the EIDE bus interface. Suprise! You *can't* avoid SCSI this way, so you might as well give in and go SCSI in the first place. 8-). [ ... ] > 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. Oh yea. > 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. I think that a pure ATA-2 environment can be salvaged... at least I haven't seen any counterclaims. Anyway, barring minor corrections (which you should look up in a comp.sys.intel archive instead of trusting me 8-)), I think your article ought to be posted everywhere and emailed to the editors at the trade rags. 8-). 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?199601022215.PAA12795>