AMD R9 285 with Debian 9: amdgpu black screen

[Apteryx]

I'm trying to use a Radeon R9 285 with the amdgpu driver on Debian 9, which runs the kernel Linux v4.9. I've followed the tutorial here: https://linuxconfig.org/how-to-insta...-stretch-linux, which has us add the "contrib" and "non-free" repo to install "firmware-linux" package which contains the proprietary Tonga firmware bits (it would be nice that those be GPL'd as well) that are apparently needed by the amdgpu driver.

Sadly, upon rebooting with the firmware (and llvm-3.9 and clang-3.9 as suggested in the tutorial) installed, I'm greeted with a black screen.

I can SSH in. I've made available the full output of "dmesg" here: https://drive.google.com/open?id=0B1...VRBUFVqbDVoSjA.

It could be that the motherboard (a vintage Asus M2N SLI Deluxe) doesn't like the card, although when *not* using the proprietary firmware I can boot into live Debian 9 just fine. I'm using the latest BIOS revision available, which is 1804. I've also tested the card in another tower I had and could make it work with the same software (Debian 9 + firmware-linux). Another part of the puzzle is that if I keep the CR2032 battery in, the memory doesn't work well (memory errors). So I'm leaving that battery out for the moment and memory tests pass fine then. I'll try to get a replacement soon.

Here are some errors that I see in dmesg:


[ 11.728654] [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 0 test failed (scratch(0xC040)=0xCAFEDEAD)
[ 11.728766] [drm:amdgpu_device_init [amdgpu]] *ERROR* hw_init of IP block <gfx_v8_0> failed -22
[ 11.728806] amdgpu 0000:03:00.0: amdgpu_init failed

[ 18.708286] amdgpu 0000:03:00.0: Fatal error during GPU init
[ 18.708317] [drm] amdgpu: finishing device.
[ 18.708318] [TTM] Memory type 2 has not been initialized


See my link above for the full dmesg. Is my card really CAFEDEAD? Eh.

[Apteryx]

Thanks for the reply, debianxfce! It's a good suggestion to try against the latest & greatest. I will experiment more this week with the card in my personal desktop and use Debian Testing instead of Debian Stable.

Regarding the memory corruption on reboots, this has been fixed by changing the CMOS battery. Apparently the BIOS settings were being corrupted by the weak battery or something.

Unless I dreamt I could boot successfully with the AMD R9 285 *once* after letting the system alone for a long time (without any power). On subsequent power on it would not work (black screen as usual with the CAFEDEAD error in dmesg). Maybe something with the board is not right. For now it's working well albeit slowly with an old Geforce + nouveau and I will try the card with another motherboard to determine whether the card has a problem alone or if it's just with that M2N SLI Deluxe motherboard that it fails... To be continued.

[pcxmac]

I have found building your own kernel to be advantageous. I also recommend chrooting and building your own basic system, btrfs works great for versioning and branching off.

[SystemCrasher]

Debian is a good thing. However, it isn't without its limits. So Debian Stable would go for "stable" to degree it happens to be "stale", "obsolete" or even totally wrecked, which is a case for kernel, MESA and so on. So lol, R9 285 is "too new" for stable. Actually most GCNs are better off with newer MESA and kernels. Debian stable tends to take about 2 years to do full QA/release cycle. So when Stable just released you could expect techs which are already about 2 years in the past at this point. Which is a big deal for fast-moving targets like kernel, mesa and so on, as well as relatively recent HW support.

Furthermore, Debian (and ubuntu) kernel builds leave a lot to be desired by default. Say, on desktop one may really want kernel with full preemption for the sake of latency and pleasant user experience. But default kernels aren't build like this. Oh, want to try some new cool stuff like btrfs with all these snapshots? Debian Stable kernel just way too old and bugged so feel free to enjoy by all these bugs. Nobody would fix them, since it is too challenging to backport all changes from more recent kernels. So you're better off with all these stable bugs. Possibly fixed in upstream versions year ago. Or maybe even two, who knows. On bright side, this implies you wouldn't get some brand new, fresh, totally unexpected bugs and incompatible changes, possibly totally breaking everything and so on. Well, sometimes programs change incompatible ways. That's where Stable gets its point: if it works for you after you've installed it, it would likely keep doing it that way. Without suddenly breaking on minor/security/etc updates.

My personal opinion is that Debian Stable "as is" is more or less fine for some server. As long as it does not uses newest HW and does not uses brand new/advanced stuff. Say, if one wants btrfs, old kernel is a really poor choice. To become a decent desktop, Debian needs some tweaking. Getting more recent MESA and kernel is definitely part of plan. I could imagine 2 options: build e.g. most recent kernel yourself or enable e.g. "testing" repos and so on. Or even "unstable" but it is really hazardous. And even "testing" could break, at this point one no longer could blindly install all updates and assume things would continue working, so it more experimental and less stable setup. If it sounds too complicated, guess what Ubuntu (and other subflavours like kubuntu, xubuntu, etc) did. They mostly tweaked Testing into somethnig else. Though I dislike their kernels as well. I do not get why they supply kernels configured like that for desktop. But alright, world is not perfect.

[SystemCrasher]

I have found building your own kernel to be advantageous. I also recommend chrooting and building your own basic system, btrfs works great for versioning and branching off.

I would second that. At least somewhat. While it sounds scary, debian (and ubuntu) kernel packages are coming with config file so one could start with more or less reasonable defaults and try to get somewhere else, if they know what they are up to. Then, there is make deb-pkg which would do the rest. Er, Debian users usually have a very good idea what to do with resulting .deb files, right? So rebuilding kernel could suprisingly be easier than it sounds. Though if it would backfire for whatever reason, troubleshooting would take some expertise, sorry, and it could happen eventually. So I would recomment this adventure for technically inclined ppl who want to learn more about their system.

I've been too lazy to re-build whole desktop environment , but I've eventually learned to debootstrap my ovn flavour of "testing" I'm using on ARM SBCs for fun and profit these days. Though it cross-debootstrap (x86-64 -> armhf) using some fancy full-virt/two phase approach I never seen documented anywhere. Either way, after some experiments I've ended up with way to build relatively compact and predictable Debian armhf core, which is quite fast to boot and ok to use in embedded setups, etc. Fancy way to fiddle with IoT-like setups. Somehow building custom Debian proven to be not THAT hard. One could even cross boundaries between e.g. x86-64 and armhf worlds if they want. But alright, it takes some understanding of inner working. There're some funny ways to get stuck, after all. Furthermore, it could happen there is nobody to ask how to get unstuck so you could be the only person who could figure out answer. When someone builds custom system they're better to be prepared for this. So it's not for everyone. Yet its fancy way to learn how your system starts up, which components are in place and why, etc.

[Apteryx]

Hello, and thanks for the replies. I enjoyed reading them. I agree that using newer and customized kernels would probably help. It's true that GCN support seems to be a moving target (still, after like 2 years). And even if it didn't help I could gain some knowledge from doing it. I have to say though that this machine is intended as an easy to support/reliable desktop machine for my father, not as a development inclined box. He pretty much hates it when software changes. I thought Debian stable would be a good fit . For the other, more exciting/nerdy adventures, I have GuixSD that has been serving me very well, and keeps me on the learning curve.

To return to my original topic, it seems that my post should have been titled: "AMD R9 285 with M2N SLI Deluxe motherboard: amdgpu black screen". I've been testing the same card with the same software (Debian 9 + amdgpu) but on another machine (an even older motherboard: P5W DH Deluxe) and it works very smoothly. So the problem doesn't seem to lie in the software, or at least if it does it is not broken on all systems.

The M2N SLI Deluxe system has been acting a bit recently. The power supply blew up, then one drive was working but slowly, then the CMOS battery was dead, and then that GPU card would work only without the firmware blobs loaded on it (although it used to work with Ubuntu 14.04 + proprietary AMD driver). And just now it started giving kernel panics with errors such as ata6: SRST and won't even boot. I've tested the RAM before and it was fine. The drive is a brand new SSD. The power supply is brand new and of good quality. Might be a SATA cable although why would it have worked for some days before, and I didn't move the box at all?

I'm a bit lost as to what to try next if swapping the SATA cables won't help.

[Apteryx]

It uses ddr 800Mhz so it is over 10 years old. Maybe it is time for a mobo,cpu and ram update. To have better luck with recent software.

In the end, the only thing that got the AMD R9 285 GPU running *on that M2N SLI Deluxe* system was to use the Linux 'drm-next-4.14-wip' branch from Alex Deucher as you recommended somewhere. The system may be old (2008), but it still punches some kicks with 8 GB ram, a Phenom II X4 940 (3 GHz Quad Core), the R9 285 and now SSD drives. I've played Dirt Rally at medium detail and it was enjoyable at around 30+ FPS (sadly it uses only 2 of the 4 cores).