Bug 28170 - sddm login screen freezing with the AMD HD 8570 GPU
Summary: sddm login screen freezing with the AMD HD 8570 GPU
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal normal
Target Milestone: Mageia 8
Assignee: KDE maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
: 26994 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-01-19 20:43 CET by Thomas Andrews
Modified: 2021-01-28 17:21 CET (History)
3 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments
lspcidrake output of the affected hardware (4.11 KB, text/plain)
2021-01-19 20:46 CET, Thomas Andrews
Details
dmesg output after a successful boot (66.17 KB, text/plain)
2021-01-19 20:47 CET, Thomas Andrews
Details
Log of an unsuccessful boot (138.74 KB, text/plain)
2021-01-19 20:48 CET, Thomas Andrews
Details
log of a successful boot - runlevel 3 login followed by "startx" (132.47 KB, text/plain)
2021-01-19 20:50 CET, Thomas Andrews
Details
xorg.conf of the affected system (3.24 KB, text/plain)
2021-01-19 20:51 CET, Thomas Andrews
Details
screen photo of trying to startx with amdgpu driver (857.09 KB, image/jpeg)
2021-01-21 19:31 CET, Thomas Andrews
Details

Description Thomas Andrews 2021-01-19 20:43:53 CET
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)
Comment 1 Thomas Andrews 2021-01-19 20:46:17 CET
Created attachment 12230 [details]
lspcidrake output of the affected hardware
Comment 2 Thomas Andrews 2021-01-19 20:47:28 CET
Created attachment 12231 [details]
dmesg output after a successful boot
Comment 3 Thomas Andrews 2021-01-19 20:48:39 CET
Created attachment 12232 [details]
Log of an unsuccessful boot
Comment 4 Thomas Andrews 2021-01-19 20:50:07 CET
Created attachment 12233 [details]
log of a successful boot - runlevel 3 login followed by "startx"
Comment 5 Thomas Andrews 2021-01-19 20:51:07 CET
Created attachment 12234 [details]
xorg.conf of the affected system
Comment 6 Thomas Andrews 2021-01-19 20:53:52 CET
*** Bug 26994 has been marked as a duplicate of this bug. ***
Comment 7 Frank Griffin 2021-01-19 21:01:21 CET
Also see bug#28024 .

CC: (none) => ftg

Comment 8 Lewis Smith 2021-01-19 21:39:23 CET
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 => kde
Target Milestone: --- => Mageia 8
CC: (none) => kernel
Version: 7 => Cauldron

Comment 9 Thomas Backlund 2021-01-19 21:42:46 CET
(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.
Comment 10 Dusan Pavlik 2021-01-20 05:54:51 CET
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

Comment 11 Thomas Andrews 2021-01-20 15:09:43 CET
(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.
Comment 12 Dusan Pavlik 2021-01-20 16:45:31 CET
For me it working on notebook.


On me desktop I have RX5500 and I using SDDM. Log in is OK.
Comment 13 Thomas Andrews 2021-01-20 17:36:25 CET
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.
Comment 14 Thomas Backlund 2021-01-21 18:02:05 CET
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 ?
Comment 15 Dusan Pavlik 2021-01-21 19:24:48 CET
Hm,

last upgrade from 20.1.2021, repair starting login to SDDM.
Comment 16 Thomas Andrews 2021-01-21 19:25:59 CET
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.
Comment 17 Thomas Andrews 2021-01-21 19:29:13 CET
(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.
Comment 18 Thomas Andrews 2021-01-21 19:31:13 CET
Created attachment 12238 [details]
screen photo of trying to startx with amdgpu driver
Comment 19 Thomas Backlund 2021-01-21 19:43:34 CET
(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?
Comment 20 Thomas Andrews 2021-01-22 16:25:51 CET
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.
Comment 21 Thomas Backlund 2021-01-22 17:44:36 CET
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
Comment 22 Thomas Andrews 2021-01-22 18:47:16 CET
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.
Comment 23 Thomas Andrews 2021-01-22 18:50:01 CET
I didn't notice that Lewis had changed the release version, or I would have put it back.

Version: Cauldron => 7

Comment 24 Thomas Backlund 2021-01-22 21:46:01 CET
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?
Comment 25 Thomas Andrews 2021-01-22 22:19:18 CET
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.
Comment 26 Thomas Andrews 2021-01-28 17:21:46 CET
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.

Note You need to log in before you can comment on or make changes to this bug.