I don't need to "measure" it.
I have a very clear report of a person who could reproduce the behaviour
at will.
It went away when he turned off IDEDMA.
To prove a theory you need lots of people. To _disprove_ something you
only need a single case.
And yes, he couldn't reproduce it at will without SMP. Which may mean that
there is a SMP problem, but is equally likely to mean that with SMP
enabled the machine had enough memory load that the DMA problems started
occurring because the timings were so tight.
> Or just run FreeBSD, which doesn't seem to be having any such problems.
Or has about .5% of the user base. Yes.
Do you remember the problems we had with interrupts enabled during data
transfers? It was a real problem, and again "just run FreeBSD, it doesn't
have the problem" came up as a solution. Sure, it doesn't have the
problem, because it doesn't have the hardware or the user base.
Anyway, I'm still open to the possibility that it's something else. It
could be extremely timing-dependent, and the person who could reproduce
his corruption easily might just have "just the right timings" until he
turned off IDE-DMA.
BUT: Whatever you claim, there _have_ been pervasive reports about
problems with IDE-DMA, for a long time. I've asked people to turn of DMA
before, exactly because the rumors have been there. We _know_ that our IDE
driver seems to be much too timing-sensitive for some reason, without ever
reporting errors even when they happen. Whether that's hardware or the
driver is secondary - the fact is that problems have magically gone away
when IDEDMA is turned off or when using a shorter cable.
And yes, in the Free/NetBSD camp it _is_ acceptable to say "don't use too
long a cable". That's the kind of mentality they have. With Linux,
however, we want to get people who have never in their life opened their
machine, and don't know whether the IDE spec says the cable can be 11" or
14" long. To those kinds of users the only right behaviour is to default
to the safest possible combination, and then allow the technical users the
possibility to (a) check that their hardware is ok and (b) turn on the
aggressive modes.
In short, you should not force users to have cutting-edge hardware. You
should not live at the edge of the spec software-wise, because you know
there is hardware out there that is sub-spec. A good driver takes sub-spec
hardware into account, whereas a bad drivers says "your hardware is
sub-spec, so screw you".
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