On Sun, Oct 17, 1999 at 12:43:39PM -0700, Mike Cheponis wrote:
> 
> On Sun, 17 Oct 1999, Tom Javen wrote:
> > On Sun, 17 Oct 1999, Mike Cheponis wrote:
> 
> >> I installed 1.4.1 on an IBM 18G disk into a 2G partition.  Then I gave the
> >> disk to a friend to install into his machine.  (Both machines are K6-2/450
> >> MHz w/64 MB, but are otherwise not identical motherboards).
> 
> 
> > I got the same problem here with 20G IBM , seems that my motherboard (asus
> > p5a) with acer chipset has some problems on ultra dma .
> > 
> > works fine with a kernel compiled with :
> > wd*     at pciide? channel ? drive ? flags 0x0fac
> 
> > Tom
> 
> The motherboard has the Ali M1541/M1543C chipset.
> 
> I guess one question is: Is this a h/w problem that prevents, in the case
> you mention, the Ali (acer) chipset from properly doing ultra dma?
> 
> Or is this a problem with NetBSD's inability to massage the Ali chipset
> properly to do ultra dma?

Neither.  It is a problem inherent to the poor electricial specification
chosen for the IDE bus (notice the new UDMA/66 cable is a perfect
example of this madness, including enough wires to do differential
signaling but then using the extra ones only as a pseudo-shield by
grounding them at the controller end!).  This is why the UDMA modes
include that CRC-32 that you're seeing fail.  If you switch to using
the old "bus-master DMA" modes, you may very well just have data
corrupted without ever finding out, because those modes don't do the
CRC!

The right thing to do is "shift down" one UDMA mode -- the problem will
then generally go away.  Your drives almost certainly can't sustain
more than the 16.6MB/sec UDMA mode 1 will get you anyway, and since
we don't support IDE disconnection yet the extra bandwidth the higher
modes get you isn't useful for putting two drives on the bus, either.