From: Takashi Iwai <tiwai@suse.de>
To: Arun Raghavan <arunr@valvesoftware.com>
Cc: Takashi Iwai <tiwai@suse.de>, Jaroslav Kysela <perex@perex.cz>,
Takashi Iwai <tiwai@suse.com>, <linux-sound@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
"Arun Raghavan" <arun@arunraghavan.net>
Subject: Re: [External Mail] Re: [PATCH] ALSA: hda/core: Log stream DMA errors on interrupt
Date: Tue, 04 Aug 2026 20:18:52 +0200 [thread overview]
Message-ID: <87wlu5hhpv.wl-tiwai@suse.de> (raw)
In-Reply-To: <DKGCFDZL0ZPJ.WU7CLZ8ZJKOI@valvesoftware.com>
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);
next prev parent reply other threads:[~2026-08-04 18:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2026-08-05 20:56 ` Arun Raghavan
2026-08-06 6:30 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wlu5hhpv.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=arun@arunraghavan.net \
--cc=arunr@valvesoftware.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox