* [PATCH] ALSA: hda/core: Log stream DMA errors on interrupt @ 2026-08-03 22:07 Arun Raghavan 2026-08-04 11:21 ` Takashi Iwai 0 siblings, 1 reply; 6+ messages in thread From: Arun Raghavan @ 2026-08-03 22:07 UTC (permalink / raw) To: Jaroslav Kysela, Takashi Iwai Cc: linux-sound, linux-kernel, Arun Raghavan, Arun Raghavan The stream descriptor status register reports FIFO and descriptor errors, but these are currently cleared silently along with the rest of the interrupt status. Log them, rate-limited, so DMA problems are visible instead of only manifesting as audible glitches. Observed on some AMD GPU HDMI audio controllers under specific low power circumstances. Signed-off-by: Arun Raghavan <arunr@valvesoftware.com> Cc: Arun Raghavan <arun@arunraghavan.net> --- sound/hda/core/controller.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/sound/hda/core/controller.c b/sound/hda/core/controller.c index 69e11d62bbfa..5f1d2c132cec 100644 --- a/sound/hda/core/controller.c +++ b/sound/hda/core/controller.c @@ -682,6 +682,11 @@ int snd_hdac_bus_handle_stream_irq(struct hdac_bus *bus, unsigned int status, sd_status = snd_hdac_stream_readb(azx_dev, SD_STS); snd_hdac_stream_writeb(azx_dev, SD_STS, SD_INT_MASK); handled |= 1 << azx_dev->index; + if (sd_status & (SD_INT_FIFO_ERR | SD_INT_DESC_ERR)) { + dev_warn_ratelimited(bus->dev, + "stream %u dma error: 0x%02x\n", + azx_dev->index, sd_status); + } if ((!azx_dev->substream && !azx_dev->cstream) || !azx_dev->running || !(sd_status & SD_INT_COMPLETE)) continue; --- base-commit: 848acc8ffe1b7cd5f1bf427b93069becfebc2c9d change-id: 20260803-master-48a36c6e70e0 Best regards, -- Arun Raghavan <arunr@valvesoftware.com> ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] ALSA: hda/core: Log stream DMA errors on interrupt 2026-08-03 22:07 [PATCH] ALSA: hda/core: Log stream DMA errors on interrupt Arun Raghavan @ 2026-08-04 11:21 ` Takashi Iwai 2026-08-04 17:42 ` [External Mail] " Arun Raghavan 0 siblings, 1 reply; 6+ messages in thread From: Takashi Iwai @ 2026-08-04 11:21 UTC (permalink / raw) To: Arun Raghavan Cc: Jaroslav Kysela, Takashi Iwai, linux-sound, linux-kernel, Arun Raghavan On Tue, 04 Aug 2026 00:07:52 +0200, Arun Raghavan wrote: > > The stream descriptor status register reports FIFO and descriptor > errors, but these are currently cleared silently along with the rest > of the interrupt status. Log them, rate-limited, so DMA problems are > visible instead of only manifesting as audible glitches. > > Observed on some AMD GPU HDMI audio controllers under specific low power > circumstances. > > Signed-off-by: Arun Raghavan <arunr@valvesoftware.com> > Cc: Arun Raghavan <arun@arunraghavan.net> Applied now to for-next branch. It's interesting at which situation you get the error bit and which one. If it can be used *reliably* for catching a streaming error, the driver could notify XRUN or error appropriately, too. thanks, Takashi ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [External Mail] Re: [PATCH] ALSA: hda/core: Log stream DMA errors on interrupt 2026-08-04 11:21 ` Takashi Iwai @ 2026-08-04 17:42 ` Arun Raghavan 2026-08-04 18:18 ` Takashi Iwai 0 siblings, 1 reply; 6+ messages in thread From: Arun Raghavan @ 2026-08-04 17:42 UTC (permalink / raw) To: Takashi Iwai, Arun Raghavan Cc: Jaroslav Kysela, Takashi Iwai, linux-sound, linux-kernel, Arun Raghavan On Tue Aug 4, 2026 at 4:21 AM PDT, Takashi Iwai wrote: > On Tue, 04 Aug 2026 00:07:52 +0200, > Arun Raghavan wrote: >> >> The stream descriptor status register reports FIFO and descriptor >> errors, but these are currently cleared silently along with the rest >> of the interrupt status. Log them, rate-limited, so DMA problems are >> visible instead of only manifesting as audible glitches. >> >> Observed on some AMD GPU HDMI audio controllers under specific low power >> circumstances. >> >> Signed-off-by: Arun Raghavan <arunr@valvesoftware.com> >> Cc: Arun Raghavan <arun@arunraghavan.net> > > Applied now to for-next branch. > > It's interesting at which situation you get the error bit and which > one. If it can be used *reliably* for catching a streaming error, the > driver could notify XRUN or error appropriately, too. Ah, I should have mentioned that in the commit message. The error bit that was signalled was SD_INT_FIFO_ERR -- the status byte was read as (SD_STS_FIFO_READY | SD_INT_FIFO_ERR). We are still working on pinning down the precise cause in this case, but it seems to be related to issues in some specific setups during lower frequency memory clock transitions. The error manifests as a short dropout caused by what appears to be a stall or missed transfer. The frequency of dropouts varies from several per minute to one every few minutes. In such a case, the existence of XRUNs might be good to know further up the stack, though it isn't clear that there is much that userspace can autonomously do to mitigate the it. Cheers, Arun ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [External Mail] Re: [PATCH] ALSA: hda/core: Log stream DMA errors on interrupt 2026-08-04 17:42 ` [External Mail] " Arun Raghavan @ 2026-08-04 18:18 ` Takashi Iwai 2026-08-05 20:56 ` Arun Raghavan 0 siblings, 1 reply; 6+ messages in thread From: Takashi Iwai @ 2026-08-04 18:18 UTC (permalink / raw) To: Arun Raghavan Cc: Takashi Iwai, Jaroslav Kysela, Takashi Iwai, linux-sound, linux-kernel, Arun Raghavan On Tue, 04 Aug 2026 19:42:17 +0200, Arun Raghavan wrote: > > On Tue Aug 4, 2026 at 4:21 AM PDT, Takashi Iwai wrote: > > On Tue, 04 Aug 2026 00:07:52 +0200, > > Arun Raghavan wrote: > >> > >> The stream descriptor status register reports FIFO and descriptor > >> errors, but these are currently cleared silently along with the rest > >> of the interrupt status. Log them, rate-limited, so DMA problems are > >> visible instead of only manifesting as audible glitches. > >> > >> Observed on some AMD GPU HDMI audio controllers under specific low power > >> circumstances. > >> > >> Signed-off-by: Arun Raghavan <arunr@valvesoftware.com> > >> Cc: Arun Raghavan <arun@arunraghavan.net> > > > > Applied now to for-next branch. > > > > It's interesting at which situation you get the error bit and which > > one. If it can be used *reliably* for catching a streaming error, the > > driver could notify XRUN or error appropriately, too. > > Ah, I should have mentioned that in the commit message. The error bit > that was signalled was SD_INT_FIFO_ERR -- the status byte was read as > (SD_STS_FIFO_READY | SD_INT_FIFO_ERR). > > We are still working on pinning down the precise cause in this case, but > it seems to be related to issues in some specific setups during lower > frequency memory clock transitions. The error manifests as a short > dropout caused by what appears to be a stall or missed transfer. The > frequency of dropouts varies from several per minute to one every few > minutes. > > In such a case, the existence of XRUNs might be good to know further up > the stack, though it isn't clear that there is much that userspace can > autonomously do to mitigate the it. When we do stop the stream as XRUN and notifies to user-space, usually it tries to recover / restart -- something like below. But it's hard to judge whether we should do this, or it can lead rather to misbehavior. We need experiments. thanks, Takashi -- 8< -- diff --git a/include/sound/hdaudio.h b/include/sound/hdaudio.h index aa994d6e6d35..615e48ecb009 100644 --- a/include/sound/hdaudio.h +++ b/include/sound/hdaudio.h @@ -412,7 +412,9 @@ void snd_hdac_bus_link_power(struct hdac_device *hdev, bool enable); void snd_hdac_bus_update_rirb(struct hdac_bus *bus); int snd_hdac_bus_handle_stream_irq(struct hdac_bus *bus, unsigned int status, void (*ack)(struct hdac_bus *, - struct hdac_stream *)); + struct hdac_stream *), + void (*error)(struct hdac_bus *, + struct hdac_stream *)); int snd_hdac_bus_alloc_stream_pages(struct hdac_bus *bus); void snd_hdac_bus_free_stream_pages(struct hdac_bus *bus); diff --git a/sound/hda/common/controller.c b/sound/hda/common/controller.c index afec5c5546ec..329854c9fe92 100644 --- a/sound/hda/common/controller.c +++ b/sound/hda/common/controller.c @@ -1058,6 +1058,15 @@ static void stream_update(struct hdac_bus *bus, struct hdac_stream *s) } } +static void stream_error(struct hdac_bus *bus, struct hdac_stream *s) +{ + struct azx_dev *azx_dev = stream_to_azx_dev(s); + + spin_unlock(&bus->reg_lock); + snd_pcm_stop_xrun(azx_stream(azx_dev)->substream); + spin_lock(&bus->reg_lock); +} + irqreturn_t azx_interrupt(int irq, void *dev_id) { struct azx *chip = dev_id; @@ -1082,7 +1091,8 @@ irqreturn_t azx_interrupt(int irq, void *dev_id) handled = true; active = false; - if (snd_hdac_bus_handle_stream_irq(bus, status, stream_update)) + if (snd_hdac_bus_handle_stream_irq(bus, status, stream_update, + stream_error)) active = true; status = azx_readb(chip, RIRBSTS); diff --git a/sound/hda/core/controller.c b/sound/hda/core/controller.c index 78855ac357c6..67bb74c618bf 100644 --- a/sound/hda/core/controller.c +++ b/sound/hda/core/controller.c @@ -676,8 +676,10 @@ EXPORT_SYMBOL_GPL(snd_hdac_bus_stop_chip); * Returns the bits of handled streams, or zero if no stream is handled. */ int snd_hdac_bus_handle_stream_irq(struct hdac_bus *bus, unsigned int status, - void (*ack)(struct hdac_bus *, - struct hdac_stream *)) + void (*ack)(struct hdac_bus *, + struct hdac_stream *), + void (*error)(struct hdac_bus *, + struct hdac_stream *)) { struct hdac_stream *azx_dev; u8 sd_status; @@ -692,6 +694,8 @@ int snd_hdac_bus_handle_stream_irq(struct hdac_bus *bus, unsigned int status, dev_warn_ratelimited(bus->dev, "stream %u dma error: 0x%02x\n", azx_dev->index, sd_status); + if (error) + error(bus, azx_dev); } if ((!azx_dev->substream && !azx_dev->cstream) || !azx_dev->running || !(sd_status & SD_INT_COMPLETE)) diff --git a/sound/soc/intel/avs/core.c b/sound/soc/intel/avs/core.c index 1a53856c2ffb..6a5a6e526c2c 100644 --- a/sound/soc/intel/avs/core.c +++ b/sound/soc/intel/avs/core.c @@ -270,7 +270,8 @@ static irqreturn_t avs_hda_interrupt(struct hdac_bus *bus) u32 status; status = snd_hdac_chip_readl(bus, INTSTS); - if (snd_hdac_bus_handle_stream_irq(bus, status, hdac_update_stream)) + if (snd_hdac_bus_handle_stream_irq(bus, status, hdac_update_stream, + NULL)) ret = IRQ_HANDLED; spin_lock_irq(&bus->reg_lock); ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [External Mail] Re: [PATCH] ALSA: hda/core: Log stream DMA errors on interrupt 2026-08-04 18:18 ` Takashi Iwai @ 2026-08-05 20:56 ` Arun Raghavan 2026-08-06 6:30 ` Takashi Iwai 0 siblings, 1 reply; 6+ messages in thread From: Arun Raghavan @ 2026-08-05 20:56 UTC (permalink / raw) To: Takashi Iwai, Arun Raghavan Cc: Jaroslav Kysela, Takashi Iwai, linux-sound, linux-kernel, Arun Raghavan On Tue Aug 4, 2026 at 11:18 AM PDT, Takashi Iwai wrote: > On Tue, 04 Aug 2026 19:42:17 +0200, > Arun Raghavan wrote: >> >> On Tue Aug 4, 2026 at 4:21 AM PDT, Takashi Iwai wrote: >> > On Tue, 04 Aug 2026 00:07:52 +0200, >> > Arun Raghavan wrote: >> >> >> >> The stream descriptor status register reports FIFO and descriptor >> >> errors, but these are currently cleared silently along with the rest >> >> of the interrupt status. Log them, rate-limited, so DMA problems are >> >> visible instead of only manifesting as audible glitches. >> >> >> >> Observed on some AMD GPU HDMI audio controllers under specific low power >> >> circumstances. >> >> >> >> Signed-off-by: Arun Raghavan <arunr@valvesoftware.com> >> >> Cc: Arun Raghavan <arun@arunraghavan.net> >> > >> > Applied now to for-next branch. >> > >> > It's interesting at which situation you get the error bit and which >> > one. If it can be used *reliably* for catching a streaming error, the >> > driver could notify XRUN or error appropriately, too. >> >> Ah, I should have mentioned that in the commit message. The error bit >> that was signalled was SD_INT_FIFO_ERR -- the status byte was read as >> (SD_STS_FIFO_READY | SD_INT_FIFO_ERR). >> >> We are still working on pinning down the precise cause in this case, but >> it seems to be related to issues in some specific setups during lower >> frequency memory clock transitions. The error manifests as a short >> dropout caused by what appears to be a stall or missed transfer. The >> frequency of dropouts varies from several per minute to one every few >> minutes. >> >> In such a case, the existence of XRUNs might be good to know further up >> the stack, though it isn't clear that there is much that userspace can >> autonomously do to mitigate the it. > > When we do stop the stream as XRUN and notifies to user-space, usually > it tries to recover / restart -- something like below. > > But it's hard to judge whether we should do this, or it can lead > rather to misbehavior. We need experiments. > > > thanks, > > Takashi > > -- 8< -- > diff --git a/include/sound/hdaudio.h b/include/sound/hdaudio.h > index aa994d6e6d35..615e48ecb009 100644 > --- a/include/sound/hdaudio.h > +++ b/include/sound/hdaudio.h > @@ -412,7 +412,9 @@ void snd_hdac_bus_link_power(struct hdac_device *hdev, bool enable); > void snd_hdac_bus_update_rirb(struct hdac_bus *bus); > int snd_hdac_bus_handle_stream_irq(struct hdac_bus *bus, unsigned int status, > void (*ack)(struct hdac_bus *, > - struct hdac_stream *)); > + struct hdac_stream *), > + void (*error)(struct hdac_bus *, > + struct hdac_stream *)); > > int snd_hdac_bus_alloc_stream_pages(struct hdac_bus *bus); > void snd_hdac_bus_free_stream_pages(struct hdac_bus *bus); > diff --git a/sound/hda/common/controller.c b/sound/hda/common/controller.c > index afec5c5546ec..329854c9fe92 100644 > --- a/sound/hda/common/controller.c > +++ b/sound/hda/common/controller.c > @@ -1058,6 +1058,15 @@ static void stream_update(struct hdac_bus *bus, struct hdac_stream *s) > } > } > > +static void stream_error(struct hdac_bus *bus, struct hdac_stream *s) > +{ > + struct azx_dev *azx_dev = stream_to_azx_dev(s); > + > + spin_unlock(&bus->reg_lock); > + snd_pcm_stop_xrun(azx_stream(azx_dev)->substream); > + spin_lock(&bus->reg_lock); > +} > + > irqreturn_t azx_interrupt(int irq, void *dev_id) > { > struct azx *chip = dev_id; > @@ -1082,7 +1091,8 @@ irqreturn_t azx_interrupt(int irq, void *dev_id) > > handled = true; > active = false; > - if (snd_hdac_bus_handle_stream_irq(bus, status, stream_update)) > + if (snd_hdac_bus_handle_stream_irq(bus, status, stream_update, > + stream_error)) > active = true; > > status = azx_readb(chip, RIRBSTS); > diff --git a/sound/hda/core/controller.c b/sound/hda/core/controller.c > index 78855ac357c6..67bb74c618bf 100644 > --- a/sound/hda/core/controller.c > +++ b/sound/hda/core/controller.c > @@ -676,8 +676,10 @@ EXPORT_SYMBOL_GPL(snd_hdac_bus_stop_chip); > * Returns the bits of handled streams, or zero if no stream is handled. > */ > int snd_hdac_bus_handle_stream_irq(struct hdac_bus *bus, unsigned int status, > - void (*ack)(struct hdac_bus *, > - struct hdac_stream *)) > + void (*ack)(struct hdac_bus *, > + struct hdac_stream *), > + void (*error)(struct hdac_bus *, > + struct hdac_stream *)) > { > struct hdac_stream *azx_dev; > u8 sd_status; > @@ -692,6 +694,8 @@ int snd_hdac_bus_handle_stream_irq(struct hdac_bus *bus, unsigned int status, > dev_warn_ratelimited(bus->dev, > "stream %u dma error: 0x%02x\n", > azx_dev->index, sd_status); > + if (error) > + error(bus, azx_dev); > } > if ((!azx_dev->substream && !azx_dev->cstream) || > !azx_dev->running || !(sd_status & SD_INT_COMPLETE)) > diff --git a/sound/soc/intel/avs/core.c b/sound/soc/intel/avs/core.c > index 1a53856c2ffb..6a5a6e526c2c 100644 > --- a/sound/soc/intel/avs/core.c > +++ b/sound/soc/intel/avs/core.c > @@ -270,7 +270,8 @@ static irqreturn_t avs_hda_interrupt(struct hdac_bus *bus) > u32 status; > > status = snd_hdac_chip_readl(bus, INTSTS); > - if (snd_hdac_bus_handle_stream_irq(bus, status, hdac_update_stream)) > + if (snd_hdac_bus_handle_stream_irq(bus, status, hdac_update_stream, > + NULL)) > ret = IRQ_HANDLED; > > spin_lock_irq(&bus->reg_lock); This did work to surface the errors to userspace as XRUNs. Of course, because this is an actual error in the transfer between the CPU and controller, it does not help mitigate the actual problem itself. Thanks! Arun ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [External Mail] Re: [PATCH] ALSA: hda/core: Log stream DMA errors on interrupt 2026-08-05 20:56 ` Arun Raghavan @ 2026-08-06 6:30 ` Takashi Iwai 0 siblings, 0 replies; 6+ messages in thread From: Takashi Iwai @ 2026-08-06 6:30 UTC (permalink / raw) To: Arun Raghavan Cc: Takashi Iwai, Jaroslav Kysela, Takashi Iwai, linux-sound, linux-kernel, Arun Raghavan On Wed, 05 Aug 2026 22:56:40 +0200, Arun Raghavan wrote: > > On Tue Aug 4, 2026 at 11:18 AM PDT, Takashi Iwai wrote: > > On Tue, 04 Aug 2026 19:42:17 +0200, > > Arun Raghavan wrote: > >> > >> On Tue Aug 4, 2026 at 4:21 AM PDT, Takashi Iwai wrote: > >> > On Tue, 04 Aug 2026 00:07:52 +0200, > >> > Arun Raghavan wrote: > >> >> > >> >> The stream descriptor status register reports FIFO and descriptor > >> >> errors, but these are currently cleared silently along with the rest > >> >> of the interrupt status. Log them, rate-limited, so DMA problems are > >> >> visible instead of only manifesting as audible glitches. > >> >> > >> >> Observed on some AMD GPU HDMI audio controllers under specific low power > >> >> circumstances. > >> >> > >> >> Signed-off-by: Arun Raghavan <arunr@valvesoftware.com> > >> >> Cc: Arun Raghavan <arun@arunraghavan.net> > >> > > >> > Applied now to for-next branch. > >> > > >> > It's interesting at which situation you get the error bit and which > >> > one. If it can be used *reliably* for catching a streaming error, the > >> > driver could notify XRUN or error appropriately, too. > >> > >> Ah, I should have mentioned that in the commit message. The error bit > >> that was signalled was SD_INT_FIFO_ERR -- the status byte was read as > >> (SD_STS_FIFO_READY | SD_INT_FIFO_ERR). > >> > >> We are still working on pinning down the precise cause in this case, but > >> it seems to be related to issues in some specific setups during lower > >> frequency memory clock transitions. The error manifests as a short > >> dropout caused by what appears to be a stall or missed transfer. The > >> frequency of dropouts varies from several per minute to one every few > >> minutes. > >> > >> In such a case, the existence of XRUNs might be good to know further up > >> the stack, though it isn't clear that there is much that userspace can > >> autonomously do to mitigate the it. > > > > When we do stop the stream as XRUN and notifies to user-space, usually > > it tries to recover / restart -- something like below. > > > > But it's hard to judge whether we should do this, or it can lead > > rather to misbehavior. We need experiments. > > > > > > thanks, > > > > Takashi > > > > -- 8< -- > > diff --git a/include/sound/hdaudio.h b/include/sound/hdaudio.h > > index aa994d6e6d35..615e48ecb009 100644 > > --- a/include/sound/hdaudio.h > > +++ b/include/sound/hdaudio.h > > @@ -412,7 +412,9 @@ void snd_hdac_bus_link_power(struct hdac_device *hdev, bool enable); > > void snd_hdac_bus_update_rirb(struct hdac_bus *bus); > > int snd_hdac_bus_handle_stream_irq(struct hdac_bus *bus, unsigned int status, > > void (*ack)(struct hdac_bus *, > > - struct hdac_stream *)); > > + struct hdac_stream *), > > + void (*error)(struct hdac_bus *, > > + struct hdac_stream *)); > > > > int snd_hdac_bus_alloc_stream_pages(struct hdac_bus *bus); > > void snd_hdac_bus_free_stream_pages(struct hdac_bus *bus); > > diff --git a/sound/hda/common/controller.c b/sound/hda/common/controller.c > > index afec5c5546ec..329854c9fe92 100644 > > --- a/sound/hda/common/controller.c > > +++ b/sound/hda/common/controller.c > > @@ -1058,6 +1058,15 @@ static void stream_update(struct hdac_bus *bus, struct hdac_stream *s) > > } > > } > > > > +static void stream_error(struct hdac_bus *bus, struct hdac_stream *s) > > +{ > > + struct azx_dev *azx_dev = stream_to_azx_dev(s); > > + > > + spin_unlock(&bus->reg_lock); > > + snd_pcm_stop_xrun(azx_stream(azx_dev)->substream); > > + spin_lock(&bus->reg_lock); > > +} > > + > > irqreturn_t azx_interrupt(int irq, void *dev_id) > > { > > struct azx *chip = dev_id; > > @@ -1082,7 +1091,8 @@ irqreturn_t azx_interrupt(int irq, void *dev_id) > > > > handled = true; > > active = false; > > - if (snd_hdac_bus_handle_stream_irq(bus, status, stream_update)) > > + if (snd_hdac_bus_handle_stream_irq(bus, status, stream_update, > > + stream_error)) > > active = true; > > > > status = azx_readb(chip, RIRBSTS); > > diff --git a/sound/hda/core/controller.c b/sound/hda/core/controller.c > > index 78855ac357c6..67bb74c618bf 100644 > > --- a/sound/hda/core/controller.c > > +++ b/sound/hda/core/controller.c > > @@ -676,8 +676,10 @@ EXPORT_SYMBOL_GPL(snd_hdac_bus_stop_chip); > > * Returns the bits of handled streams, or zero if no stream is handled. > > */ > > int snd_hdac_bus_handle_stream_irq(struct hdac_bus *bus, unsigned int status, > > - void (*ack)(struct hdac_bus *, > > - struct hdac_stream *)) > > + void (*ack)(struct hdac_bus *, > > + struct hdac_stream *), > > + void (*error)(struct hdac_bus *, > > + struct hdac_stream *)) > > { > > struct hdac_stream *azx_dev; > > u8 sd_status; > > @@ -692,6 +694,8 @@ int snd_hdac_bus_handle_stream_irq(struct hdac_bus *bus, unsigned int status, > > dev_warn_ratelimited(bus->dev, > > "stream %u dma error: 0x%02x\n", > > azx_dev->index, sd_status); > > + if (error) > > + error(bus, azx_dev); > > } > > if ((!azx_dev->substream && !azx_dev->cstream) || > > !azx_dev->running || !(sd_status & SD_INT_COMPLETE)) > > diff --git a/sound/soc/intel/avs/core.c b/sound/soc/intel/avs/core.c > > index 1a53856c2ffb..6a5a6e526c2c 100644 > > --- a/sound/soc/intel/avs/core.c > > +++ b/sound/soc/intel/avs/core.c > > @@ -270,7 +270,8 @@ static irqreturn_t avs_hda_interrupt(struct hdac_bus *bus) > > u32 status; > > > > status = snd_hdac_chip_readl(bus, INTSTS); > > - if (snd_hdac_bus_handle_stream_irq(bus, status, hdac_update_stream)) > > + if (snd_hdac_bus_handle_stream_irq(bus, status, hdac_update_stream, > > + NULL)) > > ret = IRQ_HANDLED; > > > > spin_lock_irq(&bus->reg_lock); > > This did work to surface the errors to userspace as XRUNs. > > Of course, because this is an actual error in the transfer between the > CPU and controller, it does not help mitigate the actual problem itself. So what's the best option for users if this happens? That is, what happens if we don't restart the stream? Is it a temporary fail-out and the hardware recovers / resync by itself while streaming further? If so and it's short, it might be better to leave it as is. OTOH, if it's a fatal error that needs some manual recovery, a notification to user-space for recovery is required (if any). thanks, Takashi ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-08-06 6:30 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-08-03 22:07 [PATCH] ALSA: hda/core: Log stream DMA errors on interrupt Arun Raghavan 2026-08-04 11:21 ` Takashi Iwai 2026-08-04 17:42 ` [External Mail] " Arun Raghavan 2026-08-04 18:18 ` Takashi Iwai 2026-08-05 20:56 ` Arun Raghavan 2026-08-06 6:30 ` Takashi Iwai
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox