Forgotten to include alsa-devel here..
--- Begin Message ---
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.
I don't know if the kernel creates a new call stack for IRQ
handlers or not. If it does, I don't know how to check what was
previously running on a processor. With the new spinlock debug
stuff, I'll be able to answer this question as well. If so, this
would probably be solved by disabling interrupts...
--
Encrypted replies preferred! http://www.glines.org/pubkey.txt
#!/usr/bin/perl
while($_=shift){if($d==1){$a="$a \"$_\""}else{if(/^-(.+)/){$t
=$1;$i.=$t;if($i=~/-/){$i=~s/-//;$r=shift;$d=1}}else{$r=$_;$d
=1}}}die"Usage: $0 [-ix] [--] regex [paths]\n"if!$r;eval"\$r=
qr/$r/$i";$a='.'if!$a;@F=`find $a -type f`;chomp@F;for $f(@F)
{open(I,$f)or next;while(<I>){print"$f:$.:$_"if/$r/}close(I)}
--- End Message ---
