You are not logged in.
I have a Radeon 8730M as a dedicated GPU and integrated Intel graphics. Until recently, I was able to do "xrandr --setprovideroffloadsink" and then prefix programs with DRI_PRIME=1 to have them run on the dGPU. The output from "xrandr --listproviders" still lists both:
~ $ xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x6a cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 5 associated providers: 0 name:Intel
Provider 1: id: 0x41 cap: 0x0 crtcs: 2 outputs: 0 associated providers: 0 name:OLAND @ pci:0000:01:00.0
However now I get:
~ $ xrandr --setprovideroffloadsink "OLAND @ pci:0000:01:00.0" Intel
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 140 (RANDR)
Minor opcode of failed request: 34 (RRSetProviderOffloadSink)
Value in failed request: 0x41
Serial number of failed request: 16
Current serial number in output stream: 17
Trying to do "xrandr --setprovideroffloadsink" with the IDs instead of the names gives the same error.
I also noticed this in dmesg, which was previously not there:
[ 25.735073] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD)
[ 25.735087] [drm:si_resume [radeon]] *ERROR* si startup failed on resume
Oddly enough, downgrading from Linux 4.5.1 to 4.5 seems to solve the issue. I'm not sure why given that the driver (xf86-video-ati) stays the same version.
Offline
Linux graphics stack involves much more then just the xorg driver and looks something like this :
kernelmodule
libdrm
OpenGL provider (typically mesa for opensource drivers)
xorg driver (xf86-video-* for opensource)
It does look like you may have found a kernel regression, please postfull dmesg.
"ring 0 test failed" messageas are very often critical for graphic cards.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
Full dmesg
The radeon error is towards the end.
Offline
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=64d3b09d-388c-4e12-a8db-c71d515c683c rw quiet loglevel=1 pcie_aspm=force i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1
.....
[ 0.000000] DMI: Dell Inc. Inspiron 3521/09GM81, BIOS A02 09/26/2012
Dell tends to start firmware versions with A00 ,so A02 is a very early firmware version.
I checked online, and it looks like the latest dell inspiron 3521 laptop firmware is A14, released in aug 2015.
I suggest you look into updating your firmware.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
Thank you for the pointer. Unfortunately even after updating the BIOS to A14 I get an identical error and offloading still fails.
Side note for anyone upgrading the BIOS of their Dell Inspiron (3521): the last two versions A14 and A12 don't work under FreeDOS, even though Dell claims they do. A14 gave me "This program cannot run in DOS mode" and A12 just gave me "Test." and nothing else happened. I eventually got A14 working under WinPE - https://wiki.archlinux.org/index.php/Windows_PE
Offline
https://bugs.freedesktop.org/show_bug.cgi?id=94874 looks similar.
Maybe try booting with radeon.nopm=0
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
Thank you!
This indeed appears to be the same bug. The option I needed was radeon.runpm=0 (not "nopm" as someone stated in the bug report). Offloading works now.
As someone mentioned this will prevent the card from turning off, but power management wasn't great before either, so meh.
Offline
Booting with radeon.runpm=0 fixed this issue for me as well.
Offline