DC dmesg important messages¶

The dmesg log is the first source of information to be checked, and amdgputakes advantage of this feature by logging some valuable information. Whenlooking for the issues associated with amdgpu, remember that each component ofthe driver (e.g., smu, PSP, dm, etc.) is loaded one by one, and thisinformation can be found in the dmesg log. In this sense, look for the part ofthe log that looks like the below log snippet:

[    4.254295] [drm] initializing kernel modesetting (IP DISCOVERY 0x1002:0x744C 0x1002:0x0E3B 0xC8).[    4.254718] [drm] register mmio base: 0xFCB00000[    4.254918] [drm] register mmio size: 1048576[    4.260095] [drm] add ip block number 0 <soc21_common>[    4.260318] [drm] add ip block number 1 <gmc_v11_0>[    4.260510] [drm] add ip block number 2 <ih_v6_0>[    4.260696] [drm] add ip block number 3 <psp>[    4.260878] [drm] add ip block number 4 <smu>[    4.261057] [drm] add ip block number 5 <dm>[    4.261231] [drm] add ip block number 6 <gfx_v11_0>[    4.261402] [drm] add ip block number 7 <sdma_v6_0>[    4.261568] [drm] add ip block number 8 <vcn_v4_0>[    4.261729] [drm] add ip block number 9 <jpeg_v4_0>[    4.261887] [drm] add ip block number 10 <mes_v11_0>

From the above example, you can see the line that reports that<dm>,(Display Manager), was loaded, which means that display can be part of theissue. If you do not see that line, something else might have failed beforeamdgpu loads the display component, indicating that we don’t have adisplay issue.

After you identified that the DM was loaded correctly, you can check for thedisplay version of the hardware in use, which can be retrieved from the dmesglog with the command:

dmesg | grep -i 'display core'

This command shows a message that looks like this:

[    4.655828] [drm] Display Core v3.2.285 initialized on DCN 3.2

This message has two key pieces of information:

• The DC version (e.g., v3.2.285): Display developers release a new DC versionevery week, and this information can be advantageous in a situation where auser/developer must find a good point versus a bad point based on a testedversion of the display code. Remember from pageDisplay Core,that every week the new patches for display are heavily tested with IGT andmanual tests.

• The DCN version (e.g., DCN 3.2): The DCN block is associated with thehardware generation, and the DCN version conveys the hardware generation thatthe driver is currently running. This information helps to narrow down thecode debug area since each DCN version has its files in the DC folder per DCNcomponent (from the example, the developer might want to focus onfiles/folders/functions/structs with the dcn32 label might be executed).However, keep in mind that DC reuses code across different DCN versions; forexample, it is expected to have some callbacks set in one DCN that are the sameas those from another DCN. In summary, use the DCN version just as a guide.

From the dmesg file, it is also possible to get the ATOM bios code by using:

dmesg  | grep -i 'ATOM BIOS'

Which generates an output that looks like this:

[    4.274534] amdgpu: ATOM BIOS: 113-D7020100-102

This type of information is useful to be reported.

Avoid loading display core¶

Sometimes, it might be hard to figure out which part of the driver is causingthe issue; if you suspect that the display is not part of the problem and yourbug scenario is simple (e.g., some desktop configuration) you can try to removethe display component from the equation. First, you need to identifydm IDfrom the dmesg log; for example, search for the following log:

[    4.254295] [drm] initializing kernel modesetting (IP DISCOVERY 0x1002:0x744C 0x1002:0x0E3B 0xC8).[..][    4.260095] [drm] add ip block number 0 <soc21_common>[    4.260318] [drm] add ip block number 1 <gmc_v11_0>[..][    4.261057] [drm] add ip block number 5 <dm>

Notice from the above example that thedm id is 5 for this specific hardware.Next, you need to run the following binary operation to identify the IP blockmask:

0xffffffff & ~(1 << [DM ID])

From our example the IP mask is:

0xffffffff & ~(1 << 5) = 0xffffffdf

Finally, to disable DC, you just need to set the below parameter in yourbootloader:

amdgpu.ip_block_mask = 0xffffffdf

If you can boot your system with the DC disabled and still see the issue, itmeans you can rule DC out of the equation. However, if the bug disappears, youstill need to consider the DC part of the problem and keep narrowing down theissue. In some scenarios, disabling DC is impossible since it might benecessary to use the display component to reproduce the issue (e.g., play agame).

Note: This will probably lead to the absence of a display output.

Display flickering¶

Display flickering might have multiple causes; one is the lack of proper powerto the GPU or problems in the DPM switches. A good first generic verificationis to set the GPU to use high voltage:

bash -c "echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level"

The above command sets the GPU/APU to use the maximum power allowed whichdisables DPM switches. If forcing DPM levels high does not fix the issue, itis less likely that the issue is related to power management. If the issuedisappears, there is a good chance that other components might be involved, andthe display should not be ignored since this could be a DPM issues. From thedisplay side, if the power increase fixes the issue, it is worth debugging theclock configuration and the pipe split police used in the specificconfiguration.

Display artifacts¶

Users may see some screen artifacts that can be categorized into two differenttypes: localized artifacts and general artifacts. The localized artifactshappen in some specific areas, such as around the UI window corners; if you seethis type of issue, there is a considerable chance that you have a userspaceproblem, likely Mesa or similar. The general artifacts usually happen on theentire screen. They might be caused by a misconfiguration at the driver levelof the display parameters, but the userspace might also cause this issue. Oneway to identify the source of the problem is to take a screenshot or make adesktop video capture when the problem happens; after checking thescreenshot/video recording, if you don’t see any of the artifacts, it meansthat the issue is likely on the driver side. If you can still see theproblem in the data collected, it is an issue that probably happened duringrendering, and the display code just got the framebuffer already corrupted.

Multiple Planes Debug¶

If you want to enable or debug multiple planes in a specific user-spaceapplication, you can leverage a debug feature named visual confirm. Forenabling it, you will need:

echo 1 > /sys/kernel/debug/dri/0/amdgpu_dm_visual_confirm

You need to reload your GUI to see the visual confirmation. When the planeconfiguration changes or a full update occurs there will be a colored bar atthe bottom of each hardware plane being drawn on the screen.

• The color indicates the format - For example, red is AR24 and green is NV12

• The height of the bar indicates the index of the plane

• Pipe split can be observed if there are two bars with a difference in heightcovering the same plane

Consider the video playback case in which a video is played in a specificplane, and the desktop is drawn in another plane. The video plane shouldfeature one or two green bars at the bottom of the video depending on pipesplit configuration.

• There shouldnot be any visual corruption

• There shouldnot be any underflow or screen flashes

• There shouldnot be any black screens

• There shouldnot be any cursor corruption

• Multiple planemay be briefly disabled during window transitions orresizing but should come back after the action has finished

Pipe Split Debug¶

Sometimes we need to debug if DCN is splitting pipes correctly, and visualconfirmation is also handy for this case. Similar to the MPO case, you can usethe below command to enable visual confirmation:

echo 1 > /sys/kernel/debug/dri/0/amdgpu_dm_visual_confirm

In this case, if you have a pipe split, you will see one small red bar at thebottom of the display covering the entire display width and another barcovering the second pipe. In other words, you will see a bit high bar in thesecond pipe.

Trace Groups¶

Note: Not all ASICs support all of the listed trace groups

So, to enable just PSR tracing you can use the following command:

# echo 0x8020 > /sys/kernel/debug/dri/0/amdgpu_dm_dmub_trace_mask

Then, you need to enable logging trace events to the buffer, which you can dousing the following:

# echo 1 > /sys/kernel/debug/dri/0/amdgpu_dm_dmcub_trace_event_en

Lastly, after you are able to reproduce the issue you are trying to debug,you can disable tracing and read the trace log by using the following:

# echo 0 > /sys/kernel/debug/dri/0/amdgpu_dm_dmcub_trace_event_en# cat /sys/kernel/debug/dri/0/amdgpu_dm_dmub_tracebuffer

So, when reporting bugs related to features such as PSR and ABM, considerenabling the relevant bits in the mask before reproducing the issue andattach the log that you obtain from the trace buffer in any bug reports that youcreate.