<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>Hi Michel,</p>
    <p>Please check if this patch "drm/amdkfd: start_cpsch don't map
      queues" can fix the driver loading ring test failed issue on your
      system, I am still not able to repro the issue.</p>
    <p>Regards,</p>
    <p>Philip<br>
    </p>
    <div class="moz-cite-prefix">On 2023-07-21 09:30, Philip Yang wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:0a99c609-c5c2-25fc-4ceb-52a0b4a49f29@amd.com">
      
      <p><br>
      </p>
      <div class="moz-cite-prefix">On 2023-07-21 04:55, Michel Dänzer
        wrote:<br>
      </div>
      <blockquote type="cite" cite="mid:d515206e-ab58-a8c4-ef3a-e93fc61ba37d@daenzer.net">
        <pre class="moz-quote-pre" wrap="">On 7/20/23 22:48, Philip Yang wrote:
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">On 2023-07-20 06:46, Michel Dänzer wrote:
</pre>
          <blockquote type="cite">
            <pre class="moz-quote-pre" wrap="">On 7/17/23 15:09, Michel Dänzer wrote:
</pre>
            <blockquote type="cite">
              <pre class="moz-quote-pre" wrap="">On 5/10/23 23:23, Alex Deucher wrote:
</pre>
              <blockquote type="cite">
                <pre class="moz-quote-pre" wrap="">From: Philip Yang <a class="moz-txt-link-rfc2396E" href="mailto:Philip.Yang@amd.com" moz-do-not-send="true"><Philip.Yang@amd.com></a>

Rename smv_migrate_init to a better name kgd2kfd_init_zone_device
because it setup zone devive pgmap for page migration and keep it in
kfd_migrate.c to access static functions svm_migrate_pgmap_ops. Call it
only once in amdgpu_device_ip_init after adev ip blocks are initialized,
but before amdgpu_amdkfd_device_init initialize kfd nodes which enable
SVM support based on pgmap.

svm_range_set_max_pages is called by kgd2kfd_device_init everytime after
switching compute partition mode.

Signed-off-by: Philip Yang <a class="moz-txt-link-rfc2396E" href="mailto:Philip.Yang@amd.com" moz-do-not-send="true"><Philip.Yang@amd.com></a>
Reviewed-by: Felix Kuehling <a class="moz-txt-link-rfc2396E" href="mailto:Felix.Kuehling@amd.com" moz-do-not-send="true"><Felix.Kuehling@amd.com></a>
Signed-off-by: Alex Deucher <a class="moz-txt-link-rfc2396E" href="mailto:alexander.deucher@amd.com" moz-do-not-send="true"><alexander.deucher@amd.com></a>
</pre>
              </blockquote>
              <pre class="moz-quote-pre" wrap="">I bisected a regression to this commit, which broke HW acceleration on this ThinkPad E595 with Picasso APU.
</pre>
            </blockquote>
            <pre class="moz-quote-pre" wrap="">Actually, it doesn't seem to break HW acceleration completely. GDM eventually comes up with HW acceleration, it takes a long time (~30s or so) to start up though.

Later, the same messages as described in <a class="moz-txt-link-freetext" href="https://gitlab.freedesktop.org/drm/amd/-/issues/2659" moz-do-not-send="true">https://gitlab.freedesktop.org/drm/amd/-/issues/2659</a> appear.

Reverting this commit fixes all of the above symptoms.


I reproduced all of the above symptoms with amd-staging-drm-next commit 75515acf4b60 ("i2c: nvidia-gpu: Add ACPI property to align with device-tree") as well.


For full disclosure, I use these kernel command line arguments:

 fbcon=font:10x18 drm_kms_helper.drm_fbdev_overalloc=112 amdgpu.noretry=1 amdgpu.mcbp=1
</pre>
          </blockquote>
          <pre class="moz-quote-pre" wrap="">Thanks for the issue report and full disclosure, but I am not able to reproduce this issue, with both drm-next branch and amd-staging-drm-next branch tip on gitlab. The test system has same device id, running Ubuntu 22.04, latest linux-firmware-20230625.tar.gz, and same BIOS version.
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">FWIW, your system has PCI revision ID 0xC2, while mine has 0xC1.

Also, I'm currently using linux-firmware 20230515. AFAICT there are no relevant changes in 20230625, but I'm attaching the contents of /sys/kernel/debug/dri/0/amdgpu_firmware_info just in case.


</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">I attached full dmesg log, could you help check if there is other difference, maybe kernel config, gcc version... it is hard to guess what could cause the basic driver gfx ring IB test timeout.
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">I suspect the IOMMU page faults logged in my dmesg might be relevant:

 amdgpu: Topology: Add APU node [0x15d8:0x1002]
 amdgpu 0000:05:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x122201800 flags=0x0070]
 amdgpu 0000:05:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x1125fe380 flags=0x0070]
 kfd kfd: amdgpu: added device 1002:15d8

There are no such page faults with the commit reverted.

Other than that and the IB test failure messages, our dmesg outputs are mostly identical indeed.</pre>
      </blockquote>
      <p>Yes, I don't have IO_PAGE_FAULT message on my system, thanks
        for the finding, I will continue investigating the root cause. <br>
      </p>
      <p>You are right, the error message could cause gfx ring IB test
        timeout failure, this patch does change the order of driver
        memory allocation. IOMMU is in translation mode on Ubuntu
        config.</p>
      <p>To help confirm if this is caused by IOMMU, please add this to
        kernel boot option to set IOMMU to passthrough mode, check if
        this can workaround the issue</p>
      <p>iommu=pt</p>
      <p>Regards,</p>
      <p>Philip<br>
      </p>
      <blockquote type="cite" cite="mid:d515206e-ab58-a8c4-ef3a-e93fc61ba37d@daenzer.net"> </blockquote>
    </blockquote>
  </body>
</html>