Messages in this thread | | | Subject | Re: [PATCH] 2.5.29: some compilation fixes for irq frenzy [OSS + i8x0 audio] | From | Andy Pfiffer <> | Date | 31 Jul 2002 14:50:02 -0700 |
| |
On Tue, 2002-07-30 at 15:47, Alan Cox wrote: > On Tue, 2002-07-30 at 22:19, Andy Pfiffer wrote: > > As luck would have it, I booted the kernel and played the tunes on a > > 2-way P4 Xeon system. Nothing wedged, but then again, I didn't try to > > break it. > > > > So, what did I break? > > SMP support I think. A lot of the save_flags/cli stuff you changed looks > like it needs to also lock out interrupts on the other processors, > otherwise you can get a DMA pointer being updated under you.
After reading the code in question, it appears to me that the existing save_flags/cli constructs are being used to atomically query/modify elements of an audio_devs[N] entry. I can see how it might be possible for the patch to break SMP.
Would a spinlock_t for each "struct audio_operations" be the preferred solution over, say, a global spinlock_t for all "struct audio_operations?"
And while I'm asking: I'm a bit perplexed by the "naked" sti()'s in audio_write() and audio_read() for the case where CNV_MU_LAW conversion is required. The intent appears to be to force interrupts back on during the format conversion. I don't see any corresponding cli() on the return path, however.
Does anyone have any idea why those sti()'s just seem to be stuck there?
Regards, Andy
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |