Date: Wed, 11 Sep 1996 22:16:43 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: brianc@pobox.com Cc: freebsd-hackers@FreeBSD.org Subject: Re: IDE and ASUS P/I-P6NP5 Message-ID: <199609120516.WAA06208@phaeton.artisoft.com> In-Reply-To: <199609120141.VAA00555@ottawa.net> from "Brian Campbell" at Sep 11, 96 09:41:35 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > DMA mode isn't supported AFAIK. > > > > I think the problem is still that it is impossible to reliably detect > > support for the mode without crashing older (WD1007, etc.?) hardware. > > And Terry clearly has a problem with IDE in general. Not clear from this post; the only thing this post makes clear is that I have a problem with crashing older hardware to benefit newer hardware when it's reasonable to expect new hardware to take the old hardware into account when designing a standards compliant probe sequence. So, per se, I have a problem with some IDE hardware manufacturers, and a problem with the ATAPI specification allowing leeway to them to implement badly behaved hardware. So while I'm adverse to sloppy implementations, it doesn't mean that I believe it's impossible to have a non-sloppy implementation. On the other hand, I have yet to see one, so my expectations for one are pretty low. > Nonetheless I'd really love to have a bus-mastering IDE driver > available. I could care less if it automatically detects older > hardware, although other operating systems manage to do this. Windows 95 does this by allowing the user to reset "if the hardware probe hangs for an 'unreasonable' amount of time". It logs using sync writes going into each probe, and so it is possible to recover from destructive probes for nonexistant hardware (the failure case I'm complaining about here) by restarting, skipping the erroroneous probe. I have had to occasionally rebot five times on some sensitive hardware configurations during a Windows 95 install. I have suggested that BSD needs a fallback driver mechanism and a similar probe/install mechanism... without one, what you are asking is not going to happen because the underlying technology just isn't there. For what it's worth, NT has the VM86() capability to support fallback, yet does not support it. Clearly, Microsoft is attempting to force hardware manufacturers to build cleaner hardware by not filling in the cracks with Windows 95-like putty. > I'd be happy to manually specify that my IDE chipset and drive were > "DMA capable" for the dual benefit of freeing up the CPU for more > useful tasks and increased throughput. A perfectly reasonable way to implement it: an option, not enable by default. Feel free to implement the driver changes, since I certainly don't own any IDE hardware to enable me to help you out. > Now if we can just find someone capable of doing the work ;-) Sounded like you were volunteering... 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?199609120516.WAA06208>