Created attachment 97188 [details] xorg output w/ segfault & backtrace Good day, after updating to latest xf86-video-drivers, X segfaults when attempting to offload Nvidia-blob->Intel via randr 1.4 (PRIME, optimus). chipset: sandy bridge + nvidia 540M arch: linux 3.14.0 (also linux-next) xf86-video-intel: git xserver 1.15.0 libdrm: 2.4.52 (x)randr: git distro: gentoo mixed amd64 multilib machine: Ideapad Z570 my .xinitrc: xrandr --setprovideroutputsource "Intel" NVIDIA-0 xrandr --auto exec awesome After reverting back 'stable' xf86-video-intel, everything works as expected. X crashes on second command from .xinitrc (^): xrandr --auto. When I put "xrandr --listproviders > /home/$USER/xout" in between setprovider command and auto, output was as expected (listing both nvidia and intel, with correct capabilities). If any more information is needed, I'm happy to provide it. Have a nice day.
Created attachment 97189 [details] Full Xorg log, previous attachment only contained backtrace
Sry for spam, relevant topic @nvidia dev forums (where I reported the bug first, since I generally only ran into troubles on nvidia side of things). https://devtalk.nvidia.com/default/topic/726956/linux/-notabug-offloading-no-longer-works-problem-with-latest-intel-drivers-/
If you can compile xf86-video-intel.git with ./configure --enable-debug=full and send me the Xorg.0.log, that would be most useful.
Hmm, if you have no display devices connected to nvidia, why use it as the primary? SNB GT2 should be faster for rendering 2D and compositing than a GT540m, and then you can power down the dGPU except for when you need the extra 3D capabilities.
Created attachment 97192 [details] recompiled with debug options
#4: Mainly due to VDPAU support in adobe flash and also due to the fact that I like trying out new stuff and look forward to see optimus working on Linux laptops. And yes, I've tried vdpau emulation via libva :-] PS: log doesn't look particularly useful, at least to me, perhaps I will need to recompile stuff with debug symbols and disable hardening (or I could git bisect the problem if needed).
That wasn't where I was expecting! Can you please run addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0xb88b3 0xb904e 0xba8aa
(In reply to comment #6) > #4: Mainly due to VDPAU support in adobe flash and also due to the fact that > I like trying out new stuff and look forward to see optimus working on Linux > laptops. > And yes, I've tried vdpau emulation via libva :-] Shouldn't vdpau work with DRI offloading though?
Yeah, you might need the debug symbols, or use the unstripped library in the build tree.
addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0xb88b3 0xb904e 0xba8aa Gives me: ??:0 ??:0 ??:0 So no joy, since i'm lazy to recompile stuff atm, wouldn't magic of /proc/kallsyms suffice here? edit: erm, no joy, since stuff from kallsyms seems to be randomized (damn hardening). #8: not quite sure, perhaps via some override it could work in the way you suggest, but vdpauinfo complains and it hasn't worked automagically for me in the past. I will get vanilla kernel and set it up with more sane options such as frame pointers :-] (might take some while, worst case i'll report tommorow).
#10, just realized its userspace module so kallsyms make no sense. Interestlingy enough, my toolchain created separated debug symbols... any ideas?
If you built debug symbols, they were stripped upon installation. If you still have the build tree around you can point addr2line to xf86-video-intel/src/.libs/intel_drv.so instead.
Gotcha. /var/tmp/tc/xf86-video-intel/src/sna/sna_display.c:3440 /var/tmp/tc/xf86-video-intel/src/sna/sna_display.c:3627 /var/tmp/tc/xf86-video-intel/src/sna/sna_display.c:4081
I've (re) installed from source and then used addr2line on debug symbols, hopefully pointers still remained valid.
If not I can load my debug kernel and provide coredump (perhaps I should have done that in first place).
I had a funny feeling it was going to be that.
Created attachment 97195 [details] [review] Only reload HW cursors This should prevent the crash. Though I am not sure why PRIME forces software cursors.
works for me, well done sir.
commit 4950bc4fea80d44dde798f3f8b5a07eee1555a63 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Apr 10 22:26:42 2014 +0100 sna: Only reload an active HW cursor Do not attempt to restore the cursor handle if a SW cursor is currently active. In particular, this prevents a crash after modesetting if we never had a real cursor (for example output offloading). Reported-by: Tomas Pruzina <pruzinat@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77283 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Now if you can work out the magic to control which GPU vdpau runs on, we will be laughing.
:-] I think that I'll write on mailing list about that and create separate tracking bug for that.
Hmm, left a booby trap in there. Silly me for trying to do 2 things at once. :( Make sure you update again before X crashes.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.