> I don't know.. commenting out the option just seems a bit childish. . . and
> you wonder why FreeBSD is gaining in the number of users.. with the amount of
> arrogance and backstabbing going on currently, it's no wonder.
The facts:
- After reading a few posts about silent fs corruption, Linus concludes
that the problem lies in the IDE-DMA code, and disables the default Bus
Mastering DMA option.
- The following people have tried to explain to Linus that this is the
WRONG way to handle this problem:
- Mark Lord.
- Gadi.
- Alan Cox.
- Andre Hedrick.
- Me.
- Apart from the fact that suddenly chopping off somebody else's code
is... well, not very elegant, in this case it is also WRONG on technical
grounds, because:
a) DMA mode 2 uses _exactly_ the same timings as PIO mode 4. So using
PIO mode 4 instead of DMA mode 2 brings nothing in terms of reliability.
It just decreases system performance, as it increases CPU load during
disk I/O.
b) UDMA doubles the data rate WRT DMA mode 2 (the clock rate is the
same, though). BUT IT HAS CRC! So, if both the drive and the controller
are UDMA compatible, UDMA should be used instead of PIO mode 4, because
there is _no_ _chance_ of a silent fs corruption (caused by the
interface) with UDMA. Reverting to PIO mode 4 if UDMA is available
decreases system reliability.
Conclusion: Linus wanted to increase the reliability of generic kernels,
and ended up decreasing it with his sledgehammer fix.
However, Linus said he would backout his changes if a blacklist feature
was added to the IDE-DMA code.
So, I posted an example of such a blacklist implementation, for kernel
2.0.35 (it takes < 6 lines of code...). Similarly, Andre Hedrick posted
his implementation of the blacklist feature.
I agree with TYTSO, the blacklist feature is only useful if the number
of known cases is small. Alan Cox has confirmed it is small.
So: could Linus just backout his sledgehammer fix, as he vowed he would
do? Then, could Mark Lord just go back to his status of Linux IDE Guy,
with Gadi as his main co-developer? And then, could we get over this
incident and go back to good relations among kernel developers?
Among kernel developers we can talk over technical issues on the
linux-kernel list, that's what it's for. At least in this case I think
the sledgehammer was not needed. Wrong tool for the wrong job.
Cheers,
-- Andrew D. Balsa andrebalsa@altern.org- 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