Nouveau - Jan 2015 - [Bug 88514] New: X segfaults when using prime offloading to nouveau card

https://bugs.freedesktop.org/show_bug.cgi?id=88514

            Bug ID: 88514
           Summary: X segfaults when using prime offloading to nouveau
                    card
           Product: xorg
           Version: unspecified
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Driver/nouveau
          Assignee: nouveau at lists.freedesktop.org
          Reporter: aidan at jmad.org
        QA Contact: xorg-team at lists.x.org

Created attachment 112362
  --> https://bugs.freedesktop.org/attachment.cgi?id=112362&action=edit
demsg from crash.

I am running Arch Linux, and I used to be able to use my discrete graphics card
for games using the method described below, but a while ago that stopped
working, I believe after an update of nouveau and/or the kernel.

I have:
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor
Integrated Graphics Controller (rev 06)
01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT 750M]
(rev a1) with nouveau drivers.

Steps to reproduce:
I run xrandr --setprovideroffloadsink nouveau Intel at the startup of my
desktop (cinnamon). Then I run DRI_PRIME=1 glxinfo (or any other openGL
application that I've tried (glxgears, Civ V)), and X crashes and bring me
back
to my display manager (lightdm).

Is there any other info you need, and/or did I report this issue completely
wrong?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150116/a71da0c6/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88514

--- Comment #1 from aidan at jmad.org ---
Created attachment 112363
  --> https://bugs.freedesktop.org/attachment.cgi?id=112363&action=edit
x log from crash.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150116/630af2a0/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88514

--- Comment #2 from Ilia Mirkin <imirkin at alum.mit.edu> ---
While the situation is less-than-ideal, I don't see how nouveau is
implicated.
Accel is disabled because you have the "pgraph is off and we can't
figure out
how to turn it on" issue (there's already a bug open about that, no
known
resolution). Perhaps you can get debug symbols to see where it's dying?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150116/e7a72f0a/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88514

--- Comment #3 from aidan at jmad.org ---
Could you point me towards the bug report you mentioned, I couldn't find it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150116/b0d04548/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88514

--- Comment #4 from Ilia Mirkin <imirkin at alum.mit.edu> ---
https://bugs.freedesktop.org/show_bug.cgi?id=70354
>From the backtrace, the crash appears to be happening in core X though...
but
perhaps as a result of something nouveau or intel is doing wrong.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150116/1f704278/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88514

--- Comment #5 from Tobias Klausmann <tobias.klausmann at mni.thm.de> ---
(In reply to Ilia Mirkin from comment #4)
> https://bugs.freedesktop.org/show_bug.cgi?id=70354
> 
> From the backtrace, the crash appears to be happening in core X though...
> but perhaps as a result of something nouveau or intel is doing wrong.
That seems to be likely the case. Try to remove xf86-video-nouveau or blacklist
nouveau_drv.so to let nouveau fallback to modesettings. Or you could
alternatively try the DRI3 variant of prime offloading:
http://nouveau.freedesktop.org/wiki/Optimus/

That wont fix the actual bug but may help to work around this.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150117/2c57df70/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88514

--- Comment #6 from aidan at jmad.org ---
Created attachment 112372
  --> https://bugs.freedesktop.org/attachment.cgi?id=112372&action=edit
backtrace from crash

I quickly compiled X with debug symbols, and this is what I got for a
backtrace.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150117/8007f35c/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88514

--- Comment #7 from aidan at jmad.org ---
(In reply to Tobias Klausmann from comment #5)
> (In reply to Ilia Mirkin from comment #4)
> > https://bugs.freedesktop.org/show_bug.cgi?id=70354
> > 
> > From the backtrace, the crash appears to be happening in core X
though...
> > but perhaps as a result of something nouveau or intel is doing wrong.
> 
> That seems to be likely the case. Try to remove xf86-video-nouveau or
> blacklist nouveau_drv.so to let nouveau fallback to modesettings. Or you
> could alternatively try the DRI3 variant of prime offloading:
> http://nouveau.freedesktop.org/wiki/Optimus/
> 
> That wont fix the actual bug but may help to work around this.
I might try one of these solutions.  A couple questions for DRI3: how do I
check if X and mesa have DRI3 support?  Also, what setup do I need to do?  Do I
just need to use DRI_PRIME=1, without using xrandr --setprovideroffloadsink
(like I would for DRI2)?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150117/26c4a5ea/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88514

--- Comment #8 from Tobias Klausmann <tobias.klausmann at mni.thm.de> ---
(In reply to aidan from comment #7)
(snip)
> I might try one of these solutions.  A couple questions for DRI3: how do I
> check if X and mesa have DRI3 support?  Also, what setup do I need to do? 
> Do I just need to use DRI_PRIME=1, without using xrandr
> --setprovideroffloadsink (like I would for DRI2)?
You'll need the setup described at the nouveau's prime page, linked
above,
other than that, you just have to do:
DRI_PRIME=1 app
and it will offload to nouveau

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150117/e88ff355/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88514

--- Comment #9 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to Tobias Klausmann from comment #8)
> (In reply to aidan from comment #7)
> (snip)
> > I might try one of these solutions.  A couple questions for DRI3: how
do I
> > check if X and mesa have DRI3 support?  Also, what setup do I need to
do?
> > Do I just need to use DRI_PRIME=1, without using xrandr
> > --setprovideroffloadsink (like I would for DRI2)?
> 
> You'll need the setup described at the nouveau's prime page, linked
above,
> other than that, you just have to do:
> DRI_PRIME=1 app
> and it will offload to nouveau
Except it won't work because we can't get accel going on his card...
this bug
should just be about the crash.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150117/0160ef21/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88514

--- Comment #10 from Chris Wilson <chris at chris-wilson.co.uk> ---
Right, the bug is just that we attempted to dereference a DRI2ScreenPtr on a
GPU screen for which DRI2 was never initialised (due to NoAccel). So we have 2
bugs:

1. The code should be more robust and only add an offload_slave if DRI2 was
enabled on that Screen (or be prepared for lies).

2. Nouveau shouldn't be claiming to be an offload slave if it doesn't
support
offloading (due to NoAccel).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150117/ad160d3b/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88514

--- Comment #11 from Chris Wilson <chris at chris-wilson.co.uk> ---
(In reply to Chris Wilson from comment #10)
> 2. Nouveau shouldn't be claiming to be an offload slave if it
doesn't
> support offloading (due to NoAccel).
Except, offloading may be eiter DRI2 or DRI3 so this doesn't make sense.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150117/351af857/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88514

--- Comment #12 from Chris Wilson <chris at chris-wilson.co.uk> ---
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 8b94b8f..e048224 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -158,6 +158,9 @@ GetScreenPrime(ScreenPtr master, int prime_id)
         DRI2ScreenPtr ds;

         ds = DRI2GetScreen(slave);
+        if (ds == NULL)
+            continue;
+
         if (ds->prime_id == prime_id)
             return slave;
     }

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150117/ae85462b/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=88514

Chris Wilson <chris at chris-wilson.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #13 from Chris Wilson <chris at chris-wilson.co.uk> ---
commit 082931014811e587a9734cbf4d88fd948979b641
Author: Chris Wilson <chris at chris-wilson.co.uk>
Date:   Sat Jan 17 10:09:54 2015 +0000

    dri2: SourceOffloads may be for DRI3 only

    As a DDX may declare offload support without supporting DRI2
    (because it is using an alternative acceleration mechanism like DRI3),
    when iterating the list of offload_source Screens to find a matching
    DRI2 provider we need to check before assuming it is DRI2 capable.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88514
    Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
    Reviewed-by: Dave Airlie <airlied at redhat.com>
    Signed-off-by: Keith Packard <keithp at keithp.com>

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150126/cf9ab24b/attachment.html>