I'm sorry I've been stressed during this, but why do you think I disabled
the config option instead of talking to you?
I _have_ talked to you before about this, and I could not get you to even
admit the possibility that there could be some problem with DMA. As such,
when the new report came in, I didn't have much choice but to force people
to look at this.
And yes, I've been extremely irritated by hearing the same bogus arguments
("timing is same for PIO and DMA" - wrong, "we have to use DMA because the
BIOS told us to" - wrong, "(U)DMA CRC's make it more reliable than PIO" -
wrong if the corruption happens _after_ the CRC check etc etc).
And I fully _expect_ there to be other bugs too. Don't get me wrong - the
IDE DMA problem is not likely to be "the one and final problem". I'm
trying to find problems with SMP and SCSI too, but the point is that right
now I _do_ have several reports telling me that their problems go away
when they disable DMA on IDE.
So pointing to other potential problems does not get you off the hook, so
to say. IDE DMA is _one_ problem, and so far it's been extremely hard to
even convince you to look at it (to the point that only once you get a
paper from a chipset manufacturer do you even admit to the _possibility_
that there might be drives with UDMA problems).
I'll continue to look at the other reports, but I'd like to get at least
one of the problems fixed instead of going round the ring with you just
trying to convince you that there may be a problem in DMA.
In short:
- there are definitely reports about this happening on UP too, not just
SMP.
- There are potentially _additional_ problems with SMP. Ingo found an
interesting one, although as far as I can tell it looks like the thing
Ingo looked at might be a problem on UP too.
- There have been reports of corruption with certain SCSI drivers too.
But two or more bugs don't "cancel" each other.
I'm sorry for having been irritable, but I want to get 2.2 out the door
and through a code-freeze, and disk corruption is _serious_. It's even
more serious when one of the major developers apparently doesn't even want
to entertain the notion that there might be problems.
Linus
-
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