Kernels >= 6.3 disable video output

Kernels >= 6.3 disable video output

[Steven J Abner]

 AMD 2400g, Zen1, 'Raven' firmware, igpu, no card.
Code that was added to 6.2.16 to create 6.3 and up, to last tested 
6.13.4, breaks the igpu for Ryzen. Kernels with firmware, same as that 
used on 6.3 and up, works 100% on 5.4 to 6.2.16. This bug is even in a 
Debian/Ubuntu based OS's Mainline download of 6.8 (only mainline 
tested). Without using firmware, allowing fbdev drivers to control 
output to monitor, 6.13.4 works.
 The bug is that about 70% of the time, with firmware, the output to 
the monitor is shut off. The monitor displays no input connection. With 
no monitor the Linux console works the same as monitor connected. Both 
blanked and displayed have:
 > [ 0.000000] Linux version 6.13.4 (root@steven-ryzen) (gcc (GCC) 
14.2.0, GNU ld (GNU Binutils) 2.44) #1 SMP PREEMPT_DYNAMIC Thu May 8 
13:55:46 EDT 2025
 > [ 0.310823] ACPI: bus type drm_connector registered
 > [ 0.310837] [drm] amdgpu kernel modesetting enabled.
 > [ 0.310975] [drm] initializing kernel modesetting (RAVEN 
0x1002:0x15DD 0x1002:0x15DD 0xC6).
 > [ 0.310989] [drm] register mmio base: 0xFC900000
 > [ 0.310994] [drm] register mmio size: 524288
 > [ 0.311024] [drm] add ip block number 0 <soc15_common>
 > [ 0.311029] [drm] add ip block number 1 <gmc_v9_0>
 > [ 0.311034] [drm] add ip block number 2 <vega10_ih>
 > [ 0.311039] [drm] add ip block number 3 <psp>
 > [ 0.311043] [drm] add ip block number 4 <powerplay>
 > [ 0.311047] [drm] add ip block number 5 <dm>
 > [ 0.311052] [drm] add ip block number 6 <gfx_v9_0>
 > [ 0.311057] [drm] add ip block number 7 <sdma_v4_0>
 > [ 0.311061] [drm] add ip block number 8 <vcn_v1_0>
 > [ 0.334228] [drm] BIOS signature incorrect 0 0
 > [ 0.334251] amdgpu 0000:0e:00.0: amdgpu: Fetched VBIOS from ROM BAR
 > [ 0.334258] amdgpu: ATOM BIOS: 113-RAVEN-113
 > [ 0.334554] amdgpu 0000:0e:00.0: vgaarb: deactivate vga console
 > [ 0.334560] amdgpu 0000:0e:00.0: amdgpu: Trusted Memory Zone (TMZ) 
feature enabled
 > [ 0.334585] [drm] vm size is 262144 GB, 4 levels, block size is 
9-bit, fragment size is 9-bit
 > [ 0.334596] amdgpu 0000:0e:00.0: amdgpu: VRAM: 2048M 
0x000000F400000000 - 0x000000F47FFFFFFF (2048M used)
 > [ 0.334604] amdgpu 0000:0e:00.0: amdgpu: GART: 1024M 
0x0000000000000000 - 0x000000003FFFFFFF
 > [ 0.334615] [drm] Detected VRAM RAM=2048M, BAR=2048M
 > [ 0.334619] [drm] RAM width 128bits DDR4
 > [ 0.334722] [drm] amdgpu: 2048M of VRAM memory ready
 > [ 0.334727] [drm] amdgpu: 2923M of GTT memory ready.
 > [ 0.334742] [drm] GART: num cpu pages 262144, num gpu pages 262144
 > [ 0.334877] [drm] PCIE GART of 1024M enabled.
 > [ 0.334881] [drm] PTB located at 0x000000F400A00000
 > [ 0.335145] amdgpu: hwmgr_sw_init smu backed is smu10_smu
 > [ 0.335578] [drm] Found VCN firmware Version ENC: 1.15 DEC: 3 VEP: 0 
Revision: 0
 > [ 0.356133] amdgpu 0000:0e:00.0: amdgpu: reserve 0x400000 from 
0xf47fc00000 for PSP TMR
 > [ 0.428083] amdgpu 0000:0e:00.0: amdgpu: RAS: optional ras ta ucode 
is not available
 > [ 0.434083] amdgpu 0000:0e:00.0: amdgpu: RAP: optional rap ta ucode 
is not available
 > [ 0.434090] amdgpu 0000:0e:00.0: amdgpu: SECUREDISPLAY: 
securedisplay ta ucode is not available
 > [ 0.434559] [drm] DM_PPLIB: values for F clock
 > [ 0.434564] [drm] DM_PPLIB: 1633000 in kHz, 4399 in mV
 > [ 0.434570] [drm] DM_PPLIB: values for DCF clock
 > [ 0.434574] [drm] DM_PPLIB: 300000 in kHz, 3649 in mV
 > [ 0.434578] [drm] DM_PPLIB: 600000 in kHz, 4074 in mV
 > [ 0.434583] [drm] DM_PPLIB: 626000 in kHz, 4250 in mV
 > [ 0.434587] [drm] DM_PPLIB: 654000 in kHz, 4399 in mV
 > [ 0.435247] [drm] Display Core v3.2.310 initialized on DCN 1.0
 > [ 0.504716] [drm] kiq ring mec 2 pipe 1 q 0
 > [ 0.518487] amdgpu 0000:0e:00.0: amdgpu: SE 1, SH per SE 1, CU per 
SH 11, active_cu_number 11
 > [ 0.518497] amdgpu 0000:0e:00.0: amdgpu: ring gfx uses VM inv eng 0 
on hub 0
 > [ 0.518503] amdgpu 0000:0e:00.0: amdgpu: ring comp_1.0.0 uses VM inv 
eng 1 on hub 0
 > [ 0.518510] amdgpu 0000:0e:00.0: amdgpu: ring comp_1.1.0 uses VM inv 
eng 4 on hub 0
 > [ 0.518516] amdgpu 0000:0e:00.0: amdgpu: ring comp_1.2.0 uses VM inv 
eng 5 on hub 0
 > [ 0.518523] amdgpu 0000:0e:00.0: amdgpu: ring comp_1.3.0 uses VM inv 
eng 6 on hub 0
 > [ 0.518530] amdgpu 0000:0e:00.0: amdgpu: ring comp_1.0.1 uses VM inv 
eng 7 on hub 0
 > [ 0.518536] amdgpu 0000:0e:00.0: amdgpu: ring comp_1.1.1 uses VM inv 
eng 8 on hub 0
 > [ 0.518543] amdgpu 0000:0e:00.0: amdgpu: ring comp_1.2.1 uses VM inv 
eng 9 on hub 0
 > [ 0.518549] amdgpu 0000:0e:00.0: amdgpu: ring comp_1.3.1 uses VM inv 
eng 10 on hub 0
 > [ 0.518556] amdgpu 0000:0e:00.0: amdgpu: ring kiq_0.2.1.0 uses VM 
inv eng 11 on hub 0
 > [ 0.518562] amdgpu 0000:0e:00.0: amdgpu: ring sdma0 uses VM inv eng 
0 on hub 8
 > [ 0.518569] amdgpu 0000:0e:00.0: amdgpu: ring vcn_dec uses VM inv 
eng 1 on hub 8
 > [ 0.518575] amdgpu 0000:0e:00.0: amdgpu: ring vcn_enc0 uses VM inv 
eng 4 on hub 8
 > [ 0.518581] amdgpu 0000:0e:00.0: amdgpu: ring vcn_enc1 uses VM inv 
eng 5 on hub 8
 > [ 0.518588] amdgpu 0000:0e:00.0: amdgpu: ring jpeg_dec uses VM inv 
eng 6 on hub 8
 > [ 0.521453] amdgpu: pp_dpm_get_sclk_od was not implemented.
 > [ 0.521460] amdgpu: pp_dpm_get_mclk_od was not implemented.
 > [ 0.521565] amdgpu 0000:0e:00.0: amdgpu: Runtime PM not available
 > [ 0.521868] [drm] Initialized amdgpu 3.60.0 for 0000:0e:00.0 on 
minor 0
 > [ 0.526617] fbcon: amdgpudrmfb (fb0) is primary device
 > [ 0.595813] Console: switching to colour frame buffer device 240x67
 > [ 0.628478] amdgpu 0000:0e:00.0: [drm] fb0: amdgpudrmfb frame buffer 
device

 I have no idea which code to regress to get back to 6.2.16 to make 
work again. From a quick look, that is the kernels where code was 
adopting new naming conventions for drivers, among tons of other 
changes. Think was also the start of PState default of 3, which setting 
to 1 made no difference, maybe lessened blackout closer to 50%?
Please help, I luv my 2400g! 6.1.137 is great and 5.15 is fine too. I 
still use 5.4 for testing my code too.
Steve
PS. please cc me, I'm not on the list referred by fb-dev.

Re: Kernels >= 6.3 disable video output

[Alex Deucher]

On Fri, May 9, 2025 at 3:43 AM Steven J Abner <pheonix.sja@att.net> wrote:
>
>  AMD 2400g, Zen1, 'Raven' firmware, igpu, no card.
> Code that was added to 6.2.16 to create 6.3 and up, to last tested
> 6.13.4, breaks the igpu for Ryzen. Kernels with firmware, same as that
> used on 6.3 and up, works 100% on 5.4 to 6.2.16. This bug is even in a
> Debian/Ubuntu based OS's Mainline download of 6.8 (only mainline
> tested). Without using firmware, allowing fbdev drivers to control
> output to monitor, 6.13.4 works.
>  The bug is that about 70% of the time, with firmware, the output to
> the monitor is shut off. The monitor displays no input connection. With
> no monitor the Linux console works the same as monitor connected. Both
> blanked and displayed have:
>  > [ 0.000000] Linux version 6.13.4 (root@steven-ryzen) (gcc (GCC)
> 14.2.0, GNU ld (GNU Binutils) 2.44) #1 SMP PREEMPT_DYNAMIC Thu May 8
> 13:55:46 EDT 2025
>  > [ 0.310823] ACPI: bus type drm_connector registered
>  > [ 0.310837] [drm] amdgpu kernel modesetting enabled.
>  > [ 0.310975] [drm] initializing kernel modesetting (RAVEN
> 0x1002:0x15DD 0x1002:0x15DD 0xC6).
>  > [ 0.310989] [drm] register mmio base: 0xFC900000
>  > [ 0.310994] [drm] register mmio size: 524288
>  > [ 0.311024] [drm] add ip block number 0 <soc15_common>
>  > [ 0.311029] [drm] add ip block number 1 <gmc_v9_0>
>  > [ 0.311034] [drm] add ip block number 2 <vega10_ih>
>  > [ 0.311039] [drm] add ip block number 3 <psp>
>  > [ 0.311043] [drm] add ip block number 4 <powerplay>
>  > [ 0.311047] [drm] add ip block number 5 <dm>
>  > [ 0.311052] [drm] add ip block number 6 <gfx_v9_0>
>  > [ 0.311057] [drm] add ip block number 7 <sdma_v4_0>
>  > [ 0.311061] [drm] add ip block number 8 <vcn_v1_0>
>  > [ 0.334228] [drm] BIOS signature incorrect 0 0
>  > [ 0.334251] amdgpu 0000:0e:00.0: amdgpu: Fetched VBIOS from ROM BAR
>  > [ 0.334258] amdgpu: ATOM BIOS: 113-RAVEN-113
>  > [ 0.334554] amdgpu 0000:0e:00.0: vgaarb: deactivate vga console
>  > [ 0.334560] amdgpu 0000:0e:00.0: amdgpu: Trusted Memory Zone (TMZ)
> feature enabled
>  > [ 0.334585] [drm] vm size is 262144 GB, 4 levels, block size is
> 9-bit, fragment size is 9-bit
>  > [ 0.334596] amdgpu 0000:0e:00.0: amdgpu: VRAM: 2048M
> 0x000000F400000000 - 0x000000F47FFFFFFF (2048M used)
>  > [ 0.334604] amdgpu 0000:0e:00.0: amdgpu: GART: 1024M
> 0x0000000000000000 - 0x000000003FFFFFFF
>  > [ 0.334615] [drm] Detected VRAM RAM=2048M, BAR=2048M
>  > [ 0.334619] [drm] RAM width 128bits DDR4
>  > [ 0.334722] [drm] amdgpu: 2048M of VRAM memory ready
>  > [ 0.334727] [drm] amdgpu: 2923M of GTT memory ready.
>  > [ 0.334742] [drm] GART: num cpu pages 262144, num gpu pages 262144
>  > [ 0.334877] [drm] PCIE GART of 1024M enabled.
>  > [ 0.334881] [drm] PTB located at 0x000000F400A00000
>  > [ 0.335145] amdgpu: hwmgr_sw_init smu backed is smu10_smu
>  > [ 0.335578] [drm] Found VCN firmware Version ENC: 1.15 DEC: 3 VEP: 0
> Revision: 0
>  > [ 0.356133] amdgpu 0000:0e:00.0: amdgpu: reserve 0x400000 from
> 0xf47fc00000 for PSP TMR
>  > [ 0.428083] amdgpu 0000:0e:00.0: amdgpu: RAS: optional ras ta ucode
> is not available
>  > [ 0.434083] amdgpu 0000:0e:00.0: amdgpu: RAP: optional rap ta ucode
> is not available
>  > [ 0.434090] amdgpu 0000:0e:00.0: amdgpu: SECUREDISPLAY:
> securedisplay ta ucode is not available
>  > [ 0.434559] [drm] DM_PPLIB: values for F clock
>  > [ 0.434564] [drm] DM_PPLIB: 1633000 in kHz, 4399 in mV
>  > [ 0.434570] [drm] DM_PPLIB: values for DCF clock
>  > [ 0.434574] [drm] DM_PPLIB: 300000 in kHz, 3649 in mV
>  > [ 0.434578] [drm] DM_PPLIB: 600000 in kHz, 4074 in mV
>  > [ 0.434583] [drm] DM_PPLIB: 626000 in kHz, 4250 in mV
>  > [ 0.434587] [drm] DM_PPLIB: 654000 in kHz, 4399 in mV
>  > [ 0.435247] [drm] Display Core v3.2.310 initialized on DCN 1.0
>  > [ 0.504716] [drm] kiq ring mec 2 pipe 1 q 0
>  > [ 0.518487] amdgpu 0000:0e:00.0: amdgpu: SE 1, SH per SE 1, CU per
> SH 11, active_cu_number 11
>  > [ 0.518497] amdgpu 0000:0e:00.0: amdgpu: ring gfx uses VM inv eng 0
> on hub 0
>  > [ 0.518503] amdgpu 0000:0e:00.0: amdgpu: ring comp_1.0.0 uses VM inv
> eng 1 on hub 0
>  > [ 0.518510] amdgpu 0000:0e:00.0: amdgpu: ring comp_1.1.0 uses VM inv
> eng 4 on hub 0
>  > [ 0.518516] amdgpu 0000:0e:00.0: amdgpu: ring comp_1.2.0 uses VM inv
> eng 5 on hub 0
>  > [ 0.518523] amdgpu 0000:0e:00.0: amdgpu: ring comp_1.3.0 uses VM inv
> eng 6 on hub 0
>  > [ 0.518530] amdgpu 0000:0e:00.0: amdgpu: ring comp_1.0.1 uses VM inv
> eng 7 on hub 0
>  > [ 0.518536] amdgpu 0000:0e:00.0: amdgpu: ring comp_1.1.1 uses VM inv
> eng 8 on hub 0
>  > [ 0.518543] amdgpu 0000:0e:00.0: amdgpu: ring comp_1.2.1 uses VM inv
> eng 9 on hub 0
>  > [ 0.518549] amdgpu 0000:0e:00.0: amdgpu: ring comp_1.3.1 uses VM inv
> eng 10 on hub 0
>  > [ 0.518556] amdgpu 0000:0e:00.0: amdgpu: ring kiq_0.2.1.0 uses VM
> inv eng 11 on hub 0
>  > [ 0.518562] amdgpu 0000:0e:00.0: amdgpu: ring sdma0 uses VM inv eng
> 0 on hub 8
>  > [ 0.518569] amdgpu 0000:0e:00.0: amdgpu: ring vcn_dec uses VM inv
> eng 1 on hub 8
>  > [ 0.518575] amdgpu 0000:0e:00.0: amdgpu: ring vcn_enc0 uses VM inv
> eng 4 on hub 8
>  > [ 0.518581] amdgpu 0000:0e:00.0: amdgpu: ring vcn_enc1 uses VM inv
> eng 5 on hub 8
>  > [ 0.518588] amdgpu 0000:0e:00.0: amdgpu: ring jpeg_dec uses VM inv
> eng 6 on hub 8
>  > [ 0.521453] amdgpu: pp_dpm_get_sclk_od was not implemented.
>  > [ 0.521460] amdgpu: pp_dpm_get_mclk_od was not implemented.
>  > [ 0.521565] amdgpu 0000:0e:00.0: amdgpu: Runtime PM not available
>  > [ 0.521868] [drm] Initialized amdgpu 3.60.0 for 0000:0e:00.0 on
> minor 0
>  > [ 0.526617] fbcon: amdgpudrmfb (fb0) is primary device
>  > [ 0.595813] Console: switching to colour frame buffer device 240x67
>  > [ 0.628478] amdgpu 0000:0e:00.0: [drm] fb0: amdgpudrmfb frame buffer
> device
>
>  I have no idea which code to regress to get back to 6.2.16 to make
> work again. From a quick look, that is the kernels where code was
> adopting new naming conventions for drivers, among tons of other
> changes. Think was also the start of PState default of 3, which setting
> to 1 made no difference, maybe lessened blackout closer to 50%?
> Please help, I luv my 2400g! 6.1.137 is great and 5.15 is fine too. I
> still use 5.4 for testing my code too.

What display(s) are you using and how are they connected?  Can you bisect?

Alex

Re: Kernels >= 6.3 disable video output

[Steven J Abner]

On Fri, May 9 2025 at 01:11:17 PM +0000, Alex Deucher 
<alexdeucher@gmail.com> wrote:
> What display(s) are you using and how are they connected?  Can you 
> bisect?

Not sure the question, but it's a tv thru HDMI.

Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
DisplayPort-0 disconnected primary (normal left inverted right x axis y 
axis)
HDMI-A-0 connected 1920x1080+0+0 (normal left inverted right x axis y 
axis) 575mm x 323mm
   1920x1080 60.00*+ 60.00 50.00 59.94 30.00 25.00 24.00 29.97 23.98

And hopefully to verify, 3 OSs run fine: Ubuntu/Elementary 5.4, PearlOS 
5.15, and LFS 5.15 thru 6.2.16. 6.3 and above has 70% fail rate with 
firmware built in to kernel, no fail if no firmware. Mainline 6.8 was 
on PearlOS.
Steve

Re: Kernels >= 6.3 disable video output

[Alex Deucher]

On Fri, May 9, 2025 at 9:39 AM Steven J Abner <pheonix.sja@att.net> wrote:
>
> On Fri, May 9 2025 at 01:11:17 PM +0000, Alex Deucher
> <alexdeucher@gmail.com> wrote:
> > What display(s) are you using and how are they connected?  Can you
> > bisect?
>
> Not sure the question, but it's a tv thru HDMI.
>
> Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
> DisplayPort-0 disconnected primary (normal left inverted right x axis y
> axis)
> HDMI-A-0 connected 1920x1080+0+0 (normal left inverted right x axis y
> axis) 575mm x 323mm
>    1920x1080 60.00*+ 60.00 50.00 59.94 30.00 25.00 24.00 29.97 23.98
>
> And hopefully to verify, 3 OSs run fine: Ubuntu/Elementary 5.4, PearlOS
> 5.15, and LFS 5.15 thru 6.2.16. 6.3 and above has 70% fail rate with
> firmware built in to kernel, no fail if no firmware. Mainline 6.8 was
> on PearlOS.

Is it specific to that particular TV or can you reproduce the problem
on other HDMI connected displays?  Can you narrow down where it broke?
 E.g., if 6.2.16 works, but 6.2.17 is broken, can you use git to
bisect between 6.2.16 and 6.2.17 to identify the commit which broke
it?

Alex

Re: Kernels >= 6.3 disable video output

[Steven J Abner]

On Fri, May 9 2025 at 02:05:16 PM +0000, Alex Deucher 
<alexdeucher@gmail.com> wrote:
> Can you narrow down where it broke?

 Have built kernels from 5.15 thru 6.2.16 (last of the 6.2 series), 
have no issues, ran Xorg server as test. Kernels 6.13.4 down to 6.3 
builds, more builds focused in the 6.3 series, have the 70% failure 
rate of monitor saying "no input", not just the normal blackout you can 
get from a bad configure setting. Kernel runs of 6.3 thru 6.13.4, on 
igpu disconnect, will perform the normal console functions of login, 
password, reboot and message sending via redirect, along with full 
/var/log files logging up to rebooting.
 Initial build, started with 6.13.4, had this bug detected prior to 
even install of any other software, Xorg, mesa or gdb. All other 
kernels had Xorg/mesa added, gdb was added after decided 6.1.137 would 
be base, cause it works and hopefully not the last LTS that will 
(6.6.89 fails, 70% blackouts).
Steve

Re: Kernels >= 6.3 disable video output

[Steven J Abner]

On Fri, May 9 2025 at 02:05:16 PM +0000, Alex Deucher 
<alexdeucher@gmail.com> wrote:
> bisect between 6.2.16 and 6.2.17 to identify the commit which broke

 Are you asking for a 'diff' output of drm and amdgpu directories 
between 6.2.16 (last of the 6.2 series) and 6.3 (start of the 6.3 
series)? I can and will if you want it.
Steve

Re: Kernels >= 6.3 disable video output

[Steven J Abner]

On Fri, May 9 2025 at 03:01:13 PM +0000, Steven J Abner 
<pheonix.sja@att.net> wrote:
> On Fri, May 9 2025 at 02:05:16 PM +0000, Alex Deucher 
> <alexdeucher@gmail.com> wrote:
>> bisect between 6.2.16 and 6.2.17 to identify the commit which broke
> 
> Are you asking for a 'diff' output of drm and amdgpu directories 
> between 6.2.16 (last of the 6.2 series) and 6.3 (start of the 6.3 
> series)?

 I'm willing to revert/test code on my machine, problem is I don't know 
sequence nor what I can safely revert. I haven't messed with video 
drivers/code since DOS days of having to write ones own graphics 
routines. I could force? kernel to build with '-g' on drm/amdgpu? and 
walk it I guess. But don't know what I'm looking for. :(
Steve

Re: Kernels >= 6.3 disable video output

[Alex Deucher]

On Mon, May 12, 2025 at 4:07 PM Steven J Abner <pheonix.sja@att.net> wrote:
>
> On Fri, May 9 2025 at 03:01:13 PM +0000, Steven J Abner
> <pheonix.sja@att.net> wrote:
> > On Fri, May 9 2025 at 02:05:16 PM +0000, Alex Deucher
> > <alexdeucher@gmail.com> wrote:
> >> bisect between 6.2.16 and 6.2.17 to identify the commit which broke
> >
> > Are you asking for a 'diff' output of drm and amdgpu directories
> > between 6.2.16 (last of the 6.2 series) and 6.3 (start of the 6.3
> > series)?
>
>  I'm willing to revert/test code on my machine, problem is I don't know
> sequence nor what I can safely revert. I haven't messed with video
> drivers/code since DOS days of having to write ones own graphics
> routines. I could force? kernel to build with '-g' on drm/amdgpu? and
> walk it I guess. But don't know what I'm looking for. :(

See:
https://docs.kernel.org/admin-guide/bug-bisect.html
If you know a good and bad point on a particular kernel branch, you
can use git to bisect the tree and identify the exact commit which
broke caused your issue.

Alex

> Steve
>
>

Re: Kernels >= 6.3 disable video output

[Steven J Abner]

On Mon, May 12 2025 at 08:10:40 PM +0000, Alex Deucher 
<alexdeucher@gmail.com> wrote:
> See:
> https://docs.kernel.org/admin-guide/bug-bisect.html
> ... identify the exact commit which broke caused your issue.

 One heck of a journey! But tested the solution on the first broken 
kernel 6.3. Too chicken to force revert attempts of 6.12 and 6.6 since 
I really didn't understand why revert spewed out 'nah-ah' for a one 
liner. 6.3 passed simple test of no blackouts for 8 in a row boots.
 Firstly let me qualify the revert, cause it's how i got it to work:
git show c76e483cd9163138e8fc44d829c986819f072d4f | patch --fuzz=999 
-p1 -R
 It seems simple enough of code which appears to set 8 bits of color 
for rgb as maximum, but with struct changes and me having a 
'historical' processor :) didn't want to have a non-expert speak that 
this is the full solution.
 Also note that I didn't 100% follow the bug-bisect guide as mine was 
apparently a unique situation where it had to first learn to connect to 
the internet and I don't use intrd images among other oddities. Also 
did this from last working kernel (6.2.16) to verify it was the last. 
PS had to patch amdgpu Makefile to allow the 6.2 series to compile with 
new gcc (-Wno-error).
 If need other info or need me to test actual patched 'upstream' 
kernel, I'm here.
Thank you!
Steve

Re: Kernels >= 6.3 disable video output

[Alex Deucher]

+ Harry

On Thu, May 15, 2025 at 12:11 PM Steven J Abner <pheonix.sja@att.net> wrote:
>
> On Mon, May 12 2025 at 08:10:40 PM +0000, Alex Deucher
> <alexdeucher@gmail.com> wrote:
> > See:
> > https://docs.kernel.org/admin-guide/bug-bisect.html
> > ... identify the exact commit which broke caused your issue.
>
>  One heck of a journey! But tested the solution on the first broken
> kernel 6.3. Too chicken to force revert attempts of 6.12 and 6.6 since
> I really didn't understand why revert spewed out 'nah-ah' for a one
> liner. 6.3 passed simple test of no blackouts for 8 in a row boots.
>  Firstly let me qualify the revert, cause it's how i got it to work:
> git show c76e483cd9163138e8fc44d829c986819f072d4f | patch --fuzz=999
> -p1 -R
>  It seems simple enough of code which appears to set 8 bits of color
> for rgb as maximum, but with struct changes and me having a
> 'historical' processor :) didn't want to have a non-expert speak that
> this is the full solution.
>  Also note that I didn't 100% follow the bug-bisect guide as mine was
> apparently a unique situation where it had to first learn to connect to
> the internet and I don't use intrd images among other oddities. Also
> did this from last working kernel (6.2.16) to verify it was the last.
> PS had to patch amdgpu Makefile to allow the 6.2 series to compile with
> new gcc (-Wno-error).
>  If need other info or need me to test actual patched 'upstream'
> kernel, I'm here.
> Thank you!
> Steve
>
>

Re: Kernels >= 6.3 disable video output

[Harry Wentland]

Hi Steven,

thanks for the bisect.

In order to avoid display artifacts (especially for HDR) we had to
allow higher bit depth color output on the wire. The driver should
fallback to a lower resolution as needed but looks like there's a
bug with this particular TV. Are you able to share the specific
TV model? We haven't seen this bug in internal testing but if we
know which device shows the issue we might be able to find one
for testing.

It would probably be good if we had a module parameter to force
limit the output bpc in order to unblock users (like you) that see
issues.

Harry

On 2025-05-15 12:16, Alex Deucher wrote:
> + Harry
> 
> On Thu, May 15, 2025 at 12:11 PM Steven J Abner <pheonix.sja@att.net> wrote:
>>
>> On Mon, May 12 2025 at 08:10:40 PM +0000, Alex Deucher
>> <alexdeucher@gmail.com> wrote:
>>> See:
>>> https://docs.kernel.org/admin-guide/bug-bisect.html
>>> ... identify the exact commit which broke caused your issue.
>>
>>  One heck of a journey! But tested the solution on the first broken
>> kernel 6.3. Too chicken to force revert attempts of 6.12 and 6.6 since
>> I really didn't understand why revert spewed out 'nah-ah' for a one
>> liner. 6.3 passed simple test of no blackouts for 8 in a row boots.
>>  Firstly let me qualify the revert, cause it's how i got it to work:
>> git show c76e483cd9163138e8fc44d829c986819f072d4f | patch --fuzz=999
>> -p1 -R
>>  It seems simple enough of code which appears to set 8 bits of color
>> for rgb as maximum, but with struct changes and me having a
>> 'historical' processor :) didn't want to have a non-expert speak that
>> this is the full solution.
>>  Also note that I didn't 100% follow the bug-bisect guide as mine was
>> apparently a unique situation where it had to first learn to connect to
>> the internet and I don't use intrd images among other oddities. Also
>> did this from last working kernel (6.2.16) to verify it was the last.
>> PS had to patch amdgpu Makefile to allow the 6.2 series to compile with
>> new gcc (-Wno-error).
>>  If need other info or need me to test actual patched 'upstream'
>> kernel, I'm here.
>> Thank you!
>> Steve
>>
>>

Re: Kernels >= 6.3 disable video output

[Steven J Abner]

On Thu, May 15 2025 at 05:59:55 PM +0000, Harry Wentland 
<harry.wentland@amd.com> wrote:
> Are you able to share the specific TV model?

 From TV itself: Sansui S55VAUG. From System info within tv menu: 
Settings: Device Name: GoogleTV8931 Model: Apollo Premium 4KTV
 from cat /sys/class/drm/card0/card0-HDMI-A-1/edid:
binary stuff with words 'AndroidTV' embedded.
 TV's only about 6 months old and MicroCenter offers them.
Steve

Re: Kernels >= 6.3 disable video output

[Michel Dänzer]

On 2025-05-15 19:59, Harry Wentland wrote:
> Hi Steven,
> 
> thanks for the bisect.
> 
> In order to avoid display artifacts (especially for HDR) we had to
> allow higher bit depth color output on the wire. The driver should
> fallback to a lower resolution as needed but looks like there's a
> bug with this particular TV. Are you able to share the specific
> TV model? We haven't seen this bug in internal testing but if we
> know which device shows the issue we might be able to find one
> for testing.
> 
> It would probably be good if we had a module parameter to force
> limit the output bpc in order to unblock users (like you) that see
> issues.
FWIW, with GNOME the "max bpc" property value can be set per monitor in the ~/.config/monitors.xml file. Other DEs might have something similar (with Xorg, it should even be possible to set it with xrandr).


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast

Re: Kernels >= 6.3 disable video output

[Steven J Abner]

On Fri, May 16 2025 at 03:02:47 PM +0000, Michel Dänzer 
<michel.daenzer@mailbox.org> wrote:
> FWIW, with GNOME the "max bpc" property value can be set

 Issue is pre-DE, gnome or Xorg. A boot param like 
'amd_prefcore=disable' could work. Issue then becomes putting into 
dmesg so can figure its needed. Blacked out console hard to read. A 
chroot or mount access to /var/log/... easy to find issue that way.

Re: Kernels >= 6.3 disable video output

[Steven J Abner]

On Fri, May 16 2025 at 03:38:04 PM +0000, Steven J Abner 
<pheonix.sja@att.net> wrote:
> A boot param like 'amd_prefcore=disable' could work

But kinda a band aid. What if you just download a Mainline kernel (as I 
did to verify not a build/configure issue). Writing bug report to OS 
provider could take a while for them to figure out what the issue is.