Bug 88514

Created attachment 112363 [details]
x log from crash.

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?

Could you point me towards the bug report you mentioned, I couldn't find it.

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.

(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.

Created attachment 112372 [details]
backtrace from crash

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

(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)?

(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

(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.

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).

(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.

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;
     }

commit 082931014811e587a9734cbf4d88fd948979b641
Author: Chris Wilson <chris@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@chris-wilson.co.uk>
    Reviewed-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Keith Packard <keithp@keithp.com>