Major (for me) linux issue

Might i ask what size your drive is? Might just need to create a 2GB /boot partition at the very front

2tb but I leave all the partitioning to the installer, just easier if you let it install how it wants to

all done, updated uefi (the option wasnt there) in the upgrade notes has something about aegis so guessing thats linux support. after that installed uluu and updated the kernel to the newest version and left the old one installed so I can revert if needed. thanks everyone for your help and hopefully this can help other people with similar issues

1 Like

This sounds exactly like the problem I ran into when I switched to Linux last year. With the exception of Linux Mint, the exact thing happened to my setup on various distros.

tl;dr: For me the issue was/is AMDGPU driver not managing the power state change for my MSI R9 390 correctly.

The PC would randomly lockup in the same way, the screen goes black, keyboard and mouse input drop (my keyboard LEDs turn off, the monitor also goes into standby as if the cable has been removed), the PC remains on but is completely unresponsive (I’ve also noted that the GPU fans spin up)

After a lot of trail and error I found out that it’s to do with incorrect handling of the power states for my MSI R9 390. As far as I can tell once you start doing anything that causes the GPU to change power state (playing video, even opening a web browsers, or in my tests just moving the System Monitor windows quickly back and forth on the desktop) the AMDGPU driver falls over and drops the card.

I’ve tested the R9 390 on two different PCs (Intel i7-4770K MSI Z97 and Intel i7-6850K ASUS x99) with various different distros and experienced the same problem on both machines on all but Linux Mint (I think it was Linux Mint I found to work but it was over a year ago)

I found that when I booted into text mode both machines were perfectly stable. When running in a graphical desktop environment I was able to SSH to the test machine to monitor DMESG and could see the AMDGPU power state change error just before the lockup.

I did a lot of research to try to find a solution. Someone suggested disabling AMDGPU auto power state management (setting kernel param “amdgpu.dpm=0”) but I could not get this to work and as far as I know it means that you need to run the card in “performance” power state all the time or manage the states manually. There’s some info on this here

Unfortunately I was unable to solve the issue, so my R9 390 has been sitting in a box for the past year. The i7-4770K has been running perfectly stable using the on-board Intel graphics and I have had to buy an RX 560 for the i7-6850K, both machines are now running Fedora 28 but have been stable through Fedora 26-28.

I was hoping that newer kernels and AMDGPU releases would solve the issue but only this week I gave the R9 390 another go in the i7-4470K machine with Fedora 28 and kernel 4.17 and the issue is still there :frowning:

Do you have another GPU you could try to see if this is the same issue?

Edit I just saw that you have an Nvidia GT630, I would suggest trying this GPU to see if it’s the R9 390

Shecks

well it just locked up again, I guess linux still hates AMD, the older cards at least, theres no way I’m buying a new card for this machine as its the hand me down machine from my main pc, I will try the nvidia card and see if that works, but I dont know if i want fedora im used to debian based distros

also in the time that it took me to write my last message and came back the card was extremely hot, hot enough i could feel heat coming from the case

Before you swap out the card, perhaps you could do a quick test with the “amdgpu.dpm=0” kernel parameter. It disables dynamic power managment, although this might not be the best solution for a home media PC

This might be of some help

https://bugs.freedesktop.org/show_bug.cgi?id=91880 - Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

This is the suggested kernel parameters for the 390 atm

radeon.cik_support=0 amdgpu.cik_support=1 amdgpu.dpm=1 amdgpu.dc=1

don’t know if they are still required or not?

1 Like

@Shecks @peterfixit

IF the 390 is the issue due to automatic power states you can force it to a specific state.

FWD:

IIRC that the powerstate issue was fixed in kernel versions >=4.9. However, I’m not sure if Xubuntu has cherry-picked backports which cause this regression.

Here’s another cool one.

2 Likes

Like all things AMD its very dependant on kernel. You can’t really expect any progress on distros using old kernels, and I wouldn’t trust them to backport.

According to distrowatch, Xubuntu is on kernel 4.15. So this hang shouldn’t be caused by his GPU.

The bug report suggests you need to be on 4.16* or newer to fix some of these issues assuming its the same issue. (and still require grub boot options by the look of it)

1 Like

Unfortunately these settings don’t work for me. I just tested them on Fedora 28 (Kernel 4.17.12). Hopefully the OP has better luck.

I don’t want to hi-jack the thread, but if this is actually the same issue as the OP is experiencing I am happy to run any tests because I have a spare machine with the R9 360 in it and can run the tests pretty quickly and report the results.

1 Like

ok so ive removed the 390 and installed the nvidia card, installed the proprietary drivers and it seems to work, now I need to find a distro I can use for gpu passthrough into a windows virtual machine using the r9 390 for linux and n evga 1080ti ftw3 for windows, that wont crash

you’re gonna have a hard time trying to switch around the host card in a live system.

i think you misunderstand. the primary os will be linux using 1 card and a virtual machine with a separate card being passed through to a virtual machine. 2 cards, 2 operating systems, no switching

ah, i figured you’d want to do handoff since you said you were using nvidia on the host system.

no that would be stupid, and the host machine will use a amd card with an nvidia card being for windows, the 1080ti is a good choice because of the 10-15% performance loss

not necessarily, you could actually use nvidia-xrun so you always have the best performing card available,

Like I said, though, I just misread your post.