Video signal lost after upgrading to Groovy

[DuckHook]

Brief update:

I've just tried the 5.10_RC1 kernel and it doesn't solve the problem for me. Part of the ongoing process of elimination.

[tea for one]

Out of curiosity - did you ever try a live session with Ubuntu 20.10?

[DuckHook]

Out of curiosity - did you ever try a live session with Ubuntu 20.10?

That was going to be my next project. I've been rather lackadaisical over this one because it really is just a tinkering partition, so I haven't pursued it very ardently, but I will be sure to post results when I do so.

[DuckHook]

…I will be sure to post results when I do so.

Final update:

I was never able to get Groovy to behave. A LiveUSB worked. But once installed as a virgin OS, the same problems emerged (requiring nomodeset to display, but even then generating a laundry list of nasty log errors that I was in no mood to chase down). With nothing left to lose (I had lost all my customizations with the virgin install), I took the big leap and upgraded to Hirsute. It now comes up fast and furious, so I am happy/relieved.

The problem has not been "solved" (since I never did get to the bottom of what was bugging out Groovy) so much as it has been "resolved" (through upgrading to the current developmental release), so I'm not going to mark this thread solved.

I will spend some time exploring Hirsute. As for Groovy, it will just be one of those releases that I skip.

[DuckHook]

Spoke far too soon. Hirsute misbehaves exactly like Groovy. I got to the DE the first time after upgrading, but not since. Continuing to diagnose.

[DuckHook]

After much trial and error, I've narrowed the issue down to the following. My video card drops its signal to my monitor, likely when the framebuffer kicks in. Though I have neutered both splash and quiet, the entries still race by so quickly that this is no more than an educated guess, but it conforms to that moment in the sequence when I boot my other 20.04 partition.

The salient info follows:

Driver: Radeon
Discrete video card:

duckhook@Zeus:~$ sudo lspci -vk | grep -iA20 vga
[sudo] password for duckhook: 
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti PRO [Radeon HD 7950/8950 OEM / R9 280] (prog-if 00 [VGA controller])
	Subsystem: Hightech Information System Ltd. Tahiti PRO [Radeon HD 7950/8950 OEM / R9 280]
	Flags: bus master, fast devsel, latency 0, IRQ 56
	Memory at d0000000 (64-bit, prefetchable) [size=256M]
	Memory at fbe00000 (64-bit, non-prefetchable) [size=256K]
	I/O ports at e000 [size=256]
	Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: [48] Vendor Specific Information: Len=08 <?>
	Capabilities: [50] Power Management version 3
	Capabilities: [58] Express Legacy Endpoint, MSI 00
	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Capabilities: [150] Advanced Error Reporting
	Capabilities: [270] Secondary PCI Express
	Capabilities: [2b0] Address Translation Service (ATS)
	Capabilities: [2c0] Page Request Interface (PRI)
	Capabilities: [2d0] Process Address Space ID (PASID)
	Kernel driver in use: radeon
	Kernel modules: radeon, amdgpu

Salient log items:

duckhook@Zeus:~$ sudo journalctl -b | grep radeon | grep kernel
Nov 15 18:49:01 Zeus kernel: [drm] radeon kernel modesetting enabled.
Nov 15 18:49:01 Zeus kernel: fb0: switching to radeondrmfb from EFI VGA
Nov 15 18:49:01 Zeus kernel: radeon 0000:01:00.0: vgaarb: deactivate vga console
Nov 15 18:49:01 Zeus kernel: radeon 0000:01:00.0: VRAM: 3072M 0x0000000000000000 - 0x00000000BFFFFFFF (3072M used)
Nov 15 18:49:01 Zeus kernel: radeon 0000:01:00.0: GTT: 2048M 0x00000000C0000000 - 0x000000013FFFFFFF
Nov 15 18:49:01 Zeus kernel: [drm] radeon: 3072M of VRAM memory ready
Nov 15 18:49:01 Zeus kernel: [drm] radeon: 2048M of GTT memory ready.
Nov 15 18:49:01 Zeus kernel: [drm] radeon: dpm initialized
Nov 15 18:49:01 Zeus kernel: radeon 0000:01:00.0: WB enabled
Nov 15 18:49:01 Zeus kernel: radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x00000000c0000c00 and cpu addr 0x00000000a217189e
Nov 15 18:49:01 Zeus kernel: radeon 0000:01:00.0: fence driver on ring 1 use gpu addr 0x00000000c0000c04 and cpu addr 0x0000000050fe85a6
Nov 15 18:49:01 Zeus kernel: radeon 0000:01:00.0: fence driver on ring 2 use gpu addr 0x00000000c0000c08 and cpu addr 0x0000000020952302
Nov 15 18:49:01 Zeus kernel: radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x00000000c0000c0c and cpu addr 0x000000009ceb52ec
Nov 15 18:49:01 Zeus kernel: radeon 0000:01:00.0: fence driver on ring 4 use gpu addr 0x00000000c0000c10 and cpu addr 0x0000000091a1317a
Nov 15 18:49:01 Zeus kernel: radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x0000000000075a18 and cpu addr 0x00000000fadfaf36
Nov 15 18:49:01 Zeus kernel: radeon 0000:01:00.0: fence driver on ring 6 use gpu addr 0x00000000c0000c18 and cpu addr 0x00000000176b3432
Nov 15 18:49:01 Zeus kernel: radeon 0000:01:00.0: fence driver on ring 7 use gpu addr 0x00000000c0000c1c and cpu addr 0x00000000a7719c7c
Nov 15 18:49:01 Zeus kernel: radeon 0000:01:00.0: radeon: MSI limited to 32-bit
Nov 15 18:49:01 Zeus kernel: radeon 0000:01:00.0: radeon: using MSI.
Nov 15 18:49:01 Zeus kernel: [drm] radeon: irq initialized.
Nov 15 18:49:04 Zeus kernel: [drm] Radeon Display Connectors
Nov 15 18:49:04 Zeus kernel: fbcon: radeondrmfb (fb0) is primary device
Nov 15 18:49:04 Zeus kernel: [drm:si_dpm_set_power_state [radeon]] *ERROR* si_restrict_performance_levels_before_switch failed
Nov 15 18:49:04 Zeus kernel: radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
Nov 15 18:49:04 Zeus kernel: [drm:radeon_dp_link_train_cr [radeon]] *ERROR* clock recovery tried 5 times
Nov 15 18:49:04 Zeus kernel: [drm:radeon_dp_link_train_cr [radeon]] *ERROR* clock recovery failed
Nov 15 18:49:04 Zeus kernel: [drm] Initialized radeon 2.50.0 20080528 for 0000:01:00.0 on minor 0

In summary:

1. The LiveUSB is just as problematic. No video signal without nomodeset.
2. Booting up with the old 5.4.x kernels works. It's the 5.8.x kernel series that causes the problem.
3. 5.10.x-RC kernels do not work either.
4. nomodeset always works. This is not surprising since it nerfs KMS.
5. The problem is only the video signal. I can ssh into the session just fine.
6. When comparing the logs between a successful older kernel and a problematic newer one, the only difference is this:

   Nov 15 18:49:04 Zeus kernel: [drm:radeon_dp_link_train_cr [radeon]] *ERROR* clock recovery tried 5 times
   Nov 15 18:49:04 Zeus kernel: [drm:radeon_dp_link_train_cr [radeon]] *ERROR* clock recovery failed

My Web Search Fu has deserted me. All I could find with respect to these errors were these slim pickings:

http://linux-kernel.2935.n7.nabble.c...td1320976.html
https://bugs.launchpad.net/ubuntu/+s...x/+bug/1579481
https://askubuntu.com/questions/1278...ank-2nd-screen
https://askubuntu.com/questions/1286...4-lts-to-20-10

It appears that the problem bites just a few others, and is a recurring one that has some history.

Perhaps the problem is just with my Tahiti chipset‑based card. I wanted to enquire on the Forums in case any of you have found a solution before starting a bug on Launchpad.

[DuckHook]

After more time and trouble than I thought I would ever invest into it, I've traced the problem back via mainline kernel bisection to some change made starting with the 5.5.6 kernel.

I have submitted the following bug report in LaunchPad: https://bugs.launchpad.net/ubuntu/+s...8/+bug/1904647

It states my findings there. No point in repeating it here. If anyone else has this same problem, please alert the devs that this bug effects multiple users via the above link.

[DuckHook]

Final update:

The problem remains frustratingly unresolved, but I have worked around it by giving up on the Display Port and using HDMI instead. For those stuck with only DP, I'm afraid there has been no action from the devs at Launchpad. I doubt that they see this as a high priority.