Alsa deadlock fix (was Re: 2.6-test8 : alsa hangs my box)
I am seeing this hang also, on a different card, whenever a native alsa and an OSS-emulation app collide. No nVidia stuff this time, and not snd_intel8x0 either, this is w/ a via82xx motherboard's integrated sound. From what little one can tell from the sysrq-T backtrace, it looks like a classic deadlock (both tasks stick in down(), probably on different mutexes).
It also looks like it has alreay been fixed (in alsa 0.9.7b) - I think the kernel's alsa is approximately equivalent to 0.9.6 these days? So, it looks like either some work to port that patch or a wholesale merge of alsa 0.9.8 would be good before 2.6.0... probably the former given Linus's strongly-worded comments with -test9 :-)
But a deadlock that results in two unkillable state 'D' processes whenever you an OSS and an alsa-native app access the soundcard at the same time, which happens on both VIA and Intel integrated sound, seems like a hang which might meet his criteria of problems which "causes lockups or just basic
nonworkingness: and this happens on hardware that normal people are expected to have". So I figured it's worth asking if someone who already knows what the fix consisted of could push it toward Linus ...
Re: Alsa deadlock fix
Quoted 8 lines · Kevin Puetz
But a deadlock that results in two unkillable state 'D' processes whenever you an OSS and an alsa-native app access the soundcard at the same time, which happens on both VIA and Intel integrated sound, seems like a hang which might meet his criteria of problems which "causes lockups or just basic nonworkingness: and this happens on hardware that normal people are expected to have". So I figured it's worth asking if someone who already knows what the fix consisted of could push it toward Linus ...
It's fixed in -test9.
Signature · 2 lines
Måns Rullgård [email protected]
Re: Alsa deadlock fix
Quoted 11 lines · Måns Rullgård
Quoted 8 lines · Kevin Puetz
But a deadlock that results in two unkillable state 'D' processes whenever you an OSS and an alsa-native app access the soundcard at the same time, which happens on both VIA and Intel integrated sound, seems like a hang which might meet his criteria of problems which "causes lockups or just basic nonworkingness: and this happens on hardware that normal people are expected to have". So I figured it's worth asking if someone who already knows what the fix consisted of could push it toward Linus ...
Quoted 2 lines
It's fixed in -test9.
Thanks, sorry about the bogus report then. I looked at the -test8 -> -test9 changes before I sent it, but missed it since it was from akpm (not jaroslav) and didn't mention alsa in the changelog message. Thus it missed both categories I thought to search for in the applied changes :-P