Hi Mark, (now Cc'ed to alsa-devel for better debugging environment)
At Mon, 12 Nov 2001 22:34:27 -0800, Mark Glines wrote: > > snd_pcm_period_elapsed() hangs the machine trying to get a lock on > substream->runtime->lock, which when called from snd_m3_update_ptr() > from an IRQ, seems to already be held (sometimes, at least). The > result is a dead machine, or at least some poking around in KDB to > manually reset locks. > > I've only seen this happen during periods of heavy disk IO. I don't know > how much that has to do with it, but its hung my box 3 times today, all of > which were during periods of extremely heavy disk activity. > > What follows is a KDB backtrace of the hung CPU. If you need, I can > spend a few hours this weekend and figure out where the lock is already > being held at the crucial moment. Are you already aware of this problem? > Is there any more info I can provide? 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. > > EBP EIP Function(args) > 0xe0c7306b [snd-pcm].text.lock+0x24b > snd-pcm .text.lock 0xe0c72e20 0xe0c72e20 0xe0c73c > 0xdb580ca4 0xe0c71004 [snd-pcm]snd_pcm_period_elapsed+0x54 (0xc18d79cc) > snd-pcm .text 0xe0c68060 0xe0c70fb0 0xe0c710e0 > 0xe0c7bc0e [snd-card-maestro3]snd_m3_update_ptr+0x9e (0xdb784614, 0x) > snd-card-maestro3 .text 0xe0c7b060 0xe0c7bb70 0x0 > 0xe0c7bd22 [snd-card-maestro3]snd_m3_interrupt+0xc2 (0xb, 0xdb784614) > snd-card-maestro3 .text 0xe0c7b060 0xe0c7bc60 0x0 > 0xc0109513 handle_IRQ_event+0x53 (0xb, 0xd83a3f1c, 0xdb7f0c64) > kernel .text 0xc0100000 0xc01094c0 0xc0109550 > 0xd83a3f14 0xc010984d do_IRQ+0x10d (0xc03e7fc0, 0x0, 0xc03c5154, 0xc18b1ce4, 0x) > kernel .text 0xc0100000 0xc0109740 0xc0109910 > 0xd83a3f6c 0xc026a580 call_do_IRQ+0x5 (0xe, 0xc18b1ce4, 0xd83a3fc4) > kernel .rodata 0xc0268340 0xc026a57b 0xc026a588 > 0xc0109513 handle_IRQ_event+0x53 (0xe, 0xd83a3fc4, 0xc18f7304) > kernel .text 0xc0100000 0xc01094c0 0xc0109550 > 0xd83a3fbc 0xc010984d do_IRQ+0x10d > kernel .text 0xc0100000 0xc0109740 0xc0109910 > 0xc026a580 call_do_IRQ+0x5 > kernel .rodata 0xc0268340 0xc026a57b 0xc026a588 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.. Takashi _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
