[Bug 238587] [hdac] AMD hdac + Realtek codec: occasionally stops working with interrupt mode and needs polling

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238587

--- Comment #2 from Greg V <greg at unrelenting.technology> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.