El Sat, 30 Mar 2024 19:36:52 +0100
Martijn van Duren <openbsd+tech@list.imperialat.at> 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