Video signal lost during starting Fedora 36 beta Live USB

Ask Fedora
, ,
1

Hello,

I am trying out Fedora 36 beta on HP ProDesk 405 G6 MFF, download ISO, put it onto the stick, reboot, select in UEFI menu.

I am presented with Grub menu, choose the option to boot it, then an image of Fedora briefly flashes and I get ‘no signal’ from monitor.

For the record I get the same problem on Arch installed on the same machine as soon as I upgrade from kernel 5.15.13 to 5.16.2.arch1. Screen is connected via HDMI and GPU is:

0a:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Renoir [1002:1636] (rev dc)

I don’t have a regular physical access to the computer which makes things like bisecting the kernel practically impossible. Perhaps someone has any hints how to deal with this?

Thanks, jose

2

I recently got a new desktop computer that has an AMD GPU (6700xt) and it has the same issue with “no display”… sometimes.

If you try multiple boots, does it work some of the time? That’s the case for me. (I was able to boot the installer just fine, but after install, the “no signal” would hit me some of the time.)

My new desktop is running a fresh install of Fedora 36 Silverblue and it intermittently has “no signal” while booting right after grub. Before grub (EFI boot splash) and after booting when there is a signal, everything’s fine. Around 1/4 to 1/2 the boots are met with “no signal” and the GPU is apparently not powered. DisplayPort and HDMI both do not work when it’s in this state.

On a successful boot, it works perfectly, for many hours. Suspend and resume work fine too, so it really looks like some problem initializing the GPU during boot.

At first, I was worried that it might be a hardware issue with the computer, as it’s new… but it might also be a cable problem or just a finicky monitor + GPU combo in my setup. I do get some issues with my work and personal laptops hooked up to my external monitors too, but they still work (although sometimes with weird resolutions or they don’t see the monitor correctly). However, my laptops have fallback displays (internal screens) and my desktop doesn’t. And they’re Intel iGPUs, whereas my new desktop is using an AMD card.

But if you and others are having similar issues, then it might be something with the AMD driver in the kernel. Additionally, Fedora changed the DRM/KMS boot support:

But if it’s happening in Arch for you too, then it’s probably not the Fedora 36 changes.

I haven’t found a solution yet. Perhaps there’s some initialization in Fedora’s boot that’s causing a problem.

On a hunch, I removed the rhgb option from grub, thinking that it might not like the modeswitching from bios to the password prompt (as my disk is encrypted). But this is a wild guess. I’ll test it later, when I’m back on it and will try to remember to check back here soon with how things are going here as well.

In summary, it could be a number of things:

  1. Bad hardware (probably not, if we’re both having this problem, and if it only happens after grub, and in my case, only sometimes)
  2. Bad cable (it’s a possibility… perhaps something in recent software changes is more sensitive to our cables)
  3. Picky monitors and/or GPUs and/or cables in combination
  4. Fedora 36’s DRM/KMS changes
  5. Kernel changes with the AMD driver

I think you and I have most likely knocked down the possibilities to kernel changes between 5.15.13 to 5.16.2 (and Fedora is on 5.17.6-300 here). Since it’s likely not something that would go into a x.x.y point release, it’s probably something that changed as of 5.16.

So: What changed? Well, here’s an article with info:

It does change AMD drivers a good bit and even has DisplayPort 2.0 changes (which means they might’ve touched code for initializing DisplayPort output, which could have possibly also affected HDMI output too).

It’s definitely possible that there is a kernel regression in video support that might hit some of us more than others.

3

There seems to be another problem with AMD graphics initialization over @ mon/el8-carla-bridges

It might be related.

The issue for that is filed @ 2063351 – amdgpu driver fails to initialize the Ryzen 5600G APU when DPM is turned off

Note: I can’t even get kernel logs as my disk is encrypted, so I can’t type the password to get it to boot enough to log, so I’m literally working in the dark (as the screen is off), just guessing a bunch when this does happen.

4

I did have issues with rhgb removed… so that has nothing to do with it.

However, I assumed my gpu just didn’t work and everything else would work, so I typed in my password and it looks like it booted. I had to hard-poweroff of course.

Looking at the logs, I see this on my current boot (which worked):

May 11 18:06:05 fedora kernel: fbcon: Deferring console take-over
May 11 18:06:08 fedora kernel: fbcon: amdgpudrmfb (fb0) is primary device
May 11 18:06:08 fedora kernel: fbcon: Deferring console take-over

So, looking specifically for fb0, I see this on the broken boot:

May 11 18:00:05 fedora kernel: simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device

And this on the working boot:

May 11 18:06:05 fedora kernel: simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device
May 11 18:06:08 fedora kernel: fbcon: amdgpudrmfb (fb0) is primary device
May 11 18:06:08 fedora kernel: amdgpu 0000:0b:00.0: [drm] fb0: amdgpudrmfb frame buffer device

Looking at boot -1 (previous boot, which failed), I saw this:

May 11 18:00:05 fedora kernel: fbcon: Deferring console take-over
May 11 18:00:05 fedora kernel: fbcon: Taking over console

So this means bad boot is using simple-framebuffer instead of amdgpudrmfb (bad boot)… But why?

Is this a race condition where sometimes one wins versus the other? If it is a race condition, I wonder if passing something like video=simplefb:off to the grub command to load the Linux kernel might be a workaround to reliably get amdgpudrmfb?

Or it could be related to Fedora 36’s framebuffer changes, such as the ones mentioned @ Flickerfree boot broken with new kernels using simpledrm as initial framebuffer (#167) · Issues · plymouth / plymouth · GitLab ? And the Arch kernel thing you’re experiencing might be different?

5

Hello Garrett,

thank you for your detailed response. Honestly I am still unsure if yours and mine is the same issue - I believe I get that problem all the time (as soon as I move to a distribution with a more recent kernel) so I am becoming a bit dubious.

Also, I think the computer is still “up” - not sure if Fedora live CD enables SSH on first boot or something so cannot really prove it but on Arch the system was indeed reachable remotely.

The logs - I might make a quick comparison when the PC is up. Please note that at the moment (and most of the time actually) I can only reach it remotely. And while I could still swap kernels, test grub parameters and reboot the system at will I’d rather do that when I am physically at the computer (makes fixing a “bit” easier).

I will post an update if I have something new.

Cheers, jose

6

Hey Jose,

Yeah, it’s possibly a different issue, even if we have the same symptoms. (I guess mine’s intermittent whereas yours is constant though?)

I happen to have two monitors and an extra HDMI cable that’s not in use, so I ran a little experiment last night: Main monitor over DisplayPort (as before) and secondary monitor with HDMI. Both worked at the same time in some reboots, sometimes only the secondary monitor over HDMI would work.

So this confirms it enough for me that the problem most likely isn’t with my new system (whew) or even with Fedora (for me), but with my main monitor and/or cable. (And it’s probably the cable. At least I hope. Cables are much cheaper. :grin:)

I’ve ordered a new DisplayPort cable; it’s one that is VESA certified, can do 8K at some absurdly high hertz, and has tons of great reviews. It’s overkill for my 1440p @ 60hz monitor, but should support chaining the monitors fine… and the higher specs means it’s more likely to have fewer problems, as there’s more than enough room for overhead.

I think I was basically using a pack-in DisplayPort cable from over a decade ago and it was just barely enough to usually support the new monitor and daisy chaining, but not always. And it would explain why I had to disconnect/reconnect my laptop sometimes to get the displays working. (I thought it was related to the dock, not the cable. Whoops.)

For your issue, it’s probably something else as it does seem to be kernel specific. It probably doesn’t hurt to test another HDMI cable if you have a spare or can swap them around, just to be sure though (as it’s likely the code for initializing the screen has been touched in 5.16.x, even for HDMI, and perhaps it’s now just pickier with your hardware). It’s probably not the cable for you, but it’s still good to eliminate that as an issue.

TL;DR: My issue looks likely caused by the cable. I ordered a new one to test. I’ll let you know if that’s it or if something else might be happening.

7

I have the new cable and realized I also had another DisplayPort cable (in use) I could use for testing (after unplugging and rearranging things).

Same problem, sadly. The problem I’m seeing isn’t the DisplayPort cable (unless all of them from different manufacturers over time are all somewhat bad, which is very unlikely). So you and I are likely seeing the same problem… except that I do have it working sometimes, even though it doesn’t work a lot of the time.

8

I found an issue where link negotiating is broken for AMD GPUs @

It doesn’t match up perfectly with our issue, but might be close enough that it could be the same thing. It talks about general AMD initialization and links to a patch @ kernel/git/torvalds/linux.git - Linux kernel source tree.

One of the comments says:

5.16.0-rc5 works.

5.17.1 fails

5.18.0-rc3 works.

Fedora 36 is on 5.17.6-300.fc36.x86_64.

However, rawhide is on a 5.18.0-rc6 snapshot:

  kernel 5.17.6-300.fc36 -> 5.18.0-0.rc6.20220511gitfeb9c5e19e913b5.50.fc37

So I’ve rebased to rawhide (as I’m on Silverblue) and will test it out.

If that change does fix it, then a new kernel will sort out our problems. Thankfully, Fedora does upgrade kernels even in the same major release, so it should be fixed in Fedora 36 if this is the problem. I’ll test it here and see what happens.

Update: I still experienced the issue on rawhide with 5.18.0-0.rc6. :person_shrugging: I don’t know what’s up. I’ll keep trying things and looking for fixes or at least some workarounds. (HDMI seems to be reliable here, whereas DisplayPort is not very reliable.)

9

Thank you - again - for sharing your findings. I will retest when I am the computer and put some updates here.

1 Like
10

Hello again,
I updated the Arch Linux system and now I am running kernel 5.18.14 without issues (100% success in approx. 6-7 boots). Not exactly sure what happened there but perhaps Fedora runs better on the same or newer kernel version?