BasicAddressWatch causes issues where KFDEvictTest and
KFDQMTest.OverSubscribeCpQueues fails, and results in a GPU hang/reset.
PM4EventInterrupt just hangs indefinitely. Remove them for now to allow
the kernel merges to resume, and figure out what happened in the nv10
merge to cause it
Change-Id: I418f9561ecb3e71bc52ac48ea363fcbde82a8e2b
The SDMA blacklist should contain all tests that use SDMA. It will
be applied to all ASICs that are know to have SDMA stability issues.
Change-Id: I53e723382c12f99bddf9c535000e27737a7ea1f6
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
1. Use s_mov_b32 to move 0xcafe to s18. s_movk_i32 is a sign extention move
instruction. Oxcafe will be extended to 0xffffcafe which is not desired
2. Add wait to s_load_dword instruction to make sure memory read finish before
the next store instruction.
Change-Id: I665d1d471019edfaba5693e07cdc567d4103573f
Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
If TTM eviction and restore happens, it may takes very long time if
retry, the longest time is 5 minutes during my test. There is chance
packet is submited to queue while eviction, we have to increase the
Wait4PacketConsumption timeout.
The queue will continue to execute after eviction and restore. If we
upmap the memory from GPU while queue is evicted, this will cause VM
fault. Change to unmap memory after queue is destroyed.
Change-Id: I1b44e2274ea7b83398b2e3293578dad6947cb5af
Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Because dma32 zone is on node 0, use all system memory on node 0 will
cause TTM eviction to free dma32 zone for other devices which only
work with 32bit physical address. The TTM eviction and restore may take
too long and cause queue timeout.
Running on other NUMA nodes, the NUMA default memory policy is
MPOL_PREFERRED, means TTM will get pages from local node first, and then
get remaining pages from other nodes. Check /proc/buddyinfo can confirm
this.
Reset NUMA bind to all after the test.
Change-Id: I39b373c07a2d5aa396f5c7602bffabab0481930f
Signed-off-by: Philip Yang <Philip.Yang@amd.com>
PSDB and other jenkins jobs are currently failing on several kfd tests.
This is blocking user throughput for screening patches by PSDB.
Blacklist multiple tests and submit JIRA's.
KFDIPCTest.BasicTest (ROCMOPS-459) .CMABasicTest (ROCMOPS-460) .CrossMemoryAttachTest (ROCMOPS-461)
KFDMemoryTest.BigBufferStressTest (ROCMOPS-462)
KFDQMTest.MultipleSdmaQueues (ROCMOPS-463) (ROCMOPS-416)
KFDEvictTest.BurstyTest (ROCMOPS-464)
Change-Id: I2c7cdeabc26654f39823201ce86d4113b3a98a0e
Signed-off-by: Cole Nelson <cole.nelson@amd.com>
This relates to the following commits:
1. commit aa7c13264a
2. commit 54807526b9
3. commit 6df62c78b8
Change-Id: I3d0d3214baba403b4709b358132b6756a15f42d7
Signed-off-by: Ori Messinger <Ori.Messinger@amd.com>
Allocating these before the big memory allocations minimizes the chances
of spurious out of memory errors.
Change-Id: I94aff9ec7ea34d4dc98ae08ac4cf9dc335b3df7f
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
This reduces thrashing due to graphics submissions only and
significantly speeds up the BasicTest when keeping idle compute
processes evicted. In the BasicTest compute is always idle, so
only one compute eviction and no restore is triggered. Then
graphics submissions complete quickly without thrashing each other.
Change-Id: Iae6da98903b20424a5097f235e1d09cf13e4b41b
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
1. umc error injection only accepts parameter "0 0".
2. flush output to file in order to make writing happen
immediately.
Change-Id: I8d3bde287caee6b90b6eec56c760f5a228be7595
Signed-off-by: Eric Huang <JinhuiEric.Huang@amd.com>
The path was wrong based on assumption that GPU dri render
node starts from 0, because if there is a VGA device on
board, node 0 will be VGA and node 1 will be GPU. So the fix
will look at the name of GPU minor node and find the correct
primary node on which RAS debugfs entry exists.
Change-Id: Icc5e63ce48698d5d29105c0417e3bec8afa0a7c8
Signed-off-by: Eric Huang <JinhuiEric.Huang@amd.com>
The queue IDs passed over to the kernel via kfd_ioctl_dbg_trap_args->ptr
should be a list of uint32_t's. Need to convert from the passed in
64 bit HSA_QUEUEID to 32 bit uint32_t's.
Change-Id: I8718566d9f9ffc90ce0b2ecc129b10c49d73186a
Signed-off-by: Philip Cox <Philip.Cox@amd.com>
This is updating to the new suspend and resume API for the
KFD and the thunk. We now support passing in a list of queues
to suspend, and not just all of the queues for the process.
The kfdtest testcase was also updated so it still compiles.
Change-Id: I71d1b178476bd9df0c311bdedaa6a891528cebcf
Signed-off-by: Philip Cox <Philip.Cox@amd.com>
- Run more graphics command submissions with shorter delay between
them
- Synchronize after every graphics command submission
- Include the big VRAM BO in the BOList of the command submission
to trigger more evictions
- In QueueTest, run AMDGPU command submissions concurrently with
compute shader on the user mode queue
- Submit AMDGPU commands to GFX queue instead of compute queue to
avoid deadlocks between user-mode and kernel-mode queues on the
same pipe
- Allocate slightly less memory from KFD to avoid allocation errors
due to fragmentation or memory leaks in previous tests
- Running only two processes maximizes the number of KFD evictions
(probably because of lower chances of evicting non-KFD BOs)
Change-Id: If05d53f5fcf690b6488998a3f933f120ddaa71ee
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Those two tests cover the basic queue creation and destruction
without submitting packets to CP and SDMA user queues. During bringup,
they bring values in term of untangling the issues arising in queue
creation and packet execution, which are two very different kinds.
Because of those two tests, we also rename some existing tests as
follows:
CreateCpQueue -> SubmitPacketCpQueue
CreateSdmaQueue -> SubmitPacketSdmaQueue
CreateMultipleCpQueues -> MultipleCpQueues
CreateMultipleSdmaQueues -> MultipleSdmaQueues
Lastly, move MultipleCpQueues test closer to the CP queue section
rather than leaving it behind the SDMA queue section.
Change-Id: I110fb3f3fb21878339045dd1d1c8c9d61b8988b7
Signed-off-by: Yong Zhao <Yong.Zhao@amd.com>
If a Render Node can't be found, we should finish off all child
processes immediately, then return.
Trying to do the check before forking the children results in the test
failing as well, regardless of the status of finding the render node,
which is likely why the forking occurred first in the test's initial
creation. This way we ensure that things finish cleanly before moving to
the next test
Change-Id: I2e1b62fed25c30ff1f179612127c23960da4ee5e
1. RAS error injection debugfs interface has been changed which
is using ras_ctrl instead of *_err_inject.
2. Remove ASSERT_SUCCESS for fwrite, because fwrite returns
the size of written item but not the error number.
3. Using throw exception instead of return to avoid a segment fault.
Change-Id: I6c4d9c2f7e66719faec99abd1552105a08c238a4
Signed-off-by: Eric Huang <JinhuiEric.Huang@amd.com>
This reverts commit d00ec779ce.
Fixes for HMM change corner cases are merged in from drm-next.
Tests are passed on gfx900 with the latest amd-kfd-staging.
Change-Id: I6c00d1eacf6b3f1ce715e085ae622b4e9ff1b7ff
Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Due to the recent HMM changes, the KFDIPCTest can intermittently fail,
combined with CrossMemoryAttach consistently failing. Remove it for now
while Philip Yang investigates
Change-Id: Icf272100bb7882eff4202ad6f4ced63b569f4e7d
Per Philip Yang:
For forked child process, userptr allocated on heap (through malloc)
will have two vmas if child process malloc smaller size buf, free it,
this is on vma cloned from parent process. Then malloc larger size buf,
kernel will put some pages on previous freed space from vma cloned,
create new vma for the rest of pages. This is what IPCTest does.
Change-Id: I054771e20880f975d7cc774225f19aad5363843f
With the orginal code, CreateCpQueue will report failure if
WaitOnValue return false. Add EXPECT_TRUE() so that in that case
the failure is reported.
Change-Id: I043d013958b452d7ccb9538dc296d99d024abf01
Signed-off-by: Yong Zhao <Yong.Zhao@amd.com>
We need to black list this testcase temporarily because
it is failing intermittently. The failure tends to only happen
when the certain build machine is used to build it.
This issue is being tracked by Jira ticket:
ROCMOPS-389
Change-Id: Ic4682c9da389ed731cbc034dff57e6646bba0e9d
Signed-off-by: Philip Cox <Philip.Cox@amd.com>
A basic sanity test that tests the codepath for
the debugger suspend and resume code path.
Change-Id: If4c64f7bd6a1ef45068a33965b829725a78ce492
Signed-off-by: Philip Cox <Philip.Cox@amd.com>
This will facilitate us to avoid using family ID to differentiate the
SDMA engines and SDMA queues.
Change-Id: I8d6203cc5d330e9130a1b2624997c86ba53e8ae4
Signed-off-by: Yong Zhao <Yong.Zhao@amd.com>
KFDPerformanceTest.P2PBandWidthTest[push, push] takes about 3 seconds
on 4 gfx906, the default g_TestTimeout 2 seconds is not enough to wait
for sDMA queue rptr is consumed. Use kfdtest command line option
--timeout=6000, the test is finished and result is reasonable twice as
P2PBandWidthTest[push, none]. Change P2PBandWidthTest wait timeout to 6
seconds.
Add timeout argument to function WaitOnValue, BaseQueue.Wait4PacketConsumption
SDMAQueue.Wait4PacketConsumption, PM4Queue.Wait4PacketConsumption with
default value is g_TestTimeOut.
Change-Id: I0aa04d644339feaeea695e41647ae66568beab9e
Signed-off-by: Philip Yang <Philip.Yang@amd.com>
This will support the sp3 library built on one gcc version to be
compatible with another gcc version.
Change-Id: If67714bd63376dc781c56ed025be335fe54b2ba5
Signed-off-by: Yong Zhao <Yong.Zhao@amd.com>
These tests all make use of an SDMAQueue in one way or another, so add
them to the SDMA_BLACKLIST to be 100% certain
Change-Id: Ic29e073c2f46249f3e5918145b13d276aec7bb33
This is intermittently causing VM faults and excessive evictions, which
causes the rest of the tests to fail. Take it out for now until someone
can investigate
Change-Id: I9c43890bc9f03a4a31efbc18df0df5e40a232c58
On small bar multi-gpu system, hsaKmtMemoryMapToGPU will fail due to latest
kernel P2P sanity check. Swith to use hsaKmtMemoryMapToGPUNodes to fix
the failure
Change-Id: Id8b6329d1243df0e908cc9a171b5c7f9156f4a8b
Signed-off-by: shaoyunl <shaoyun.liu@amd.com>
BaseQueue class has a member function GetQueueType so m_Type
is duplicated. m_Type is only used in one function. Move it to
a local variable.
Change-Id: Ice144cf723178dd628cb49261c23d10605f9ee7d
Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
On gfx900+, the test sometimes timeout due to cp fw bug.
Blacklist it until we address the root cause and have a fix.
Change-Id: Iff600a6f6dbd86c56e034f530484205520bced32
Signed-off-by: xinhui pan <xinhui.pan@amd.com>
We observe this test fails on gfx900+. Looks like the sdma packets are not
executed at all after we submit sometimes.
Run it with timeout 2s on gfx900.
[ RUN ] KFDQMTest.SdmaEventInterrupt
[----------] SDMACopyData FAIL! 1485262707170 VS 1485262747814
[----------] Event On Queue 1:0 Timeout, try to resubmit packets!
[----------] The timeout event is signaled!
[ ] Time Consumption (ns)
[ ] 1: 1859427148
[ ] 2: 680148
[ ] 3: 6370
[ ] 4: 5481
/home/pp/code/compute/libhsakmt/tests/kfdtest/src/KFDQMTest.cpp:1670: Failure
Value of: (ret)
Actual: 31
Expected: HSAKMT_STATUS_SUCCESS
Which is: 0
[----------] SDMACopyData FAIL! 1485367669958 VS 1485367750022
[----------] Event On Queue 2:1 Timeout, try to resubmit packets!
[----------] The timeout event is signaled!
[ ] Time Consumption (ns)
[ ] 1: 1881615148
[ ] 2: 673629
[ ] 3: 6074
[ ] 4: 5481
/home/pp/code/compute/libhsakmt/tests/kfdtest/src/KFDQMTest.cpp:1670: Failure
Value of: (ret)
Actual: 31
Expected: HSAKMT_STATUS_SUCCESS
Which is: 0
[----------] SDMACopyData FAIL! 1485427671250 VS 1485427751238
[----------] Event On Queue 2:1 Timeout, try to resubmit packets!
[----------] The timeout event is signaled!
[ ] Time Consumption (ns)
[ ] 1: 1881508777
[ ] 2: 741629
[ ] 3: 6074
[ ] 4: 5481
/home/pp/code/compute/libhsakmt/tests/kfdtest/src/KFDQMTest.cpp:1670: Failure
Value of: (ret)
Actual: 31
Expected: HSAKMT_STATUS_SUCCESS
Which is: 0
[ FAILED ] KFDQMTest.SdmaEventInterrupt (23675 ms)
Change-Id: I7c1b752537d89782570df20838bf976578614f75
Signed-off-by: xinhui pan <xinhui.pan@amd.com>