Bug 1164737

Summary: Radeon R7 Graphics [1002:130f] 15.2 build 581.2 Installer crash with certain combination of integrated graphics and monitor
Product: [openSUSE] openSUSE Distribution Reporter: Walter Zimmer <walter.zimmer>
Component: X.OrgAssignee: E-mail List <xorg-maintainer-bugs>
Status: RESOLVED FIXED QA Contact: E-mail List <xorg-maintainer-bugs>
Severity: Normal    
Priority: P3 - Medium CC: jreidinger, snwint, walter.zimmer
Version: Leap 15.2   
Target Milestone: ---   
Hardware: x86-64   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: boot.txt (from supportconfig)
x.txt (from supportconfig)
/var/log/messages from 581.2 (without nomodeset)
/var/log/messages from 581.2 (with nomodeset)
/var/log/Xorg.0.log from 581.2 (with nomodeset, after Yast started up)

Description Walter Zimmer 2020-02-24 15:45:22 UTC
Tried to install 15.2 build 581.2 on an older PC.

Boot from USB stick, all unnecessary hw/disks unplugged.
Bootloader succeeds, then comes the screen with the three green bars chasing each other. Then comes some text output, and then the screen goes blank and it just crashes: numlock, CTRL-alt-del not working, PC has to be hard reset (5 sec powerbutton). Same with 15.1 btw. Waiting for 5 minutes doesn't help.

CPU is a quite ancient AMD A10-7850K with integrated graphics,
monitor is LG 32UD99-W (UHD), connected via HDMI.
Mainboard is Gigabyte F2A88XM-D3H.

The same monitor is working fine when the same Leap 15.2 is installed on a Ryzen 5 3400G with the same monitor (also connected via HDMI).

It also works when I attach my older (sub-FHD) monitor for installation and switch to the new UHD monitor later, so it really seems to be that particular combination of older CPU/graphics and newer monitor which confuses the installer.

Don't know if it's worth fixing as the CPU is quite old, and (at least for me) the workaround worked quite well, but I thought I mention it.

If there's anything I can test please tell, but I guess it's difficult to get log files so early in the installation process. Logfiles from the installed system are no problem, I'm just now submitting this report on it as it runs fine.
Comment 1 Josef Reidinger 2020-02-25 12:48:40 UTC
Can you try to setup remote logging as described at [1] and attach such logs there? So we will see where crash happens ( hopefully).

Thanks

[1] https://en.opensuse.org/SDB:YaST_remote_logging_during_installation
Comment 2 Walter Zimmer 2020-02-26 23:01:19 UTC
Tried the NFS thing, didn't work; had network up, ping and SSH to nfs server were working, firewall on server disabled. But mount said (after requesting nolock which I then provided): "requested protocol version or transport protocol not available." Then I gave up, version mismatch between identical distributions is unlikely, but I have no idea what the real error could be. Sorry for that!

On the bright side: "nomodeset" helps to skip the crash and provides a blurry, but usable install screen.
Comment 3 Josef Reidinger 2020-02-28 09:12:58 UTC
as nomodeset helps it looks like problem with graphical drivers which is more limited in installation environment.

Steffen do you have idea how to more debug this issue?
Comment 4 Steffen Winterfeldt 2020-02-28 09:36:39 UTC
Looks like an xorg issue to me. Let's move this to the xorg team.
Comment 5 Stefan Dirsch 2020-02-28 10:14:13 UTC
Hmm. Since it crashes with installation kernel, but obviously not with the kernel on installed system, the issue might already be fixed assuming the kernel has been updated during installation to a newer release/version. This would mean a newer build would already fix the issue.

Still it would be helpful for me to see some logfiles, so I know more about the hardware and kernel detectections. Could you install supportutils package, run supportconfig and provide the results here? Thanks!
Comment 6 Stefan Dirsch 2020-02-28 10:15:04 UTC
(In reply to Stefan Dirsch from comment #5)
> Still it would be helpful for me to see some logfiles, so I know more about
> the hardware and kernel detectections. Could you install supportutils
> package, run supportconfig and provide the results here? Thanks!

This on the installed system of course. :-)
Comment 7 Walter Zimmer 2020-02-28 23:19:39 UTC
Created attachment 831633 [details]
boot.txt (from supportconfig)
Comment 8 Walter Zimmer 2020-02-28 23:20:43 UTC
Created attachment 831634 [details]
x.txt (from supportconfig)
Comment 9 Walter Zimmer 2020-02-28 23:22:29 UTC
That facilitates things :) Attached boot.txt and x.txt from the running system, I guess this is what you need.
Comment 10 Stefan Dirsch 2020-03-01 11:53:04 UTC
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Kaveri [Radeon R7 Graphics] [1002:130f]

Logfiles are from an older system, right? Kernel 4.12 doesn't sound like Leap 15.2 to me ...

I propose to try again with a newer build.

Build 595.1 apparently will ship/ships with 5.3.18-lp152.4.6. I don't know whether this is newer than the one on Build 581.2. I can't find images for this any longer.
Comment 11 Walter Zimmer 2020-03-02 09:38:09 UTC
Sorry for the confusion! The system is indeed 15.1. But that one shows the same symptom (installer crashes, switch afterwards is fine), so I thought the hardware info should still be helpful.

So I'll download the 585.1 this evening and try it...

Maybe I'll try to copy the supportutils binary on a USB stick and execute on the install system (with startshell=1), since it seems to be a statically linked one.
Comment 12 Stefan Dirsch 2020-03-02 09:47:30 UTC
Hmm. Now I'm completely confused. Hardware information has been from the affected system you initially reported or not?

I would have hoped for logs from the installed 15.2 system of build 581.2, since then I would also have seen the kernel information and could have told you if a newer build comes with a newer kernel ... only with an updated kernel it makes sense to test again ... but maybe you no longer have this system avalable. Using supportconfig on a USB stick may work. Not sure I ever have tried this before ...
Comment 13 Walter Zimmer 2020-03-02 19:24:49 UTC
Created attachment 831739 [details]
/var/log/messages from 581.2 (without nomodeset)
Comment 14 Walter Zimmer 2020-03-02 19:25:22 UTC
Created attachment 831740 [details]
/var/log/messages from 581.2 (with nomodeset)
Comment 15 Walter Zimmer 2020-03-02 19:26:29 UTC
Created attachment 831741 [details]
/var/log/Xorg.0.log from 581.2 (with nomodeset, after Yast started up)
Comment 16 Walter Zimmer 2020-03-02 19:34:29 UTC
Hardware info has been from the system, but extracted via the installed 15.1, not the 15.2 beta. But it doesn't matter:

I've put in the 581.2 stick again, supportconfig didn't work as it tries to read some config from /usr/lib, so in my desperation I copied the /var/log/messages from the normal boot (without nomodeset option), and then from a boot with the nomodeset option active (see attachments above). From this second boot which allowed Yast to start (because of nomodeset), I also attached the Xorg.0.log.

I hope you can now extract all the information you need?
Comment 17 Stefan Dirsch 2020-03-02 21:13:17 UTC
Seems 581.2 comes with  5.3.18-lp152.4-default, where you still need "nomodeset". So I'm afraid Build 595.1 with 5.3.18-lp152.4.6 won't help either, but who knows ...
Comment 18 Walter Zimmer 2020-03-03 09:41:17 UTC
No Problem, I'm happy to know that nomodeset saves me from getting into the basement to pull out my old monitor when I'll install the final 15.2. :)

Anything else I can do? Already the installed system from 15.1 boots without nomodeset, so in general the support for this monitor is working since some time - just not in the 15.1/15.2 installer. So it seems the answer to the riddle is hidden in the xorg.0.log from the case where it's aborting. Maybe I'll try that NFS logging again... or maybe just plain to a USB stick?
Comment 19 Stefan Dirsch 2020-03-03 10:18:59 UTC
Ok. I suggest to try from time to time an updated installer. It still sounds weird to me that graphics on the installed system works but not with the installer. It should be the same driver. But indeed workaround for now is to install with nomodeset and then remove this kernel option again for the installed system.
Comment 20 Walter Zimmer 2020-03-03 19:38:39 UTC
Ok, there is an Xorg.0.log and a YaST2/y2start.log on the stick. After the crash I waited for 5 mins and prayed the disk blocks make it to the stick, but unfortunately, both have exactly 0 bytes length, so no use.

If there are any new ideas, please tell, in the meantime I'll try again when the official release is out, but I'm happy anyway. Thanks a lot!
Comment 21 Stefan Dirsch 2020-03-04 10:36:34 UTC
Yeah. Just let me know, whether it works with the final release. :-) I hope so ...
Comment 22 Walter Zimmer 2020-04-21 08:50:25 UTC
Update ate my 15.2, so I installed new from the Build 632.2 iso and the installer worked flawless without need for nomodeset workaround. So it is as you predicted. :) Thanks a bunch!
Comment 23 Stefan Dirsch 2020-04-21 09:27:44 UTC
Happy to hear this. Thanks for confirmation!
Comment 24 Stefan Dirsch 2020-04-21 09:29:59 UTC
Considered fixed.