[alsa-devel] ALSA: hda - Fix possible races in HDMI driver - lockup on shutdown when radeon.audio=1 after using audacity

[Arthur Marsh]

Takashi Iwai wrote, on 20/01/14 19:22:
> At Sun, 19 Jan 2014 17:32:16 +1030,
> Arthur Marsh wrote:
>>
>> I have had reproducible lock-ups on shut-down (at the shutting down ALSA
>> stage) of my AMD64 machine (Asus M3A78Pro motherboard, BIOS 1701
>> 01/27/2011, CPU AMD Athlon(tm) II X4 640 Processor) running the 64 bit
>> Linux kernel more recent than 3.12 when *both* radeon.audio=1 was set
>> and I had been running audacity 2.0.5. (iommu=noaperture is also set).
>>
>> The problem was reproducible with the stock Debian kernel
>> linux-image-3.13-rc6-amd64 version 3.13~rc6-1~exp1.
>>
>> The machine is using an ATI/AMD 3850HD video card with a DVI cable to a
>> DVI input on my monitor, and the default audio device is the
>> motherboard's on-board audio device:
>>
>> 00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00
>> Azalia (Intel HDA)
>>
>> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
>> [AMD/ATI] RV670 [Radeon HD 3690/3850]
>> 01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] RV670/680
>> HDMI Audio [Radeon HD 3690/3800 Series]
>>
>> $ git bisect bad
>> cbbaa603a03cc46681e24d6b2804b62fde95a2af is the first bad commit
>> commit cbbaa603a03cc46681e24d6b2804b62fde95a2af
>> Author: Takashi Iwai <tiwai at suse.de>
>> Date:   Thu Oct 17 18:03:24 2013 +0200
>>
>>       ALSA: hda - Fix possible races in HDMI driver
>>
>>       Some per_pin fields and ELD contents might be changed dynamically in
>>       multiple ways where the concurrent accesses are still opened in the
>>       current code.  This patch fixes such possible races by using eld->lock
>>       in appropriate places.
>>
>>       Reported-by: Anssi Hannula <anssi.hannula at iki.fi>
>>       Signed-off-by: Takashi Iwai <tiwai at suse.de>
>>
>> :040000 040000 0c29281f82a3ebd9a704d481114f9cfcefea07c8
>> d71fd101125cd29a628cb5e66c7ee4f56e28329b M      sound
>>
>> When running audacity from the command line there was the following output:
>>
>> ALSA lib pcm_dsnoop.c:618:(snd_pcm_dsnoop_open) unable to open slave
>> ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave
>> ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
>> ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
>> ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
>> ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave
>> Expression 'stream->playback.pcm' failed in
>> 'src/hostapi/alsa/pa_linux_alsa.c', line: 4611
>> Expression 'stream->playback.pcm' failed in
>> 'src/hostapi/alsa/pa_linux_alsa.c', line: 4611
>> Expression 'stream->playback.pcm' failed in
>> 'src/hostapi/alsa/pa_linux_alsa.c', line: 4611
>>
>> I am happy to supply further information or run further tests to help in
>> isolating the problem and verifying a solution.
>
> Could you build the kernel with lockdep kconfig and see whether it
> reports errors?
>
> Reverting the commit doesn't work cleanly.  Instead, you can try to
> simply comment out all mutex_lock(&per_pin->lock) and
> mutex_unlock(&per_pin->lock) calls in patch_hdmi.c to see whether it's
> a mutex deadlock.
>
>
> thanks,
>
> Takashi
>

I rebuilt the kernel after commenting out all mutex_lock(&per_pin->lock) 
and mutex_unlock(&per_pin->lock) calls in patch_hdmi.c, and the 
resulting kernel shutdown without hanging.

Regards,

Arthur.