(Ryzen 1st gen on an MSI X370 SLI PLUS)
hdac1: <AMD (0x1457) HDA Controller> mem 0xfcf00000-0xfcf07fff irq 43 at device 0.3 on pci14
hdacc1: <Realtek ALC892 HDA CODEC> at cad 0 on hdac1
hdaa1: <Realtek ALC892 Audio Function Group> at nid 1 on hdacc1
pcm6: <Realtek ALC892 (Rear Analog 7.1/2.0)> at nid 20,22,21,23 and 24,26 on hdaa1
pcm7: <Realtek ALC892 (Front Analog)> at nid 27 and 25 on hdaa1
Occasionally (not very often, sometimes it's like, a week without this)
- the sound stops working (playback starts stuttering on the same sample and the progress in the music/video player stops going forward)
- I don't think any messages are logged (I'll recheck next time it happens)
- sysctl dev.hdac.1.polling=1 fixes the problem and playback resumes fine
I've observed similar symptoms very occasionally also (1st gen Zen Threadripper, X399 board). In my instances, it's hdac0 rather than hdac1; and "devctl disable -f hdac0 ; devctl enable hdac0" resolves the issue.
LOL, just noticed that in polling mode, rapidly clicking a button on the (USB) mouse slows the music down. (both with the stock ums driver and iichid's usbhid+hms)
IRQs of the hdac and one of the xhcis are next to each other but that probably doesn't have anything do to with anything.. right?
irq71: xhci2 778144 24
irq72: hdac1 172458 5
Also, sometimes toggling back to polling=0 just works.
Trying to google related things.. apparently Linux automatically (!) switches to polling mode https://alsa-devel.alsa-project.narkive.com/ZfY6zFlv/2-6-33-rc3-hda-works-in-polling-mode
More recent example with the codec I have (ALC892) https://bugzilla.kernel.org/show_bug.cgi?id=101501 shows that Linux can also auto disable MSI o_0
And Linux forces polling mode on Intel Coffee Lake: https://lore.kernel.org/patchwork/patch/892159/ saying that polling mode is not too bad. Well, on FreeBSD it causes this funny mouse thing for me.
So I guess there's no "real fix" for drivers, the hardware is just crap (as usual with Realtek) and all we can do is auto-reset and/or auto-fallback-to-polling.
Could you please check base r361001 ?
I did not associate that commit with this report, because I am not 100% sure that it would help. But I think that there is a pretty good chance that it does.
(In reply to Andriy Gapon from comment #3)
Seems like it has helped..
Closing as fixed. Let's see if the problem comes back.