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

[Takashi Iwai <tiwai@suse.de>]

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@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@iki.fi>
>      Signed-off-by: Takashi Iwai <tiwai@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