Description of problem: This bug is meant to be a clarification of Bug 26994. Affected hardware: Dell Dimension e520, Core2Quad Q6600, 4GB RAM, AMD HD 8570 GPU, rtl8192cu wifi dongle, 32-bit Plasma system. (Though I believe this would affect a 64-bit system as well.) When the boot process reaches the sddm login screen, almost everything is frozen. The cursor moves with the mouse, but there is no response to mouse clicks, or to any keyboard input. The only way out is to press the power button. If the user uses a different DM, or sets up autologin, or boots into runlevel 3 and then uses the "startx" the Plasma desktop will come up and there is no further evidence of a problem until the next boot. If the user switches to the Vesa driver, the sddm login is responsive - though with the performance problems that would be associated with that driver. Another set of hardware, AMD Phenom II, 8GB RAM, AMD HD 8490 graphics, does not show any problem. This issue was first noticed when testing the Mageia 8 beta1 isos, at which time Cauldron was showing the same behavior as Mageia 7. Since then, Cauldron still shows the issue, but the symptoms are much worse. (Bug 28154)
Created attachment 12230 [details] lspcidrake output of the affected hardware
Created attachment 12231 [details] dmesg output after a successful boot
Created attachment 12232 [details] Log of an unsuccessful boot
Created attachment 12233 [details] log of a successful boot - runlevel 3 login followed by "startx"
Created attachment 12234 [details] xorg.conf of the affected system
*** Bug 26994 has been marked as a duplicate of this bug. ***
Also see bug#28024 .
CC: (none) => ftg
Thank you for the report & all the supporting evidence. (In reply to Thomas Andrews from comment #1) > lspcidrake output of the affected hardware Just for info: In video cases, normally 'lspci -v' and post *just* the VGA section suffices. It gives much better information than bare lspci. Also, 'inxi -SGxx' provides a neat system & graphics summary. All these bugs around the same problem. Is it SDDM (KDE) or hardware (kernel/drivers)? Assigning to the former for starters, they can judge; CC'ing the latter.
Assignee: bugsquad => kdeTarget Milestone: --- => Mageia 8CC: (none) => kernelVersion: 7 => Cauldron
(In reply to Lewis Smith from comment #8) > Thank you for the report & all the supporting evidence. > > (In reply to Thomas Andrews from comment #1) > > lspcidrake output of the affected hardware > Just for info: > In video cases, normally 'lspci -v' and post *just* the VGA section > suffices. It gives much better information than bare lspci. > Also, 'inxi -SGxx' provides a neat system & graphics summary. > Nope. we _always_ want "lspcidrake -v" as that shows both pci ids, and what driver drakx is trying to map it to.
Same problem is with ryzen4500 notebook from kernel 5.9 Temporary solution is restart Xserver with ctrl+alt+backspace, when is hang with cursor. I mean same problem is with detection external monitor (in docking station) in booting konsole. After is starting xserver, detection working weri well.
CC: (none) => pavlikd
(In reply to Dusan Pavlik from comment #10) > Same problem is with ryzen4500 notebook from kernel 5.9 > > Temporary solution is restart Xserver with ctrl+alt+backspace, when is hang > with cursor. > > I mean same problem is with detection external monitor (in docking station) > in booting konsole. After is starting xserver, detection working weri well. Unfortunately, in this case, ctrl+alt+backspace doesn't do anything. I tried it, repeatedly. Perhaps that has something to do with the mouse and keyboard both being wireless, controlled by the same Logitech "unifying" receiver, perhaps not. There are three temporary workaround solutions for this problem: 1) Boot run level 3, log in as a user, then run "startx." This can be used at every boot. 2) Once you reach a desktop, use MCC to set up auto-login. This bypasses the sddm login screen altogether. 3) Use a display manager other than sddm. I have used XDM and GDM. Both worked as expected.
For me it working on notebook. On me desktop I have RX5500 and I using SDDM. Log in is OK.
Without really knowing anything about how this could be determined, and based on experience with wifi devices, which probably is dangerous to apply here, I suspect that the "oland" firmware in radeon-firmware may very well be what is at fault. The HD 8570 is an "oland" chip. The HD 8490 is a "caicos" chip, and that works. And Dusan's RX5500 is a "navi" chip, which he says also works.
so you do have a conflict between old ati and new amdgpu Does it work if you edit xorg.conf, and in this section: Section "Device" Identifier "device1" VendorName "Advanced Micro Devices, Inc. [AMD/ATI]" BoardName "ATI Radeon HD 6400 and later (radeon/fglrx)" Driver "ati" Option "DPMS" EndSection change the Driver "ati" to Driver "amdgpu" and reboot ? does it work better then ?
Hm, last upgrade from 20.1.2021, repair starting login to SDDM.
Worse, much worse. That one change makes it stop before even getting to the login. I can still log in under run level 3, but "startx" crashes before it even begins. (Photo of the monitor to follow) Back in the early days of Mageia 7, or was it the late days of Mageia 6, when I first got this card, the system would want to use the ati driver. Same thing for the HD 8490 card. I thought that strange, since the MCC description puts the cutoff between the two drivers at something much lower than either. So, being curious, I tried each card with both drivers - and both of them worked. I couldn't see a difference in performance. Of course, much has changed since then.
(In reply to Dusan Pavlik from comment #15) > Hm, > > last upgrade from 20.1.2021, repair starting login to SDDM. I have seen mine work as it should, too - once in a while, maybe 10% of the time. The next boot would mess up again. No idea what might have been different when it worked.
Created attachment 12238 [details] screen photo of trying to startx with amdgpu driver
(In reply to Thomas Andrews from comment #16) > Worse, much worse. That one change makes it stop before even getting to the > login. I can still log in under run level 3, but "startx" crashes before it > even begins. (Photo of the monitor to follow) > > Yeah, sorry I forgot some bits... create a /etc/modprobe.d/amd.conf with the line: blacklist radeon then recreate the initrd with dracut -f and reboot... does it work then? if not, revert xorg.conf to ati, alter the /etc/modprobe.d/amd.conf to have blacklist amdgpu then recreate the initrd with dracut -f and reboot... does it work better then?
Blacklisting radeon got me nowhere. Just a black screen with an unresponsive flashing cursor at the top. Switching back to "ati" and blacklisting amdgpu didn't help, either. The sddm login comes up that way, but it's the same as I originally reported - unresponsive.
ok, I've submitted an sddm-0.19.0-5.mga8 to Cauldron Core Updates Testing. Can you try that one out to see if it helps with this
Uh, this bug is about Mageia 7. Is the mga8 sddm even going to work? Bug 28154 is the one I filed against Cauldron, because the symptoms are much worse and much more widespread. In that one, none of the RC Live isos but Gnome will boot into Live mode, and even Gnome freezes within a minute or two.
I didn't notice that Lewis had changed the release version, or I would have put it back.
Version: Cauldron => 7
ah, didn't see that this was mga7 first... did this start with kernel 5.10 series ?, meaning if you boot back to 5.7 series or older it would work again?
I'm not sure when it started. Soon after installing Mageia 7.1, I activated auto-login, and thus bypassed the problem for some time. I know it wasn't that way when Mageia 7.1 was installed. I didn't notice it until I installed Cauldron from a beta1 CI test iso, and it showed up there on the first boot. I investigated, and found that if I disabled auto-login my 32-bit Mageia 7 Plasma install on that hardware did the same thing.
The problem has existed at least since the Mageia 7.1 isos, as the Live Plasma refuses to boot into Live mode. I have changed the graphics driver to "amdgpu" (Volcanic Islands in drakx11), and as root created a text file named "amd.conf" in /etc/modprobe.d that contains the following lines: blacklist radeon options amdgpu cik_support=1 options amdgpu si_support=1 options radeon cik_support=0 options radeon si_support=0 After running "dracut -f" and rebooting, the problem disappears. The sddm login now works as it should.
Mageia 7 is EOL since July 1st 2021. There will not have any further bugfix for this release. You are encouraged to upgrade to Mageia 8 as soon as possible. @reporter, if this bug still apply with Mageia 8, please let us know it. @packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead. This bug report will be closed OLD if there is no further notice within 1st September 2021.
The problem was solved in Mageia 8 by changing the video driver for this class of Radeon gpus. The workaround described in Comment 26 does the same thing for Mageia 7. Closing this bug as "works for me"
Resolution: (none) => WORKSFORMEStatus: NEW => RESOLVED