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 |
||
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. Created attachment 173361 [details]
Debug patch
Created attachment 173391 [details]
relevant parts of journalctl -b 0 with debug patch
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. 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? Created attachment 173491 [details]
Test fix patch
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. 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. Created attachment 173521 [details]
Fix patch
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. |
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.