linux-kernel - Re: [Intel-gfx] linux-next: Tree for Jul 25 [ call-trace: drm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 26 Jul 2013 09:15:14 +0200
From:	Sedat Dilek <sedat.dilek@...il.com>
To:	Chris Wilson <chris@...is-wilson.co.uk>,
	Sedat Dilek <sedat.dilek@...il.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Jani Nikula <jani.nikula@...ux.intel.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	intel-gfx <intel-gfx@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	DRI <dri-devel@...ts.freedesktop.org>,
	linux-next <linux-next@...r.kernel.org>
Cc:	"s.dilek" <s.dilek@...erlin.de>
Subject: Re: [Intel-gfx] linux-next: Tree for Jul 25 [ call-trace: drm |
 drm-intel related? ]

On Fri, Jul 26, 2013 at 1:25 AM, Chris Wilson <chris@...is-wilson.co.uk> wrote:
> 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@...is-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,

I will wait for today's official Linux-next (next-20130726) release
and check if the issue still exists (might be I mismerged).
Cannot promise for bisecting, but for me it seems to be a
"kernel-related" issue.
So, my 1st bisect-strategy would be to see before/after drm-intel
merge into -next.

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.

- Sedat -

> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/