>hm, if DMA channels are being mucked with from within an IRQ handler, then
>we should spinlock the DMA controller itself. It's only in recent kernels
Yes the soundcard irq handler play with the DMA controller.
>that a cli() in an IRQ handler doesnt lock out other IRQs from doing stuff
>on other CPUs. So if the DMA controller isnt robust enough against a 'mix'
>of commands interleaved from two CPUs going to two different channels,
>then we might have a problem. Eg, in Andrea's fixpatch:
Agreed. It would be nice if somebody would be able to cause problems
running for example two soundcard on a smp machine.
>- 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
Yes! I reproduced the disable_dma() bug also with a silly C M$DOS proggy.
I only need to run disable_dma() get_dma_residue() and enable_dma() at
every SB irq handler and my old mb locked solid.
>look at asm/dma.h shows some nonatomic DMA related functions, wondering
>wether anyone has though about their SMP compatibility. On the other hand
This is sure not the problem of the disable_dma_bug since it happens also
in MSDOG with the only SB running.
>i have an AWE64 myself and Quake runs well too, but havent seen any lockup
>yet. (but this is the only DMA active ISA device here)
I think too that there could be problems with two soundcard for example
on SMP.
If somebody is going to test the DMA code in SMP with two ISA DMA device
running at the same time I suggest to decrease the DMA buffer to increase
the number of irq per sec...
Andrea[s] Arcangeli
-
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