lkml.org 
[lkml]   [1998]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.1.111: IDE DMA disabled?
Hi,

On Sun, 26 Jul 1998, Linus Torvalds wrote:

> On Sun, 26 Jul 1998, Alan Cox wrote:
> >
> > > Personally, I never understood why DMA was enabled by default anyway. As
> > > far as I can tell the only sane thing is to have it always disabled by
> > > default, and enable it with hdparm.
> >
> > Its a factor of 10 speedup in effective throughput. It was turned on by
> > the BIOS - which may have configured aspects of the firmware we don't even
> > know about for DMA only operation.
>
> BUT THERE HAVE BEEN REPORTS OF CORRUPTION WITH IDE-DMA FOR TOO LONG, AND
> WE'RE READYING FOR A STABLE RELEASE!

(no need to shout)
>
> I don't buy into the BIOS argument. I've heard it before, and it sounds
> completely bogus to me. If you're running Win3.11, the BIOS will have done
> the same thing, and I know win3.11 doesn't use DMA in its native driver.
> And I bet they tested that configuration. In short, whoever came up with
> the argument that "if the BIOS tells us that it can do DMA, we must follow
> that" is just out to lunch or is trying to reach for any reason to keep it
> enabled.

I have yet to come across a Win 3.11/DOS IDE (U)DMA driver, please point
me to one.
What you will see are Windows 95 DMA Bus Mastering drivers. Those set
safe timings which might not be available from the BIOS initialization
routines.

And Alan _is_ correct. The BIOS usually detects the chipset, and also
checks whatever drives are attached to the IDE channels for (U)DMA
compatibility.

Most recent BIOSes report this in their boot message. They may also be
setting timing parameters for (U)DMA transfers. I can give you at least
one example: the ASUS SP-97V motherboard.

>
> The argument is proven false by the fact that people who saw corruption
> with DMA on didn't see it with DMA off. In short, my counter-argument is
> that we _know_ that DMA is unsafe. Rather than wild and idle speculation,
> we have FACTS. And when it comes to fact vs wild speculation, I'll go with
> the facts any day.

At least on EIDE drives (I am not mentionning SCSI DMA, I do not have
any SCSI drives), DMA timings are much more stringent than PIO timings.
And UDMA is much worse, because we are doubling the data rate (although
the clock rate stays the same at 16.6MHz).

If you want facts, you should check the ATA-4 specs (about 340 pages).
There is an entire appendix on various timing issues raised by UDMA
(only 26 pages) "Signal Integrity issues for ATA/ATAPI4".
>
> Quite frankly, as long as the IDE driver defaults to DMA on when
> configured with IDEDMA, the IDEDMA thing won't be visible by default. I
> categorically refuse to have an option that is known to cause various
> silent corruptions. It was fine in a development series, but sorry, it's
> no longer acceptable.

IMHO it is _never_ fine to have silent corruption, but I believe the
problem is not in the IDE DMA driver. Mark Lord wrote a fine piece of
code which has been exercised by more people than we would care to
count, in various configurations, with different chipsets and different
hard disk drives from various manufacturers. Considering the diversity
of the hardware involved, it is a tribute to Mark's code quality that
there haven't been more reports of problems.
>
> And yes, Alan, it's trivial to get 10 times throughput improvement by
> being buggy. I can calculate PI to 20 billion digits in less than two
> seconds if I'm not required to actually get the right answer. Does that
> make my computer a supercomputer?

What Alan was saying (correct me if I am wrong) is that for DMA
transfers to be enabled by the IDEDMA driver, you need:

1) a DMA capable chipset.
2) a DMA capable drive.
3) for UDMA transfers, you additionally have to enable UDMA in the BIOS
CMOS SETUP (otherwise the drive reverts to standard DMA transfers).

So, if these two/three conditions are present, it should be OK to assume
that DMA/UDMA can be enabled safely.

My experience with (U)DMA mode2 indicates that the driver is extremely
safe for DMA mode2, but may cause flawed or marginal hardware to fail
when used in UDMA mode 2.

Things to watch for are:

a) Drive quality. Quantum drives are very reliable, but this is not
surprising since they worked with Intel to develop both DMA mode2 and
UDMA. IBM drives are good, too. Don't know about the others. I have seen
reports of entire batches of drives from Western Digital having
problems, and at least one Samsung drive I tested would consistently
malfunction under both DMA mode 2 and UDMA, even though it was specified
as UDMA compatible. The same equipment with an IBM drive has been
working flawlessly for a year, using UDMA.
b) Cable length (less than 18 inches, but I prefer 12 inches or less).
c) Connector layout (preferably connect the (U)DMA hard disk at the end
of the chain).
d) I prefer one (U)DMA drive per channel/cable. Some EIDE drives still
don't get along well with drives from other manufacturers on the same
cable.
e) DON'T overclock the PCI bus. The PCI bus timings get passed on to the
(U)DMA controller in most cases and may cause data corruption (most of
the time, not silent at all).

Summarizing: just as any other piece of code in the kernel, the IDEDMA
driver by Mark Lord will fail with flawed hardware. OTOH, it works fine
and provides near-theoretical maximum performance with standard,
functional hardware operated within specs.

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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.848 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site