On 14/04/10 12:32 AM, Mark Lord wrote:
..
The syslog shows the usual "fallback" messages,
but the audio consisted of very loud static, the kind
of noise one gets when the sample bits are all reversed.
While it was failing, I tried retuning, stopping/starting
the recording, etc.. nothing mattered. It wanted a reload
of the cx18 driver to cure it.
..
Since all of this happens rather randomly,
I'm beginning to more strongly suspect a race condition
somewhere in the driver.
Now, it's a rather large driver -- lots of complexity in that chip
-- so it will take me a while to sort through things.
But at first blush, I don't see any obvious locking around
the various read-modify-write sequences for the audio registers.
And a quick "grep spin *.[ch]" shows a few spin_lock/spin_unlock
calls in cx18-queue.c and cx18-stream.c (as well as the alsa code,
which shouldn't be in play in this scenario).
Oddly, none of those spinlocks use _irq or _irq_save/restore,
which means they aren't providing any sort of mutual exclusion
against the interrupt handler.
But like I said, I'm only just beginning to look more closely now.
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
