Bug 96271

Summary: snd_hda_codec_ca0132: Applications freeze permanently when trying to access the chip
Product: Drivers Reporter: Andreas Reis (andreas.reis)
Component: Sound(ALSA)Assignee: Jaroslav Kysela (perex)
Status: RESOLVED CODE_FIX    
Severity: high CC: tiwai
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: Tiwai for-next Subsystem:
Regression: No Bisected commit-id:
Attachments: relevant dmesg
Debug patch
relevant parts of journalctl -b 0 with debug patch
Test fix patch
Fix patch

Description Andreas Reis 2015-04-07 17:22:21 UTC
Created attachment 173331 [details]
relevant dmesg

Using Tiwai's for-next branch (at ALSA: hda_intel: add AZX_DCAPS_I915_POWERWELL for SKL and BSW) makes anything instantly perma-freeze that tries to use the Creative Core3D (CA0132) chip on my Gigabyte G1.Sniper M5. This also causes systemd to wait infinitely to store the sound card state on shutdown.

4.0-rc7 seems unaffected.

Attached are the relevant parts from dmesg.

Side note: snd_hda_codec_ca0132 has been repeatedly spamming dmesg with "ca0132 DOWNLOAD OK :-) DSP IS RUNNING." whenever it feels like it for months now.
Comment 1 Takashi Iwai 2015-04-07 19:00:42 UTC
Hm, something seems wrong with the runtime PM, then.

Could you try once the patch below and get the log until it gets the 120 sec freeze message?  Note that this may give lots of outputs in kernel log.
Comment 2 Takashi Iwai 2015-04-07 19:01:03 UTC
Created attachment 173361 [details]
Debug patch
Comment 3 Andreas Reis 2015-04-07 19:46:47 UTC
Created attachment 173391 [details]
relevant parts of journalctl -b 0 with debug patch
Comment 4 Andreas Reis 2015-04-07 20:01:21 UTC
alsamixer was called from root on a tty, then I started the xserver as normal user, waited (and restarted the xserver once by accident).

There's two HDMI monitors connected to my motherboard.

Also, full disclosure, I'm actually using drm-intel-nightly (your git is at 4.0-rc5, which still had a bug that prevented me from booting). However, that branch closely tracks your for-next, and thus has all its commits.
Comment 5 Takashi Iwai 2015-04-08 05:55:43 UTC
Thanks.  As long as reading the log, there is no refcount unbalance.  Maybe it's a race of runtime suspend and the power up by alsactl invocation at the same time.

Remove the previous patch and could you try the patch below?
Comment 6 Takashi Iwai 2015-04-08 05:56:12 UTC
Created attachment 173491 [details]
Test fix patch
Comment 7 Andreas Reis 2015-04-08 11:01:37 UTC
Sound works with that, so it seems to fix it. Thanks!

I say "seems" because I noticed that the bug didn't always occur. Sometimes it would work after booting, sometimes it would repeatedly fail.

I haven't been able to figure out the cause of that inconsistency, though naively I'd say it happened when I had plugged in my headphones on the previous boot, and removed them prior (ie, during the uefi phase) to rebooting Linux. Kinda like how I can't use the CA0132's mic-in on Windows if I reboot from Linux, where it doesn't work at all.

Next time I'll buy something that doesn't use a fancy binary blob.

Anyway, I'll test it for a day or two and report again.
Comment 8 Takashi Iwai 2015-04-08 11:50:18 UTC
Good to hear.  The reason you didn't see it always is basically because it's a race between the runtime PM suspend and the concurrent access via alsactl during suspend.

Below is the more official patch I'm going to submit to upstream.  Please use this one istead of further testing.
Comment 9 Takashi Iwai 2015-04-08 11:51:46 UTC
Created attachment 173521 [details]
Fix patch
Comment 10 Andreas Reis 2015-04-19 21:21:04 UTC
Whoops, forgot to update. Haven't had any issues with sound since the patch. I'll change this to fixed, if you don't mind.