PC Processors

[igel]

After updating Linux kernels to 6.2.0 (Pop-OS! and Ubuntu) or anything newer, the HDMI and DP signals are gone. Monitors and analyzers report that the signal goes out as soon as the kernel starts loading. EFI and boot manager are displayed properly, Windows 10 boots as well. Happens on 3000G and 5600G in ASrock X300W DeskMini, ASrock X300 DeskMeet, ASrock B450M Steel legend. 

With amdgpu.sg_display=0 and AGESA 1.2.0.7 there is no difference. With AGESA 1.2.0.A (not sure what is this) the 6.2.0 kernel never sends a signal, and the 6.2.6 kernel after some time (presumably when X/wayland starts) displays a colored noise. 

[kheper]

Your distro-released kernels may be missing config options. I'm running a custom 6.2.1 kernel - made with oldconfig from a previous kernel config.

You could paste /boot/config-6.2.0 here, and someone might be able to detect the issue. You could also compare the config of a previous working kernel with the configs of the 6.2.X kernels. diff on the commandline.

[igel]

Nope, that's not it. Kernel config relative to the amdgpu driver is the same. After finally having time to dig this deeper it turned out that something has changed in how kfd and amd_iommu interact, or how amd_iommu works. Extracting logs, there is a message from kfd that IOMMU cannot continue for the ID of the iGPU. 

There are two, actually 3 ways to get the display working properly again. 

1. yanking the amd_iommu off entirely with amd_iommu=off. This has negative effects on virtualization abilities, so it is not preferable. 

2. setting amd_iommu to force_isolation. This keeps IOMMU running for the system in general, but you still get the error from kfd about not being able to continue the IOMMU for the iGPU so I expect that suspend/resume will be affected.

3. instructing the amdgpu driver to ignore one of the acpi tables via an undocumented parameter. amdgpu.ignore_crat=1. There is no IOMMU resume error from kdf, however the amdgpu driver now considers the iGPU to be a dGPU. It is a minor and non-material difference to me. 

Note that this is always a cold boot, not a resume. 

[kheper]

Compare the 6.2.X config with the config of an older working kernel. Identify which IOMMU options are set (or are not set). I have no video signal issues with 6.2.X kernels and my AMD APU.

[igel]

Again, it is not a question of configuration ( configs were compared). Apparently amd made changes to the iommu driver and are aware that it broke things and are working on a fix in the 6.3 kernel. 

here is the bugzilla:

217170 – amdgpu failed to resume involving AMD IOMMU with 6.2.2-301 kernel resulting in a black scre...

and the iommu dev thread amdgpu failed to resume with AMD IOMMU enabled and 6.2.2-301 and 6.3.0-0.rc0.20230227gitf3a2439f20d9...

[kheper]

My guess is that your distro(s) are using 6.X kernel patches, specific (and broken) to them. 

Debian's new release is called - Bookworm. The default kernel on Bookworm is 6.1.0-9. There're no issues with AMD APUs. 

You could compile a vanilla, 6.X kernel from kernel.org, or switch to Debian Bookworm.

[igel]

Again, please read.

The change is in the 6.2.0 mainline kernel. As I pointed out, this is a change AMD made in the driver and is known to cause issues. 

The fact that it is working on Debian with old 6.1.X kernel is why it is working - the changes are not in yet - and is immaterial to the topic. The topic applies to 6.2.x kernels only as apparently AMD already submitted the patch to the 6.3 tree in rc3. 

[Anonymous]

Often linux and bios and other things use a default colorspace and resolution thats maybe a lot lower than a typical TV or monitor nowadays. The hollywood formatting is 1080p or 4k. If the kernel was outputing in 800x600 or something similar or even just 720p for compatability and to support legacy hardware or in older VGA colorspace your display would be the issue and need to be configured or connected possibly via different cables that are NOT HDMI or to an older or different display. Or if the drivers have freesync or a newer colorspace enabled or HDR for example your monitors maybe do not support that or havent got it turned on. Furthermore if you turn on freesync or HDR in the monitor buttons/remote menus and the OS doesnt have HDR or freesync drivers.. you see a blank screen. Also sometimes display signals may have issues based on what is plugged in first at boot like the APU or if theres a discreet GPU. Lastly many linux distros may say great for gaming or whatever or be a crypto mining thing. All crypto mining cards dont output graphics to use all of it for 'data crunching maths'. There also just might be an issue with the cables you are using if that version of linux EDID HDMI or display port CEC and device identification doesnt match up for whatever reason. Some people edit that stuff to 'overclock' their HDMI or whatever and think its 'cool' when nothing can be detected anymore or it shows up as a different hardware device to fake benchmarks like some sort of intel or nvidia youtuber.

if you are using virtualization that could be your issue too. check your APU in bios is it hybrid graphics? or auto? game mode? is single root IO virtualization on or off? did you enable secure boot and you updated the OS and now it cant show an image because it cant boot as the secure boot and TPM 2.0 has a boot sector linked to a previous OS? was the OS you had before ever using any sort of drive encryption or bitlocker? did you use samsung magician or some other type of memory card secure encryption on your drive partitions? that often leaves a blank signal after installing from live CD or boot media.