Greetings. I’ve been trying to switch from the radeon driver to amdgpu for some time. However my card is a GCN 1.0 model, and as such marked experimental for this driver. Using it therefore requires some special steps, which I’ve attempted taking but they don’t seem to work out. This thread is dedicated to discussing those steps, and seeing why things aren’t working on my model of card. I use openSUSE Tumbleweed and the latest system packages provided by its official repositories.
Now what I tried, by mixing together a bunch of instructions I found in various places: First of all I created the file /etc/X11/xorg_pci_ids/amdgpu.ids and included my card’s model, which seems to be 1002:6811 (so 10026811). Obviously I made sure the “nomodeset” flag isn’t present in my kernel boot parameters. Then I booted with the following custom parameters from grub2:
amdgpu.exp_hw_support=1 blacklist=radeon 3
The result is that, once the system finishes booting and I should be reaching the login manager (SDDM) where I type my password and log in, I’m instead taken to a console in a different runlevel (as if pressing Control + Alt + F#). If I press Control + Alt + F7 to switch to the normal session, I only see a black screen with just the cursor blinking forever in the upper-left corner of the screen.
So far I seem to have a vague clue as to why: The amdgpu module apparently gets loaded, then unloaded 2 seconds later! From what the instructions indicate, this should not be happening. The two lines in the paste below show this happening:
mircea@linux-qz0r:~> grep amdgpu /var/log/Xorg.0.log
38.075] (II) Matched amdgpu from file name amdgpu.ids
38.087] (II) Matched amdgpu from file name amdgpu.ids
38.087] (==) Matched amdgpu as autoconfigured driver 1
38.087] (==) Matched amdgpu as autoconfigured driver 3
38.114] (II) LoadModule: "amdgpu"
38.114] (II) Loading /usr/lib64/xorg/modules/drivers/amdgpu_drv.so
38.156] (II) Module amdgpu: vendor="X.Org Foundation"
All GPUs supported by the amdgpu kernel driver
40.110] (II) UnloadModule: "amdgpu"
40.110] (II) Unloading amdgpu
Am I missing anything important? What can I attempt to get this driver working successfully?
I do not have an /etc/modprobe.d/50-radeon.conf file, but do have /etc/X11/xorg.conf.d/10-amdgpu.conf. I also have all amdgpu packages installed for months:
I tried blacklisting radeon via the kernel boot parameter explained in the first post, which is currently my method of choice as it allows me to do one-time tests without making permanent system changes that could leave my system unusable. Before I attempt to blacklist it permanently, I’d like to understand why I’m stuck in a black screen upon booting with this blacklist.
Just tried it without the “3” at the end: This only causes the blacklist to not work at all, and “radeon” remains the module in use as is normally the case.
On Thu 08 Jun 2017 07:06:02 PM CDT, MirceaKitsune wrote:
malcolmlewis;2825822 Wrote:
> Hi
> Because you have a 3 at the end probably… multi-user target?
Just tried it without the “3” at the end: This only causes the blacklist
to not work at all, and “radeon” remains the module in use as is
normally the case.
Hi
Have no idea why your grub command doesn’t work… adding a 3 will
always boot to multi-user/runlevel 3.
So you get to a graphical session with no 3, but using the radeon
driver?
If so then implement the changes with a blacklist file, rebuild initrd
and reboot. If it doesn’t work, then press ctrl+alt+F1 to get to a
console login, remove the blacklist, rebuild initrd etc.
Or go to YaST bootloader and add your options here, you can always edit
them out at boot time…
–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.2|GNOME 3.20.2|4.4.62-18.6-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
I remember trying something similar months ago. As in I actually used a blacklist file, instead of relying on a kernel boot parameter. I got the exact same result, so I don’t believe this is the cause.
Like I said I’m nervous about doing this in the permanent system configuration, rather than using one-time boot parameters which aren’t persisted; This is my main desktop and I don’t wish to be stuck trying to debug a non-functional system from the console. Still I need to switch to amdgpu, as the radeon driver is riddled with both GPU lockups as well as vulnerabilities that let hidden attack scripts trigger system crashes… both of which I’m hoping a driver switch will solve.
Never the less, I have access to a console on runlevel 1 (control + alt + f1) with amdgpu. Perhaps someone can suggest a few debug commands to try there, in order to see exactly why the login manager refuses to start? Please let me know what else I can try next, and if anyone has any suspicions as to why the login manager won’t load.
Hi
Well if you insist on not blacklisting and rebuilding initrd so the radeon driver is removed, then not sure what you can do, plus things may not be ready for GCN 1.0 cards yet to really work.
Press ctrl+alt+F1 or use ssh from another computer to get to the system if it goes pear shaped.
No issues with the Mullins cards here with Leap 42.2, Tumbleweed amdgpu driver.
Like I said, I already tried with a blacklist file in the past. It was actually a custom RPM package, which I then uninstalled using YaST from command line to fix it. But yeah, it was the exact same result.
And my login manager is SDDM. By the time I did the test mentioned above, I’m sure I was using KDM. So this issue happens with both… which leads me to believe it might be a general issue agnostic of login manager.
About 3-4 months ago, I simply installed that package and restarted… then when it didn’t boot, I started YaST from the CLI then removed the package and restarted again.
Both that and booting with the parameters blacklisting “radeon” have the exact same result: The runlevel of the normal session (control + alt + f7) remains stuck at a black screen where only the cursor is seen blinking in the upper-left corner of the screen, instead of the login manager actually showing up. Note that this is an inexperienced guess, but I’d say that looks a bit like X11 not starting up or crashing immediately after it does… could this be a possibility?
I use Tumbleweed, still tried that package since 42.2 is pretty close (especially at the time when I tried it). Obviously I have xf86-video-amdgpu installed as well, alongside every other amdgpu package offered in the default repositories (I believe there are 3 in total).
My card should definitely be new enough to work. The only problem is that it’s labeled GCN 1.0, and from what I heard the Kernel developers are (stubbornly?) still marking those as experimental, although for 1.1 and 1.2 it’s default from what I heard.
Hi
Once 1.1 support was included in Tumbleweed I dropped my packages, so if you still have them, then they should be removed. Then use the default Tumbleweed ones.
So passing the experimental option is the only thing that should be needed.
But for 42.2 you also needed the xf86-video-amdgpu as well as the module.