Re: ✗ Fi.CI.IGT: failure for drm/i915: stop using swiotlb (rev6)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 28/07/2022 16:54, Robert Beckett wrote:
On 28/07/2022 15:03, Tvrtko Ursulin wrote:

On 28/07/2022 09:01, Patchwork wrote:

[snip]

        Possible regressions

  * igt@gem_mmap_offset@clear:
      o shard-iclb: PASS
<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11946/shard-iclb6/igt@gem_mmap_offset@xxxxxxxxxx>
        -> INCOMPLETE
<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106589v6/shard-iclb1/igt@gem_mmap_offset@xxxxxxxxxx>

What was supposed to be a simple patch.. a storm of errors like:

yeah, them's the breaks sometimes ....


  DMAR: ERROR: DMA PTE for vPFN 0x3d00000 already set (to 2fd7ff003 not 2fd7ff003)
  ------------[ cut here ]------------
  WARNING: CPU: 6 PID: 1254 at drivers/iommu/intel/iommu.c:2278 __domain_mapping.cold.93+0x32/0x39<>   Modules linked in: vgem drm_shmem_helper snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_cod>   CPU: 6 PID: 1254 Comm: gem_mmap_offset Not tainted 5.19.0-rc8-Patchwork_106589v6-g0e9c43d76a14+ #>   Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS >
  RIP: 0010:__domain_mapping.cold.93+0x32/0x39
  Code: fe 48 c7 c7 28 32 37 82 4c 89 5c 24 08 e8 e4 61 fd ff 8b 05 bf 8e c9 00 4c 8b 5c 24 08 85 c>
  RSP: 0000:ffffc9000037f9c0 EFLAGS: 00010202
  RAX: 0000000000000004 RBX: ffff8881117b4000 RCX: 0000000000000001
  RDX: 0000000000000000 RSI: ffffffff82320b25 RDI: 00000000ffffffff
  RBP: 0000000000000001 R08: 0000000000000000 R09: c0000000ffff7fff
  R10: 0000000000000001 R11: 00000000002fd7ff R12: 00000002fd7ff003
  R13: 0000000000076c01 R14: ffff8881039ee800 R15: 0000000003d00000
  FS:  00007f2863c1d700(0000) GS:ffff88849fd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f2692c53000 CR3: 000000011c440006 CR4: 0000000000770ee0
  PKRU: 55555554
  Call Trace:
   &lt;TASK&gt;
   intel_iommu_map_pages+0xb7/0xe0
   __iommu_map+0xe0/0x310
   __iommu_map_sg+0xa2/0x140
   iommu_dma_map_sg+0x2ef/0x4e0
   __dma_map_sg_attrs+0x64/0x70
   dma_map_sg_attrs+0x5/0x20
   i915_gem_gtt_prepare_pages+0x56/0x70 [i915]
   shmem_get_pages+0xe3/0x360 [i915]
   ____i915_gem_object_get_pages+0x32/0x100 [i915]
   __i915_gem_object_get_pages+0x8d/0xa0 [i915]
   vm_fault_gtt+0x3d0/0x940 [i915]
   ? ptlock_alloc+0x15/0x40
   ? rt_mutex_debug_task_free+0x91/0xa0
   __do_fault+0x30/0x180
   do_fault+0x1c4/0x4c0
   __handle_mm_fault+0x615/0xbe0
   handle_mm_fault+0x75/0x1c0
   do_user_addr_fault+0x1e7/0x670
   exc_page_fault+0x62/0x230
   asm_exc_page_fault+0x22/0x30

No idea. Maybe try CI kernel config on your Tigerlake?

I have an idea of what could be happening:

The warning is due to a pte already existing. We can see from the warning that it is the same value, which indicates that the same page has been mapped to the same iova before.

This map shrink loop will keep mapping the same sg, shrinking if it fails to hopefully free up iova space.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915/i915_gem_gtt.c?h=v5.19-rc8#n32

If we now look at the intel iommu driver's mapping function:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iommu/intel/iommu.c?h=v5.19-rc8#n2248

If that -ENOMEM loop breaking return is hit (presumably running out of pte space, though I have not delved deeper), then it will return back up the stack, eventually returning 0 from dma_map_sg_attrs() indicating the error. This will cause a shrink and retry.

The problem is that the iommu does not undo it's partial mapping on error. So the next time round, it will map the same page to the same address giving the same pte encoding, which would give the warning observed.

I would need to get some time to try to repro and debug to confirm, but this looks like it might be exposing an iommu driver issue due to us changing our mapping patterns because the segment sizes are now different.

I'll see if I can get some time allotted to debug it further, but for now, I don't have the bandwidth, so this may need to go on hold until I or someone else can get time to look in to it.

Yeah that's understandable. I also currently don't have any free bandwidth unfortunately.

+ Christoph FYI, as per above, swiotlb API usage removal is currently a bit stuck until we find someone with some spare time to debug this further.

Regards,

Tvrtko



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux