> > Does that make DMA bad for disk IOs ? ;)
>
> No. You misunderstand my interest. Im not interested in whether DMA, polled
I think I perfectly understood your interest. ;)
But the fix has been to disable IDE DMA by default and I wanted to be sure
you were not suggesting that sort of fix.
Linux has millions of users and probably most of them will go with the
defaults. So, not enabling features by default is kind of swindle, IMO.
M$$ O/Ses are probably castrating systems this way in order to be
comfortable, but I would prefer Linux to be more honest with regards to
user expectations.
We probably should maintain black-lists for assumed mature features and
white-lists for very new features, but requiring users to enable features
by themselves if they want to get hardware features they paid for isn't
honest, IMO.
> I/O, or FIQ is the right way to do disk I/O. Im trying to find a pattern
> to the reports of people who get disk corruption in 2.1.10x and dont in
> 2.0.x (I've eliminated several reports that also had 2.0.x problems already
> and one person found the DMA problem was a CPU fan ;))
A system that seems to work is a real miracle, given all hardware errata,
software bugs, possible physical problems and partially broken pieces
of hardware. ;-)
> Im entirely interested in the following if people would like to mail me
> reports (off list and I'll summarise)
>
> Mail me only if they see disk corruption problems. The same procedure under
> 2.0.x doesnt cause problems (btw please for IDE test 2.0.34/35 with UDMA
> support too).
>
> o Disk controller type (IDE/SCSI) :
> o Disk Hardware :
> o Other devices on cable/chain :
> o Does 2.0.33 also corrupt :
> o Does 2.0.34/35 corrupt :
> o Are you using RAID (md driver software) :
> o What processor :
> o What chipset :
Very clear and quite nice approach to track the problem.
> > We must be aware that buses that donnot implement either parity or
> > CRC may lead to _silent_ data corruption.
>
> SCSI has parity and IDE has CRC. The IDE CRC was even done right - to a non
> aware host the IDE CRC error appears to be a soft drive error. Only a UDMA
> host realises its actually a cable CRC - so it fails safe
I have had a look in Intel chipset UDMA implementation.
They use the PCI clock as data transfer clock reference, so any
over-clocked system BUS with a chipset that uses a fixed divisor (2)
(overclocked PCI BUS) will also run UDMA beyond specifications.
BTW, is UDMA CRC a mandatory feature or some kind of optionnal feature?
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html