On Sat, 05 Feb 2022 18:51:32 +0100, Alexander Sergeyev wrote: > > On Mon, Jan 31, 2022 at 03:57:04PM +0100, Takashi Iwai wrote: > > In anyway, we need to track down exactly which access triggers those > > errors... > > I went deeper into codec reads and writes: > - snd_hda_codec_write > - snd_hdac_codec_write > - codec_write > - snd_hdac_exec_verb > - codec_exec_verb > - snd_hdac_bus_exec_verb_unlocked > - azx_send_cmd / azx_get_response > - snd_hdac_bus_send_cmd / azx_rirb_get_response > > In the last functions a circular buffer is used to write commands. The > problem is that "bus->corb.buf[wp]" and "bus->rirb.res[addr]" are > nowhere close to the IOMMU-reported address of the offending memory > access. It's likely that I've missed other communication channels. But > is it possible that IOMMU-reported address and buffers addresses are of > different kinds (physical/virtual) or different regions mapped to the > same physical pages? > > Example: > snd_hdac_bus_send_cmd: bus->corb.buf[wp] = cpu_to_le32(val) // = 0x3b8000, wp=0xfb, &buf[wp]=00000000f1fd4592 > snd_hdac_bus_get_response: reading result from 0000000059c4003d > snd_hdac_bus_send_cmd: bus->corb.buf[wp] = cpu_to_le32(val) // = 0x339000, wp=0xfc, &buf[wp]=000000007f14c128 > snd_hdac_bus_get_response: reading result from 0000000059c4003d > snd_hdac_bus_send_cmd: bus->corb.buf[wp] = cpu_to_le32(val) // = 0x1470740, wp=0xfd, &buf[wp]=00000000a6b14901 > snd_hdac_bus_get_response: reading result from 0000000059c4003d > snd_hdac_bus_send_cmd: bus->corb.buf[wp] = cpu_to_le32(val) // = 0x14ba000, wp=0xfe, &buf[wp]=00000000d8d1672a > snd_hdac_bus_get_response: reading result from 0000000059c4003d > snd_hdac_bus_send_cmd: bus->corb.buf[wp] = cpu_to_le32(val) // = 0x14b8000, wp=0xff, &buf[wp]=00000000b87b3287 > snd_hdac_bus_get_response: reading result from 0000000059c4003d > snd_hdac_bus_send_cmd: bus->corb.buf[wp] = cpu_to_le32(val) // = 0x2ba000, wp=0x0, &buf[wp]=000000002162c728 > snd_hdac_bus_get_response: reading result from 0000000059c4003d > snd_hdac_bus_send_cmd: bus->corb.buf[wp] = cpu_to_le32(val) // = 0x2b8000, wp=0x1, &buf[wp]=0000000095f61061 > snd_hda_intel 0000:05:00.6: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0015 address=0x1fffff800 flags=0x0020] Hm, I'm not sure, either. But let's try to avoid some possible confusion at first, e.g. a patch like below. Takashi -- 8< -- diff --git a/sound/hda/hdac_controller.c b/sound/hda/hdac_controller.c index f7bd6e2db085..074199aa73ea 100644 --- a/sound/hda/hdac_controller.c +++ b/sound/hda/hdac_controller.c @@ -618,7 +618,7 @@ int snd_hdac_bus_alloc_stream_pages(struct hdac_bus *bus) if (WARN_ON(!num_streams)) return -EINVAL; /* allocate memory for the position buffer */ - err = snd_dma_alloc_pages(dma_type, bus->dev, + err = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, bus->dev, num_streams * 8, &bus->posbuf); if (err < 0) return -ENOMEM; @@ -626,7 +626,7 @@ int snd_hdac_bus_alloc_stream_pages(struct hdac_bus *bus) s->posbuf = (__le32 *)(bus->posbuf.area + s->index * 8); /* single page (at least 4096 bytes) must suffice for both ringbuffes */ - return snd_dma_alloc_pages(dma_type, bus->dev, PAGE_SIZE, &bus->rb); + return snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, bus->dev, PAGE_SIZE, &bus->rb); } EXPORT_SYMBOL_GPL(snd_hdac_bus_alloc_stream_pages);
