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/> References: <bug-238587-12827@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238587 --- Comment #2 from Greg V <greg@unrelenting.technology> --- LOL, just noticed that in polling mode, rapidly clicking a button on the (U= SB) 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 proba= bly doesn't have anything do to with anything.. right? irq71: xhci2 778144 24 irq72: hdac1 172458 5 Also, sometimes toggling back to polling=3D0 just works. Trying to google related things.. apparently Linux automatically (!) switch= es to polling mode https://alsa-devel.alsa-project.narkive.com/ZfY6zFlv/2-6-33-rc3-hda-works-i= n-polling-mode More recent example with the codec I have (ALC892) https://bugzilla.kernel.org/show_bug.cgi?id=3D101501 shows that Linux can a= lso 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-238587-12827-DD3S6BXHGX>