diff mbox

[Intel-gfx] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]

Message ID 20130725215259.GB13295@cantiga.alporthouse.com (mailing list archive)
State New, archived
Headers show

Commit Message

Chris Wilson July 25, 2013, 9:52 p.m. UTC
On Thu, Jul 25, 2013 at 10:07:02PM +0200, Sedat Dilek wrote:
> What means the bang line?
> 
> [    54.564] (II) GLX: Initialized DRI2 GL provider for screen 0
> [    54.565] bang: 1159
> [    54.565]
> Fatal server error:
> [    54.565] failed to create screen resources

That means between the kernel reporting success for
DRM_IOCTL_I915_GEM_MMAP_GTT and libdrm returning from
drm_intel_gem_bo_map_gtt(), something went wrong. This implies that the
call to mmap() failed.

I don't see how changing versions of the ddx would unmask the bug, nor
why the mmap() should suddenly start failing. Anybody have any
suggestions other than


which is most likely to report EINVAL (22)?
-Chris

Comments

Chris Wilson July 25, 2013, 11:25 p.m. UTC | #1
On Fri, Jul 26, 2013 at 01:21:07AM +0200, Sedat Dilek wrote:
> On Thu, Jul 25, 2013 at 11:52 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > On Thu, Jul 25, 2013 at 10:07:02PM +0200, Sedat Dilek wrote:
> >> What means the bang line?
> >>
> >> [    54.564] (II) GLX: Initialized DRI2 GL provider for screen 0
> >> [    54.565] bang: 1159
> >> [    54.565]
> >> Fatal server error:
> >> [    54.565] failed to create screen resources
> >
> > That means between the kernel reporting success for
> > DRM_IOCTL_I915_GEM_MMAP_GTT and libdrm returning from
> > drm_intel_gem_bo_map_gtt(), something went wrong. This implies that the
> > call to mmap() failed.
> >
> > I don't see how changing versions of the ddx would unmask the bug, nor
> > why the mmap() should suddenly start failing. Anybody have any
> > suggestions other than
> >
> > diff --git a/src/intel_uxa.c b/src/intel_uxa.c
> > index 2f14173..3872258 100644
> > --- a/src/intel_uxa.c
> > +++ b/src/intel_uxa.c
> > @@ -1149,12 +1149,15 @@ Bool intel_uxa_create_screen_resources(ScreenPtr screen)
> >         PixmapPtr pixmap;
> >         intel_screen_private *intel = intel_get_screen_private(scrn);
> >         dri_bo *bo = intel->front_buffer;
> > +       int ret;
> >
> >         if (!uxa_resources_init(screen))
> >                 return FALSE;
> >
> > -       if (drm_intel_gem_bo_map_gtt(bo))
> > +       if ((ret = drm_intel_gem_bo_map_gtt(bo))) {
> > +               ErrorF("%s:%d bang, errno=%d\n", __func__, __LINE__, -ret);
> >                 return FALSE;
> > +       }
> >
> >         pixmap = screen->GetScreenPixmap(screen);
> >         intel_set_pixmap_bo(pixmap, bo);
> >
> > which is most likely to report EINVAL (22)?
> 
> Yupp, this shows me...
> 
> [    28.542] (II) GLX: Initialized DRI2 GL provider for screen 0
> [    28.543] intel_uxa_create_screen_resources:1158 bang, errno=22
> [    28.543]
> Fatal server error:
> [    28.543] failed to create screen resources

I'm out of ideas, could you bisect this? Either kernel, userspace or
both. Thanks,
-Chris
Chris Wilson July 26, 2013, 7:26 a.m. UTC | #2
On Fri, Jul 26, 2013 at 09:15:14AM +0200, Sedat Dilek wrote:
> For example: I could start my X with even doing ugly hacks like this...
> 
> [ intel-ddx (git) ]
> ...
> Bool intel_uxa_create_screen_resources(ScreenPtr screen)
> ...
> #if 0
> 	if (drm_intel_gem_bo_map_gtt(bo))
> 		return FALSE;
> #endif
> ...
> 
> ...with any other kernel.

Yes. Acquiring the map there is just a bit of paranoia to ensure we
having the mapping into the scanout already in place in case of
emergencies (and so don't fail along failure paths due to resource
conflicts).

Hmm, though we only started checking for map failures in 2.20.10 - which
would explain why going back to the older ddx masks the issue. And yes,
this means we do require a kernel bisect - or some passing inspiron.
-Chris
Chris Wilson July 26, 2013, 8:50 a.m. UTC | #3
On Fri, Jul 26, 2013 at 10:27:03AM +0200, Sedat Dilek wrote:
> On Fri, Jul 26, 2013 at 10:25 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> > ...
> > ... but does not start as well, so it seems to be a kernel-issue as
> > assumed (2nd confirmation).
> >
> > X.log attached.
> >
> 
> Now, really w/ promised attachment.

Yes, same failure (GTT mmaps) but at a later point, and UXA has no
fallback plan.
-Chris
Daniel Vetter July 26, 2013, 8:52 a.m. UTC | #4
On Fri, Jul 26, 2013 at 10:50 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> On Fri, Jul 26, 2013 at 10:27:03AM +0200, Sedat Dilek wrote:
>> On Fri, Jul 26, 2013 at 10:25 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>> > ...
>> > ... but does not start as well, so it seems to be a kernel-issue as
>> > assumed (2nd confirmation).
>> >
>> > X.log attached.
>> >
>>
>> Now, really w/ promised attachment.
>
> Yes, same failure (GTT mmaps) but at a later point, and UXA has no
> fallback plan.

I'm running igt on my machines here to prep a new -next test cycle,
and gtt mmaps seem to fail across the board :( Currently I'd wager
that the vma offset manager is the culprit, since I've only recently
pulled that stuff in from drm-next.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
diff mbox

Patch

diff --git a/src/intel_uxa.c b/src/intel_uxa.c
index 2f14173..3872258 100644
--- a/src/intel_uxa.c
+++ b/src/intel_uxa.c
@@ -1149,12 +1149,15 @@  Bool intel_uxa_create_screen_resources(ScreenPtr screen)
        PixmapPtr pixmap;
        intel_screen_private *intel = intel_get_screen_private(scrn);
        dri_bo *bo = intel->front_buffer;
+       int ret;
 
        if (!uxa_resources_init(screen))
                return FALSE;
 
-       if (drm_intel_gem_bo_map_gtt(bo))
+       if ((ret = drm_intel_gem_bo_map_gtt(bo))) {
+               ErrorF("%s:%d bang, errno=%d\n", __func__, __LINE__, -ret);
                return FALSE;
+       }
 
        pixmap = screen->GetScreenPixmap(screen);
        intel_set_pixmap_bo(pixmap, bo);