I also am running a SMP system. I also have lockups quite frequently but have not yet found the cause. If you'd like me to run any tests on my own system to help, let me know. My stats are: kernel 2.4.12-3mdk SMP, alsa 0.9.0beta9. If CONFIG_DEBUG_SPINLOCK is disabled by default, mine is disabled. Same goes for KDB patch...
Cheers, Tom > > > On Tue, Nov 13, 2001 at 04:10:18PM +0100, Takashi Iwai wrote: > > >>I was not aware of this problem. >> >>We need to know on which part, maestro3 or pcm core, this problem >>lies. As far as I looked into the code, the locking in >>snd_pcm_period_elapsed should be ok, though. Possibly >>spinlock-debug-enabled kernel would help to point out where the >>deadlock occurs. >> > > I am running 2.4.13 with CONFIG_DEBUG_SPINLOCK enabled, KDB patch > applied and that enabled too, SMP kernel on a dual system. The > spinlock debugging currently in the kernel doesn't help. I plan to > hack include/linux/spinlock.h to store __LINE__ and a pointer to > __BASE_FILE__ of the calling code, but I need to set aside a couple > hours to do this, and this work week is hectic, so it'll probably > have to wait until the weekend. I'll send you more info as I get > it. > > >>Hmm, the codepath looks very simple. >>Is it possible that interrupts collide twice? >>The m3 interrupt routine sends ack to intr ioport as soon as its >>entrance. Not sure whether this causes the problem.. >> > > The backtraces for the affected processor are basically identical. > During one hang, the other CPU was stuck in the scheduler. Another > time, it was stuck in some read() call from a userspace program. _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
