Re: 2.1.111: IDE DMA disabled?

Linus Torvalds (
Tue, 28 Jul 1998 17:49:26 -0700 (PDT)

On Tue, 28 Jul 1998, Mark Lord wrote:
> Duh. Letmesee.. SMP=1 by default.. Mmmm... looks very bad.

I have news for you - 2.2 won't have that. The development kernels have it
because it's my default environment, so it's the easiest for me. For a
release kernel it obviously doesn't make sense.

So for 2.2.0, there will magically appear a '#' marker in the main
Makefile. And if it makes you feel better, I can add the comment marker to
drivers/block/ at that time too, and remove it for the while
being. But I suspect you'd be even more upset by that, right?

> On a constructive note, could there be an SMP cache-sync problem
> with DMA (IDE or SCSI) ?

Yes. According to all Intel docs, cache coherency is done in hardware
(there is not even any working software solution, because a wbinvl
actually causes more bugs than it fixes), and while there are magic things
you have to do to cause "synchronizing" of the CPU core to the caches (not
the caches to each other), one of the magic things is a IO instruction.

So by just reading the IDE status register you'd essentally guarantee that
whatever DMA activity happened earlier will have completed as far as the
CPU is concerned.

> SMP really should be OFF by default,
> especially as SMP kernels do not survive
> booting on many non-SMP machines.

Yes. And it will be.

By the same logic, DMA should be OFF by default.

Do you get my drift now?

> The timings with DMA are *identical* to the timings with PIO,
> so if it fails with DMA, it will fail with PIO as well.


Even if the timings on the actual IDE cable are 100% the same, the timings
will be very different indeed on another level. A DMA access will cause
the memory write directly, possibly with a write-back-and-invalidate
and/or a invalidate from some CPU.

A PIO read will move directly from the IDE controller into the CPU, and
the CPU itself will do all the memory accesses. As such, from the
standpoint of the IDE controller they are two very very different

So yes, if you read the "IDE specs" the timings look the same: X cycles
per access on the IDE cable. But specs and hardware aren't the same thing.

> Removing DMA from the kernel solves nothing there.

I didn't _want_ to remove DMA from the kernel.

I've been asking you to not do DMA by default for a very long time, and
every time I ask I have gotten back a reply saying essentially something
like "if the BIOS set us up for DMA we have to do DMA". Which is obviously
not true.

The only way I could even get you to react to this whole discussion was to
disable DMA completely. Not because I wanted to make it impossible for
people to use DMA, but because I wanted to make it impossible for the
kernel to start using DMA when it shouldn't.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at