|Summary:||[hdac] AMD hdac + Realtek codec: occasionally stops working with interrupt mode and needs polling|
|Product:||Base System||Reporter:||Greg V <greg>|
|Component:||kern||Assignee:||freebsd-multimedia (Nobody) <multimedia>|
|Severity:||Affects Only Me||CC:||cem, emaste, rhurlin, sigsys|
Description Greg V 2019-06-15 20:30:38 UTC
(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
Comment 1 Conrad Meyer 2019-06-15 20:59:48 UTC
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.
Comment 2 Greg V 2020-04-02 19:23:31 UTC
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.
Comment 3 Andriy Gapon 2020-05-13 06:28:29 UTC
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.
Comment 4 Greg V 2020-07-16 23:22:03 UTC
(In reply to Andriy Gapon from comment #3) Seems like it has helped..
Comment 5 Andriy Gapon 2020-10-13 06:00:59 UTC
Closing as fixed. Let's see if the problem comes back.