You are not logged in.
Pages: 1
Like many before me, I have driver issues.
I have a Latitude E5470 with integrated Intel graphics and a dedicated AMD R7 M360 GPU. The former works fine. The latter doesn't work at all.
If I don't use amdgpu, whether or not I use xf86-video-radeon, the GPU does not show as available to X. Running 'xrandr --listproviders' shows only the Intel card.
If I don't blacklist amdgpu, or if I 'modprobe amdgpu' before I start X, I get a kernel oops (see below for dmesg) and X fails to start. If I load the module after starting X, the laptop freezes. This is true even after uninstalling xf86-video-radeon and blacklisting the radeon module. amdgpu-pro does not change any of this.
(Note: /sys/kernel/debug/ does not show a vga switcheroo switch except after loading amdgpu. If I echo "DIS" to it, the screen goes black. Relevant?)
dmesg link: https://pastebin.com/Ss4npAvA
Thank you for your help!
Last edited by epicepee (2017-05-02 20:25:59)
Offline
post full "lspci -k" output please.
Some questions :
Your processor is an intel i7-6600 , but you don't seem to have intel microcode updates enabled.
Check archwiki and enable them please.
you appear to be using an optimised linux-ck kernel, have you tried with the stock kernel or generic linux-ck ?
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
Here is lspci -k:
I have tried the stock linux kernel, it doesn't act differently. I have not tried generic linux-ck.
I'm pretty sure GRUB should be updating my microcode, as I have the intel-ucode package installed and grub.cfg mentions it:
initrd /intel-ucode.img /initramfs-linux-ck-skylake.img
I will try to update manually, maybe through Windows, as I am unfamiliar with the process.
EDIT: Ran the Windows Intel updater, I assume it updated the microcode if there is an update to be had. Relevant messages in dmesg are the same.
Last edited by epicepee (2017-05-03 17:21:05)
Offline
EDIT: Ran the Windows Intel updater, I assume it updated the microcode if there is an update to be had. Relevant messages in dmesg are the same.
Unless you have updated the bios and that includes the latest microcode for your cpu then you want to do what is described here: https://wiki.archlinux.org/index.php/Microcode
Regarding lspci, you probably want to get the output of 'lspci -nnk' as it will allow everyone to more easily identify which card you actually have.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
R00KIE: I have done what is described there. How should I best test whether it works? [EDIT: Trying a few things, will report back]
And here's lspci -nkk:
https://pastebin.com/qFG78CV1
Last edited by epicepee (2017-05-03 20:35:24)
Offline
Offline
Looks like my microcode is up to date (version 0x009e).
Offline
I said 'lspci -nnk' not 'lspci -nkk'.
Don't blacklist any modules, either radeon or amdgpu. Show us the output of dmesg when you have booted without blacklisting anything. You also don't need to install any xorg video drivers, the built-in modesetting driver should work. Like slithery says, you should read the wiki on how to test/use the discrete card.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Here's lspci:
https://pastebin.com/fanSMjJn
And here's dmesg with nothing blacklisted:
https://pastebin.com/Ue0TatkW
Thank you!
Offline
From your last dmesg you can see that the gpu "switch" is detected
[ 11.029550] vga_switcheroo: detected switching method \_SB_.PCI0.GFX0.ATPX handle
[ 11.029651] ATPX version 1, functions 0x00000033
[ 11.029710] ATPX Hybrid Graphics
but then something goes belly up when the amdgpu tries to (re)load the smu firmware. This may be either a driver bug or that particular card/implementation may need some quirk. You should give the current git kernel a try and if it doesn't work try with the lts kernel just to check if it might have worked before. If it doesn't work with the current git kernel you should definitely submit a bug report upstream: https://bugs.freedesktop.org/buglist.cg … lution=---
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
I have tested linux-lts, it doesn't help. I ran into an error compiling linux-git; I will try again, but I don't want to put too much effort into testing a kernel I plan to use exactly once. If I can't get it to work I'll try to find a precompiled version.
Offline
If you plan to report the problem upstream, testing with a git kernel is most probably the first thing you are going to be asked to try to check if the problem might have been fixed already. After that you may be requested to try patches with possible fixes so count on having to compile a git kernel more than once.
If you are using a linux-git package from the AUR it should just work but you may have found the git tree in a state that doesn't compile for some reason, just wait some time and give it a try later.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
If you wait for the linux mainline merge window to close and the first few release candidates to pass and the chance of it compiling and booting should be higher.
It is good practice to have backups of all your data just emphasizing this as you will be trying less tested code. You could also test 4.11 while waiting for the above to occur.
Offline
Another option is to test with the amd-staging kernel that has all the latest amd driver code, including the DC/DAL parts.
There's an AUR package for it, or you could use the one (different PKGBUILD then AUR) in Lordheavy's unofficial mesa-git repo.
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
I have a pretty similar setup (Intel HD5500 + R5 M330) and getting radeon to work required some trial and error, but I eventually succeeded with PRIME.
I thought I'd share some observations which might or might not apply to your hardware.
1) xrandr --listproviders shows radeon for me only if I add a device section for it in Xorg's configuration
2) Caveat: adding a device section only for the radeon driver results in Xorg launch failure with the 'no screens found' error, even if I add a relevant 'screen' section.
Adding a device section also for the i915 driver fixes it; I don't use the 'screen' section.
3) PRIME works for me even if xrandr --listproviders does not show radeon (no device section); I keep those sections for some tweaking, anyway.
4) I have to disable power management or I get the error.
What happens if you do
xrandr --setprovideroffloadsink 1 0
and then
DRI_PRIME=1 glxinfo | grep "OpenGL renderer"
?
Last edited by electric_indigo (2017-05-10 20:27:19)
Offline
electric_indigo:
xrandr --setprovideroffloadsink 1 0
gives
Could not find provider with index 1
normally, as no kernel module for the Radeon is loaded. Loading
radeon
does not help, and loading
amdgpu
crashes X.
Offline
Pages: 1