Bug 238587 - [hdac] AMD hdac + Realtek codec: occasionally stops working with interrupt mode and needs polling
Summary: [hdac] AMD hdac + Realtek codec: occasionally stops working with interrupt mo...
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-multimedia (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-15 20:30 UTC by Greg V
Modified: 2020-10-13 06:00 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 freebsd_committer 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 freebsd_committer 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 freebsd_committer 2020-10-13 06:00:59 UTC
Closing as fixed. Let's see if the problem comes back.