From: Jose Maldonado Subject: Re: AMD 17h/1xh HD Audio testers wanted! To: tech@openbsd.org Date: Sun, 31 Mar 2024 19:39:01 -0400 El Sat, 30 Mar 2024 19:36:52 +0100 Martijn van Duren escribió: > On Sun, 2023-03-05 at 08:53 +0100, Alexandre Ratchov wrote: > > If you've an azalia(4) attaching as "AMD 17h/1xh HD Audio", please > > test this diff and report regressions. Especially audio lock ups > > that require reboot. > > > > IIRC, MSI was disabled few years ago to "fix" such lockups, and now > > this diff suggests we need MSI on certain boards. > > > I recently bought a new computer which has this card that requires MSI > and usually locks up in between 5m and 1h. Because of these fast > hangs I managed to try a couple of things and the diff below > (definitely not intended for commit) allows me to simply restart my > application and the audio continues. It can also happen that I get a > couple of stutters before it continues without issues (until the next > moment). > > This behaviour is similar to the azalia driver on my laptop: > azalia0 at pci0 dev 31 function 3 "Intel 500 Series HD Audio" rev > 0x20: msi Which also once in a blue moon hangs the audio and I need > to restart my player (ogg123, I haven't noticed anything with other > audio utilising applications). > > This makes me believe that there's some issue in the azalia driver in > general when it comes to receiving MSI interrupts, with the difference > that the AMD 17h/1xh needs to have some state reset as performed by > azalia_intr(), where my Intel does not (and my AMD triggers a whole > lot faster) > > I'm not sure where to go from here though. Is there anyone who has an > idea what a good next debug step would be? Do we want to work towards > a hack where we simply add some additional cleanup steps once we > detect the driver hang? > > martijn@ > In my case this patch is a great advance. Generally, my audio freezes after ~90 minutes of playback causing me to have to restart, but with the patch it took ~200 minutes for the first error to occur. In this case, the error is a momentary stuck and the audio then continued working as if nothing had happened, I didn't have to touch anything or restart sndiod. In the dmesg (compile the kernel with AUDIO_DEBUG and AZALIA_DEBUG) I could see this during the audio failure: azalia_stream_intr: stream 1: hwpos 26880, 13 intrs azalia_stream_intr: stream 2: hwpos 3840, 12 intrs azalia_stream_intr: stream 1: hwpos 3840, 11 intrs azalia_stream_intr: stream 2: hwpos 0, 8 intrs audio0: stopped audio0: drain: mode = 3, pause = 1, active = 0, used = 0 audio0: close: done audio_mixer_close: flags = 0x7 Then I see the following section and the audio is still working correctly: audio0: setpar: req enc=6 bits=16, bps=2, msb=1 rate=48000, pchan=2, rchan=2, round=480, nblks=16 audio0: block size set to: 480 audio0: play nblks -> 16 audio0: rec nblks -> 34 audio0: setpar: new enc=6 bits=16, bps=2, msb=1 rate=48000, pchan=2, rchan=2, round=480, nblks=16 audio_mixer_open: flags = 0x10007 -- ********************************************************* Dios en su cielo, todo bien en la Tierra