Date: Thu, 02 Apr 2020 19:23:31 +0000 From: bugzilla-noreply@freebsd.org To: multimedia@FreeBSD.org Subject: [Bug 238587] [hdac] AMD hdac + Realtek codec: occasionally stops working with interrupt mode and needs polling Message-ID: <bug-238587-12827-DD3S6BXHGX@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-238587-12827@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238587 --- Comment #2 from Greg V <greg@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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-238587-12827-DD3S6BXHGX>