AMDGPU-PRO 16.50 Rolls Out With GCN 1.0 Support, FreeSync

[bridgman]

It was working before, I've been using the amdgpu driver for a few months without problems, it was really going great. Then I went to test the -PRO stack on Ubuntu, and when I came back to Arch mouse cursor was gone. Something updated, I'm not sure what. It wasn't the Kernel, though, because I used the same Kernel that was working before.

I do remember that mouse cursor wasn't present in the very early stages of SI support on amdgpu, but then xf86-video-amdgpu updated and it started working and was working since. So I do believe the problem is with this package.

Thanks. OK, so mouse cursor was working with the upstream kernel, then stopped working, but you were using the same kernel as when it was working (looks like 4.8.13 now but that's a recent update - do you remember what you were using ?). Doesn't that suggest the problem is *not* in the kernel driver ? (not saying I know where it is, just that maybe your previous stack was using a different X driver or that DE changed etc..).

We still need to figure out where the problem you were seeing *is* coming from though; haven't heard any internal reports of mouse cursor problems (it's one of the more obvious bugs) but will double-check.

[Amarildo]

bridgman Please refer to post #78 where I linked the amd-staging-4.7 Kernel. That is what stayed the same, other factors (mesa, llvm, xf86-video-amdgpu, etc) all changed, along with xorg-server from 1.18 to 1.19 in the [testing] repo of Arch, which is required now for xf86-video-amdgpu IIRC.

[bridgman]

OK, thanks. I missed the highlighting on "kernel".

If you are using the testing repo then I think your amdgpu X driver should be sufficiently new to pick up the mouse cursor fix there. Did you use the *same* kernel build before and after (ie built from same point in amd-staging-4.7 tree) or did you do a fresh build / pick up a newer version of the kernel tree ?

I'm wondering if there might be an issue between the newer "everything else" you picked up the second time and the 4.7 kernel base in the staging tree, ie whether a newer upstream kernel might be a better choice. IIRC the 4.9 kernel is out now so I would try that, unless one of the other devs remembers a specific issue.

[dungeon]

Maybe if possible try to revert from testing, if problem dissapear it is certainly somewhere in xserver or ddx... and then of course bisect that

[Amarildo]

bridgman I tried the Kernel compiled on Dec 7, and then I compiled it fresh afterwards to see if it would help. It didn't. That's why I think the problem is not on the Kernel itself.

[bridgman]

Yep, if you tried the previously built kernel first then agree it doesn't sound like kernel driver is the problem.

So either something broke in the other components or there's a mismatch between older kernel/drm and the newer userspace you picked up. Reverting to earlier userspace as dungeon mentioned would cover all bases if there was a way to be confident you were going back to the same versions you had before; failing that going to newer upstream kernel would at least rule out a mismatch.

[Amarildo]

I did revert most of the userspace stuff back a few days, though I'm not 100% sure it was to the same version as when it was working. I could only revert the oldest packages in /var/cache/pacman/pkg, which was around 10 versions. Given that the buildserver builds new packages every 6 hours, and the fact that I didn't update every 6 hours, IMO those should be enough to go back to where it was working.

What I don't remember reverting is xorg-server nor xf86-video-amdgpu (this last one was always pulled from git, always the latest).

This is why I think the problem is in xf86-video-amdgpu-git.

I'm on Ubuntu 16.04 right now and I'll compiled amd-staging, and use mesa-git from oibaf or padoka. If it fails too, I'm off to Windows.

[bridgman]

Can I ask you to stop thinking about amd-staging as the universal solution ?

It does have a purpose, and there are a number of specific scenarios where we have recommended giving it a try, but if you are running on a distro with a newer-than-4.7 kernel then IMO you are likely to have more success with a recent upstream tree. The amd-staging branches are raw development trees and I can pretty much guarantee that there will be regressions.

The base kernel should be OK for 16.04 but please try a recent upstream kernel as well.

[Amarildo]

Are you sure? Because last time I tried 4.9 and 4.10 I wasn't able to boot at all, getting a black screen. There was a kernel parameter to make the Kernel boot IIRC, but then I had no audio if I enabled that.

I'm only using amd-staging-4.7 because I found it has the best support for SI cards on amdgpu while still being trouble-free.

[bridgman]

Are you sure? Because last time I tried 4.9 and 4.10 I wasn't able to boot at all, getting a black screen. There was a kernel parameter to make the Kernel boot IIRC, but then I had no audio if I enabled that.

Hmm, that sounds like something the devs would want to know about, even if it is a non-obvious new or different kernel config parm. Do you happen to remember what the kernel parm was that made it boot, and for bonus points would there happen to be an fdo bugzilla ticket ?

Re: mouse cursor issue, I just found a very recent (last couple of days) fix-for-a-fix related to cursor on DCE6 (among others) so might be worth pulling either latest amd-staging-4.7 or drm-next-4.10-wip. There are also a number of changes specific to SI desktop cards in there you might want. In both cases you need something less than 36 hours old.