> > of commands interleaved from two CPUs going to two different channels,
> > then we might have a problem. Eg, in Andrea's fixpatch:
> >
> > - disable_dma(dmap->dma);
> > pos = dmap->bytes_in_use - get_dma_residue(chan);
> > - enable_dma(dmap->dma);
> >
> > i'm not sure though wether this is really done from IRQ handlers. A quick
>
> It isnt in the sound case. It also doesnt affect different DMA channels
> being mixed together. So Im puzzled.
[i'm only thinking those SMP problems for now. The VIA thing might be a
different, probably hardware bug]
it's not necessarily the sound drivers. Eg. a quick look to the drivers
directory shows that ltpc.c uses these DMA functions from within IRQ
handlers. Also, are global interrupts disabled at this point in the sound
code?
the danger situation which i cannot really prove but i suspect it might
exist:
CPU0 CPU2
inb DMA1
outb DMA2
inb DMA0
inb DMA2
so those two, supposedly atomic functions are getting to the DMA
controller in a 'mixed up' way because of SMP. (for similar reasons do we
spinlock-protect IRQ controllers and APICs too)
-- mingo
-
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.tux.org/lkml/faq.html