VITIS-13074 - Dump common control codes before and after being patched #8338
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
maxzhen
approved these changes
Aug 8, 2024
stsoe
requested changes
Aug 8, 2024
larry9523
approved these changes
Aug 9, 2024
daveliddell
pushed a commit
to daveliddell/XRT
that referenced
this pull request
Sep 27, 2024
VITIS-13074 - Dump common control codes before and after being patched (Xilinx#8338) * Dump control-codes, control-packet and preemption-codes * Attempt to fix compiling errors on linux * Remove no_exec_cmd_buf * Remove all change to xrt_kernel.cpp * Put all change in xrt_module.cpp. Not ideal... * Add log file * Trigger debugging elf-flow only if xrt_core::config::get_xrt_debug is true * Attempt to fix compile error on centos78 --------- Co-authored-by: dezhliao <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem solved by the commit
The overall goal is to provide a debugging method when there is a hang caused by control-codes.
Add one flag dump-control-codes in file xrt.ini Debug section. When this flags is true, control-codes before and after patching are dumped for users to further identify the issue.
Refer to this confluence page for spec: https://confluence.amd.com/x/8avhV
Bug / issue (if any) fixed, which PR introduced the bug, how it was discovered
How problem was solved, alternative solutions (if any) and why they were rejected
Problem1: If application has many run-object. How to tell which set of pre- and post- patch bin file is for which run?
Ultimate solution is to add an id in elf file
Currently the id is a static member of class xrt::module_sram. It is incremented every time when constructor is called.
Problem2: minimize performance impact brought by debug flag
Selected solution:
At the phase of constructing xrt::module_sram, Check whether Dump-control-codes is true. If yes, record it in xrt::module_sram::m_debug_mode.
Alternative solution (rejected because concept of control-codes is also in xrt-device)
At the phase of creating xrt::device, Check whether Dump-control-codes is true. If yes, record it in xrt::device::m_debug_mode. The reason is to avoid checking Dump-control-codes in a use case with many xrt::module.
Risks (if any) associated the changes in the commit
What has been tested and how, request additional testing if necessary
Test on strixb0 has been done using one of the standard transaction-buffer test cases from Larry.
Documentation impact (if any)
The new entry in xrt.ini needs to be documented