I had decided to upgrade my HP Laptop (AMD Graphics) to 42.2. Update went smoothly and quickly. However upon boot, KDE won’t start anymore. I get the terminal login, then when the GUI is supposed to load, I am just getting a black screen with a white (not flashing) cursor on the top left and nothing happens. Console and system are working fine and with no issues. I have reverted and did another upgrade to see if maybe something was wrong. Also I did a zypper update to see if any packages were missing, but the issue remains the same.
For now I have snapper’d back to 42.1 and everything is working fine. Any ideas would be appreciated.
As an additional info: I am right now using AMDs fglrx proprietary drivers.
try uninstalling fglrx before upgrade my understanding is that fglrx is depreciated in favor of the new AMDGPU/AMDGPU-PRO driver Which appears to be a work in progress and may not support older chips
if I remember well, there were some issues with that driver and some graphics features, that would not work well… However, this was some time ago.
Let me see if your suggestion works. If I get into KDE, that would be at least leading to the fact, that it was indeed a driver issue.
I will be reporting back shortly, with some news and progress (if any).
I have tried to use nomodeset to boot and it resulted in the same issue as before.
However, deleting the fglrx drivers resolved the issue at least partially.
I am able to log in now, however screen resolution is not set properly and the laptop monitor is not recognized (it just says VGA).
However, I have not updated the machine yet but just installed the core version as it is from the disk. Internet is fairly slow here and it takes me 3h to download the patches. Hence I wanted to see if it works first. Now since it did, I did a zypper up to update the packages. I will see if this is resolved after the update.
Also I suppose, I know have to add all the additional repos manually, right? Because all I see now is the regular openSUSE repos and all the others are gone.
OSS: radeon kernel driver + radeon xorg driver + applicable Mesa driver (rx00 … where x = 1, 2, 6) –> supports a whole whack of devices up to radeon southern islands (SI) class hardware
OSS: radeon kernel driver + radeon xorg driver + radeonsi Mesa driver –> supports a bunch of devices from radeon SI through radeon Sea Islands (CIK) class hardware
OSS: amdgpu kernel driver + amdgpu xorg driver + radeonsi Mesa driver –> currently by default
supports from radeon volcanic islands (VIK) class hardware and onwards[LIST]
in the near future, support will be extend to include from radeon southern islands (SI) class hardware and onwards
Currently, amdgpu-pro provides support for consumers in that it will work for hardware not currently or natively supported by the amdgpu driver they have access too E.g. the amdgpu kernel driver (and rest of graphics stack) in Leap 42.2 does not support radeon Sea Island class hardware … users of such hardware can turn to the amdgpu-pro driver stack, or update their respective kernel and graphics environment in order to make use of the amdgpu driver on Leap with said hardware.
At the time of that last sub-bullet point mentioned above, there should be zero reason for consumers to use the amdgpu-pro driver … it will no longer provide a convenience usage case scenario, and its only remaining differences between it and the vanilla amdgpu version will be aimed at enterprise workstation users who have specific requirements (that have essentially arisen and resulted from vendor lock in of particular applications they use)
Quite a while ago now, the radeon kernel and radeon xorg driver use to use UMS (user mode setting).
Then KMS (kernel mode setting) was introduced … this effectively moved mode setting support from the xorg driver into the kernel driver. For a while, both mode setting pathways were supported (though KMS was set as the default). What this meant was that you could pass the nomodeset (or nokms) boot option and you’d still be using the radeon kernel driver, albeit, the older the UMS code pathway/method for mode setting was being used instead
But those days are gone. Now its KMS only (UMS support has been disabled)*. Now when you pass nomodeset or no kms, you don’t use the radeon driver … you’ll use a generic UMS supporting fallback driver (fbdev, 99.99% of the time) that has limited support for pretty much everything
and in the near future, it will be AMS (atomic mode setting), but that’s unimportant to the story … included only for interest’s sake]
However, deleting the fglrx drivers resolved the issue at least partially.
yes, if you were trying to run with a driver that doesn’t have support (and Leap 42.2’s environment falls under that categoy), it ain’t gonna work. Ergo you’re problem with that.
I am able to log in now, however screen resolution is not set properly and the laptop monitor is not recognized (it just says VGA).
See the section above … you’re now using the limited fbdev driver. Get rid of the nomodeset stuff and utilise the radeon driver.
If you have trouble after doing that, then we can properly sort things out from then … but you got to get to the proper starting point first!
However, I have not updated the machine yet but just installed the core version as it is from the disk. Internet is fairly slow here and it takes me 3h to download the patches. Hence I wanted to see if it works first. Now since it did, I did a zypper up to update the packages. I will see if this is resolved after the update.
it won’t resolve anything you’ve described. see above sections.
Also I suppose, I know have to add all the additional repos manually, right? Because all I see now is the regular openSUSE repos and all the others are gone.
what other repos? about the only other repo most users will want is the packman repo (to get access to codecs for unencumbered media playback support) … in any regard, that’s a vastly different area/problem … better to open up another thread then to mix such discussion in with this graphics related issue.
Even without nomodeset, the display settings were unavailable.
However, once the update of all the packages was complete and I did a reboot of the system everything worked just fine. There are no more issues - at least nothing I can tell so far. I was just not aware, that fglrx was depricated on 42.2. I heard that Ubuntu 16.4 would no longer use it, but well… either way that fixed it.
It’s not deprecated, it is outdated and right out broken on 42.2 (and Tumbleweed even longer).
It doesn’t support current Xorg versions, as AMD didn’t update it at all since a year.
And the official version only supports/works with kernels up to 3.9 either AFAIK, but this has been patched in the fglrx packages available for openSUSE (which support up to 4.5).
Sebastian Siebert (who worked on packaging fglrx for openSUSE already) is currently working on creating a new packaging script for the new (proprietary) amdgpu-pro Xorg driver though, which will then be available in the fglrx repo soon too I suppose. Though AFAIK this does not come with its own kernel module, but also uses the standard amdgpu kernel module. So you might need to update the kernel too.
But this might not support older chips that fglrx still supported.
If the open source driver works fine for you now, it’s probably best to stick to it.
Hi
For the newer cards there is already an amdgpu-pro driver available, it works with SLE 12 SP2 and openSUSE… just unpack and run the install script, it adds a local repo with the pre-built rpms. If not in the list of supported cards but still a GCN one, depends on which GCN version, but I have my R5 (GCN 1.1) working fine with the in-kernel amdgpu driver. If not a GCN card, radeon is the only option…
Well I the system having the issues was a Laptop, running an on-board Mullins chip. Last I checked, it was supported by the gpu driver from AMD, but once I installed it (back then testing Kubuntu 16.04) it did not work well.
Either way, I am now running open source drivers and as far as I can tell, it works fine. I have not tried any games yet, but most games I play are older anyways (SWG, Panzer General III Era, etc.). I will have to see how it goes and keep that GPU drivers in mind.
For the time being, the system works and since this is more a work machine than a gaming one anyways, I am happy with how it is for now.
Hi
For the Mullins chip (Which my R5 is), I raised a bug/patch and was added into the upstream xf86-video-amdgpu driver which is in Tumbleweed, for the Mullins card it needs CIK on which in the 4.4 kernel isn’t activated, again ok in Tumbleweed. For the amdgpu kernel driver to work, I have a patched amdgpu-kmp and the xf86-video-amdgpu package available here;
zypper if amdgpu amdgpu-kmp-default xf86-video-amdgpu
Information for package amdgpu:
-------------------------------
Repository : repo-AMDgpu-Update
Name : amdgpu
Version : 4.4.36-2.1
Arch : x86_64
Vendor : obs://build.opensuse.org/home:malcolmlewis
Installed Size : 156 B
Installed : Yes
Status : up-to-date
Summary : Experimental kernel module to support Sea Island cards
Description :
This kernel module adds experimental support for Sea Island cards BONAIRE,
KABINI, MULLINS, KAVERI and HAWAII.
Information for package amdgpu-kmp-default:
-------------------------------------------
Repository : repo-AMDgpu-Update
Name : amdgpu-kmp-default
Version : 4.4.36_k4.4.36_8-2.1
Arch : x86_64
Vendor : obs://build.opensuse.org/home:malcolmlewis
Installed Size : 30.9 MiB
Installed : Yes
Status : up-to-date
Summary : Experimental kernel module to support Sea Island cards
Description :
This kernel module adds experimental support for Sea Island cards BONAIRE,
KABINI, MULLINS, KAVERI and HAWAII.
Information for package xf86-video-amdgpu:
------------------------------------------
Repository : repo-AMDgpu
Name : xf86-video-amdgpu
Version : 1.2.0-2.1
Arch : x86_64
Vendor : obs://build.opensuse.org/home:malcolmlewis
Installed Size : 183.3 KiB
Installed : Yes
Status : up-to-date
Summary : AMDGPU video driver for the Xorg X server
Description :
amdgpu is an Xorg driver for AMD video cards.
Its autodetects whether your hardware has a CI or newer AMD Graphics Card
No, the amdgpu-pro package does include a kernel module (it gets placed in /ib/modules/{linux}/updates/amdgpu.ko ) … there wouldn’t be much point of just packaging the amdgpu xorg driver alone … you’d miss out on the 3D stuff (pro package provides amdgpu_dri … oss stack utilises radeonsi_dri)
In any regard, amdgpu is only applicable to GCN hardware (From Southern Islands adapters and onwards)
Ahh, okay. From what you had written, I was thinking that it was an even older device. Regardless, what I wrote describes the support options or pathways you can choose from (now, and in the future) … if you elect to go with one of the amdgpu routes, you will need to blacklist the radeon driver.
Either way, I am now running open source drivers and as far as I can tell, it works fine. I have not tried any games yet, but most games I play are older anyways (SWG, Panzer General III Era, etc.). I will have to see how it goes and keep that GPU drivers in mind.
By default, you’ll be using the radeon driver stack.
For the time being, the system works and since this is more a work machine than a gaming one anyways, I am happy with how it is for now.
good to hear.
Well, I thought I read somewhere a while ago that both drivers (the open source one and amdgpu-pro) will use the same kernel module.
And Sebastian Siebert also wrote that he needed to install a newer kernel so that his graphics card works with amdgpu-pro.
But I had a look at the SLE packages provided by AMD now, and there is indeed a kernel module (in source code, built on installation/with dkms) included.
So it seems you are right.
It is named the same though, so maybe it’s just a newer version or something like that?
Regarding 3D, I didn’t mean just the actual Xorg driver alone, but all user space parts (including the GL libraries). Just didn’t know how to express it better while staying comprehensible.
The SLE packages apparently have a flaw though, they come without 32bit libraries, so 32bit applications won’t work (if they use OpenGL at least). This will be workarounded in the openSUSE packages by extracting the missing files from the Ubuntu packages.
See openSUSE Lizards
Its largely the same (probably on the order of 95% or greater). In time* it will move to about 99% same code base. Current differential is related to DC/DAL, IOCTLs (that will never get put into kernel), …
Which why I wrote earlier that: “At the time of that last sub-bullet point mentioned above, there should be zero reason for consumers to use the amdgpu-pro driver … it will no longer provide a convenience usage case scenario, and its only remaining differences between it and the vanilla amdgpu version will be aimed at enterprise workstation users who have specific requirements (that have essentially arisen and resulted from vendor lock in of particular applications they use)” … that (for now mythical point in time) will also encompass the CL, and Vulkan aspect too.
Regarding 3D, I didn’t mean just the actual Xorg driver alone, but all user space parts (including the GL libraries). Just didn’t know how to express it better while staying comprehensible.
Just to be clear on this point, he (Sebastian) was talking about the oss amdgpu kernel driver:
The default openSUSE kernel does not work with my graphics card. So I should installed Kernel 4.9 from Kernel repo because I have a Radeon R9 290X (Southern Island architecture).
he would possibly have to update the user space components too.
In an regards, my earlier point about it not yet supporting such hardware by default applies.