system starts, but display seems to deactivate

sukolyn · 2024-10-04 01:12:42

hi,

since last update (yesterday), my system starts : I see GrUB, some lines, and at the moment (I think) it loads the video driver, the screen goes black, and as it doesn't receive data it turns off.
after that, the boot seems to reach login on tty (as it's configured : no display manager, only TTY). I can blindly login, ~/.bashrc starts sx and I see the disk blinking as usual when the window manager loads, but the screen doesn't turn on anymore.

it's not a hardware problem, as I can use any other OS from liveUSB and every thing's fine
from lspci, video card is

VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos XT [Radeon HD 7470/8470 / R5 235/310 OEM]

what else do you need to make my system shows again ?

NB: I can login through ssh.

Last edited by sukolyn (2024-10-04 06:54:39)

sukolyn · 2024-10-04 09:41:32

here is pacman's log of latest update (grep '^\[2024-10-03T' /var/log/pacman.log) : http://0x0.st/XE8N.txt
as I didn't notice any kernel update, previous boot was sept. 26 21:15:59

do you need more infos ?

seth · 2024-10-04 12:13:18

do you need more infos ?
NB: I can login through ssh.

Please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

sukolyn · 2024-10-04 14:37:50

here it is : http://0x0.st/XEPG.txt

seth · 2024-10-04 16:01:24

"-b", you sent your entire journal since april…

oct. 04 16:22:22 archlinux kernel: radeon 0000:01:00.0: [drm] Cannot find any crtc or sizes
oct. 04 16:22:22 archlinux kernel: radeon 0000:01:00.0: [drm] Cannot find any crtc or sizes
oct. 04 16:22:22 archlinux kernel: radeon 0000:01:00.0: [drm] Cannot find any crtc or sizes

Test the LTS kernel, unfortunately Caicos is a northern island and not covered by the amdgpu module

Edit: for the 6.11 kernel and because of the problems along the nvidia driver

oct. 04 16:22:21 archlinux kernel: [drm] Initialized simpledrm 1.0.0 for simple-framebuffer.0 on minor 0

That's the simpledrm device, try to add "initcall_blacklist=simpledrm_platform_driver_init" to the https://wiki.archlinux.org/title/Kernel_parameters and see whether that avoids the issue.

Last edited by seth (2024-10-04 16:02:44)

sukolyn · 2024-10-04 17:44:53

"-b", you sent your entire journal since april…

oops. sorry.

initcall_blacklist doesn't change behaviour.

since I have another machine (it should be a "spare machine") with the same problem with another Radeon on which I could test further suggestions,
I could simply downgrade kernel (on my "main machine") to previous working version (pacman -U /var/cache/pacman/pkg/linux-6.10.10.arch1-1-x86_64.pkg.tar.zst), until next version corrects the problem. Does that sound reasonable ?

seth · 2024-10-04 20:03:23

It's probabaly easier to test/use the LTS kernel parallel to the main one to wait this out, but you might have to look into this yourself (with assistence) since the radeon module is probably no longer in widespread use.

sukolyn · 2024-10-04 20:31:57

use the LTS kernel parallel to the main one

does installing LTS kernel keep current kernel in place ? or is there something more than simply installing LTS to do to keep current kernel ?

the radeon module is probably no longer in widespread use.

and they removed it like that from the kernel ?!

Last edited by sukolyn (2024-10-04 20:34:24)

seth · 2024-10-04 20:33:10

does installing LTS kernel keep current kernel in place ?

yup, you'll still have to add it to your bootloader config, though.

sukolyn · 2024-10-04 22:23:59

hmm. doesn't seem "easier". I'm gonna give it a try, though.

thank you.

btw: I've already downgraded kernel on the "clone", and it simply works as usual, but I guess I'll have to downgrade every kernel's update until kernel's maintainers correct radeon module (if I understood well what's happening).

seth · 2024-10-05 06:39:41

You can add the kernel to the IgnorePkg list.
Using a second kernel is "easier" because you get to use it while testing the behavior of the main one w/ the next update w/o having to worry about downgrades (or forgetting to update b/c of IgnorePkg)

sukolyn · 2024-10-06 19:24:41

ok.
thank you.

I've installed linux-lts, but it removed vmlinuz and initramfs-linux{,-fallback}.img from /boot.
do I have to reinstall linux 6.11.2 with pacman -U ?

seth · 2024-10-06 19:35:33

You can just "pacman -S linux" to re-intall it, the install hook will call mkinitcpio which should™ restore kernel and initramfs.

sukolyn · 2024-10-06 20:31:06

ok, that did it.

thanks agains.

sukolyn · 2024-10-06 21:57:36

now, with LTS installed I've got time to prepare to next step. which is...

get a kernel parameter that disables simple-framebuffer*, to let fbdev do the job ?
get a new graphic card which supports simple-framebuffer ?

--
* btw, what does it do ? why does that appear now ? why not with every graphic card ?
edit: why does that affect Arch and not Ubuntu (didn't they enable simple-framebuffer in their kernel ? how to check ?)

Last edited by sukolyn (2024-10-06 22:06:56)

seth · 2024-10-07 07:42:01

First and foremost: the LTS kernel works as expected?
The difference between Arch and Ubuntu is most likely the kernel generation, this started w/ 6.11, right?
The simpledrm device is a fallback to allow you to run a display manager (wayland, X11 always had a VESA driver) in case your graphics driver is broken.
It's usually not meant to be used and typically gets replace when the actual driver inializes.
And it has a tendency to cause more harm than good.

Adding "initcall_blacklist=simpledrm_platform_driver_init" to the https://wiki.archlinux.org/title/Kernel_parameters will block it and the reference from #5 will not be in the journal, but according to #6 that did not address your problem.

Does kernel 6.11.2 still not work?

sukolyn · 2024-10-07 12:33:08

seth wrote:

the LTS kernel works as expected?

yes.

this started w/ 6.11, right?

right.

Does kernel 6.11.2 still not work?

yes, it doesn't work either.

seth · 2024-10-07 15:17:28

Good:

sept. 26 21:16:00 archlinux kernel: [drm] ib test on ring 5 succeeded
sept. 26 21:16:00 archlinux kernel: [drm] Radeon Display Connectors
sept. 26 21:16:00 archlinux kernel: [drm] Connector 0:
sept. 26 21:16:00 archlinux kernel: [drm]   HDMI-A-1
sept. 26 21:16:00 archlinux kernel: [drm]   HPD1
sept. 26 21:16:00 archlinux kernel: [drm]   DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c
sept. 26 21:16:00 archlinux kernel: [drm]   Encoders:
sept. 26 21:16:00 archlinux kernel: [drm]     DFP1: INTERNAL_UNIPHY1
sept. 26 21:16:00 archlinux kernel: [drm] Connector 1:
sept. 26 21:16:00 archlinux kernel: [drm]   DVI-I-1
sept. 26 21:16:00 archlinux kernel: [drm]   HPD4
sept. 26 21:16:00 archlinux kernel: [drm]   DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 0x645c
sept. 26 21:16:00 archlinux kernel: [drm]   Encoders:
sept. 26 21:16:00 archlinux kernel: [drm]     DFP2: INTERNAL_UNIPHY
sept. 26 21:16:00 archlinux kernel: [drm]     CRT1: INTERNAL_KLDSCP_DAC1
sept. 26 21:16:00 archlinux kernel: [drm] Initialized radeon 2.50.0 20080528 for 0000:01:00.0 on minor 0
sept. 26 21:16:00 archlinux kernel: [drm] fb mappable at 0xD0363000
sept. 26 21:16:00 archlinux kernel: [drm] vram apper at 0xD0000000
sept. 26 21:16:00 archlinux kernel: [drm] size 8294400
sept. 26 21:16:00 archlinux kernel: [drm] fb depth is 24
sept. 26 21:16:00 archlinux kernel: [drm]    pitch is 7680
sept. 26 21:16:00 archlinux kernel: fbcon: radeondrmfb (fb0) is primary device
sept. 26 21:16:00 archlinux kernel: Console: switching to colour frame buffer device 240x67
sept. 26 21:16:00 archlinux kernel: radeon 0000:01:00.0: [drm] fb0: radeondrmfb frame buffer device

sept. 26 21:15:59 archlinux kernel: simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device
sept. 26 21:16:00 archlinux kernel: fbcon: radeondrmfb (fb0) is primary device
sept. 26 21:16:00 archlinux kernel: radeon 0000:01:00.0: [drm] fb0: radeondrmfb frame buffer device

Bad:

oct. 04 16:22:22 archlinux kernel: [drm] ib test on ring 5 succeeded
oct. 04 16:22:22 archlinux kernel: [drm] Radeon Display Connectors
oct. 04 16:22:22 archlinux kernel: [drm] Connector 0:
oct. 04 16:22:22 archlinux kernel: [drm]   HDMI-A-1
oct. 04 16:22:22 archlinux kernel: [drm]   HPD1
oct. 04 16:22:22 archlinux kernel: [drm]   DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c
oct. 04 16:22:22 archlinux kernel: [drm]   Encoders:
oct. 04 16:22:22 archlinux kernel: [drm]     DFP1: INTERNAL_UNIPHY1
oct. 04 16:22:22 archlinux kernel: [drm] Connector 1:
oct. 04 16:22:22 archlinux kerne l: [drm]   DVI-I-1
oct. 04 16:22:22 archlinux kernel: [drm]   HPD4
oct. 04 16:22:22 archlinux kernel: [drm]   DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 0x645c
oct. 04 16:22:22 archlinux kernel: [drm]   Encoders:
oct. 04 16:22:22 archlinux kernel: [drm]     DFP2: INTERNAL_UNIPHY
oct. 04 16:22:22 archlinux kernel: [drm]     CRT1: INTERNAL_KLDSCP_DAC1
oct. 04 16:22:22 archlinux kernel: [drm] Initialized radeon 2.50.0 for 0000:01:00.0 on minor 0
oct. 04 16:22:22 archlinux kernel: radeon 0000:01:00.0: [drm] Cannot find any crtc or sizes
oct. 04 16:22:22 archlinux kernel: radeon 0000:01:00.0: [drm] Cannot find any crtc or sizes
oct. 04 16:22:22 archlinux kernel: radeon 0000:01:00.0: [drm] Cannot find any crtc or sizes

oct. 04 16:22:21 archlinux kernel: simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device

Can you please post a journal w/ 6.11 and the simplydumb™ device blacklisted?

sukolyn · 2024-10-07 17:12:07

journalctl.initcall_blacklist : http://0x0.st/XExG.txt

Linux version 6.11.2-arch1-1
Command line: ... initcall_blacklist=simpledrm_platform_driver_init
...
blacklisting initcall simpledrm_platform_driver_init
...
radeon 0000:01:00.0: [drm] Cannot find any crtc or sizes

journalctl.regular : http://0x0.st/XEx5.txt
almost the same without blacklisting simplefb.

Linux version 6.11.2-arch1-1
...
radeon 0000:01:00.0: [drm] Cannot find any crtc or sizes

seth · 2024-10-07 19:25:36

I'm more concerned about the complete absence of radeondrmfb as fb0

Do you get an output when booting "nomodeset"?
Do you have a display server on the system (X11)?
Does that activate the output?
Does this hinge on the presence of the xf86-video-ati package?

sukolyn · 2024-10-07 19:33:03

X11 is installed; spectrwm is launched using sx from TTY, but it doesn't activate the output.

xf86-video-ati is installed.

so.

nomodeset starts the kernel until having TTY, but I'm losing the resolution (it's written bigger than usual; I don't like that. )
X11 is 800x600, and xrandr doesn't show other resolutions. (I feel like 20 years back.)

with nomodeset lshw -c video shows no driver
without nomodeset : lshw -c video still shows that driver is radeon. 8O

I've removed xf86-video-ati with the same behaviour.

Last edited by sukolyn (2024-10-07 20:03:23)

seth · 2024-10-07 20:03:14

nomodeset starts the kernel until having TTY, but I'm losing the resolution (it's written bigger than usual; I don't like that. )
X11 is 800x600, and xrandr doesn't show other resolutions. (I feel like 20 years back.)

More like 30, VESA is from the mid-90ies and you're getting an 80x25 terminal, that's all expected.

zgrep -i radeon /proc/config.gz

Edit: this is most likely going to show

# CONFIG_FB_RADEON is not set

The idea would be to explicitly enable it, which will require a kernel rebuild.

Last edited by seth (2024-10-07 20:06:28)

sukolyn · 2024-10-07 20:23:10

here is in 6.11.2 :

$ zgrep -i radeon /proc/config.gz
CONFIG_DRM_RADEON=m
CONFIG_DRM_RADEON_USERPTR=y
# CONFIG_FB_RADEON is not set

it's the same output in 6.10.10

Last edited by sukolyn (2024-10-07 20:24:02)

seth · 2024-10-07 20:28:03

Yes, I know - the theory is that the default behavior has changed.

sukolyn · 2024-10-09 10:11:04

what the next step ?

Arch Linux

#1 2024-10-04 01:12:42

system starts, but display seems to deactivate

#2 2024-10-04 09:41:32

Re: system starts, but display seems to deactivate

#3 2024-10-04 12:13:18

Re: system starts, but display seems to deactivate

#4 2024-10-04 14:37:50

Re: system starts, but display seems to deactivate

#5 2024-10-04 16:01:24

Re: system starts, but display seems to deactivate

#6 2024-10-04 17:44:53

Re: system starts, but display seems to deactivate

#7 2024-10-04 20:03:23

Re: system starts, but display seems to deactivate

#8 2024-10-04 20:31:57

Re: system starts, but display seems to deactivate

#9 2024-10-04 20:33:10

Re: system starts, but display seems to deactivate

#10 2024-10-04 22:23:59

Re: system starts, but display seems to deactivate

#11 2024-10-05 06:39:41

Re: system starts, but display seems to deactivate

#12 2024-10-06 19:24:41

Re: system starts, but display seems to deactivate

#13 2024-10-06 19:35:33

Re: system starts, but display seems to deactivate

#14 2024-10-06 20:31:06

Re: system starts, but display seems to deactivate

#15 2024-10-06 21:57:36

Re: system starts, but display seems to deactivate

#16 2024-10-07 07:42:01

Re: system starts, but display seems to deactivate

#17 2024-10-07 12:33:08

Re: system starts, but display seems to deactivate

#18 2024-10-07 15:17:28

Re: system starts, but display seems to deactivate

#19 2024-10-07 17:12:07

Re: system starts, but display seems to deactivate

#20 2024-10-07 19:25:36

Re: system starts, but display seems to deactivate

#21 2024-10-07 19:33:03

Re: system starts, but display seems to deactivate

#22 2024-10-07 20:03:14

Re: system starts, but display seems to deactivate

#23 2024-10-07 20:23:10

Re: system starts, but display seems to deactivate

#24 2024-10-07 20:28:03

Re: system starts, but display seems to deactivate

#25 2024-10-09 10:11:04

Re: system starts, but display seems to deactivate

Board footer