Messages in this thread | | | Date | Tue, 28 Jul 1998 17:49:26 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: 2.1.111: IDE DMA disabled? |
| |
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/Config.in 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.
No.
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 sequences.
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.
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
| |