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 10:27:03 +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>
Subject: Re: [Intel-gfx] linux-next: Tree for Jul 25 [ call-trace: drm |
 drm-intel related? ]

On Fri, Jul 26, 2013 at 10:25 AM, Sedat Dilek <sedat.dilek@...il.com> wrote:
> On Fri, Jul 26, 2013 at 9:26 AM, Chris Wilson <chris@...is-wilson.co.uk> wrote:
>> 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.
>
> First confirmation...
> OK, next-20130726 shows the same symptoms!
>
> I tried diverse intel-ddx release and went back to v2.21.9... and
> searched for a version like v2.20.0 which has no checking for map
> failures...
>
> [ intel-ddx (v2.20.0) ]
> ...
> Bool intel_uxa_create_screen_resources(ScreenPtr screen)
> {
>         ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
>         intel_screen_private *intel = intel_get_screen_private(scrn);
>         dri_bo *bo = intel->front_buffer;
>
>         if (!uxa_resources_init(screen))
>                 return FALSE;
>
>         drm_intel_gem_bo_map_gtt(bo);
>
>         if (intel->use_shadow) {
>                 intel_shadow_create(intel);
>         } else {
>                 PixmapPtr pixmap = screen->GetScreenPixmap(screen);
>                 intel_set_pixmap_bo(pixmap, bo);
>                 intel_get_pixmap_private(pixmap)->pinned = 1;
>                 screen->ModifyPixmapHeader(pixmap,
>                                            scrn->virtualX,
>                                            scrn->virtualY,
>                                            -1, -1,
>                                            intel->front_pitch,
>                                            NULL);
>                 scrn->displayWidth = intel->front_pitch / intel->cpp;
>         }
> ...
> ... 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.

- S.

> - Sedat -
>
>> -Chris
>>
>> --
>> Chris Wilson, Intel Open Source Technology Centre

Download attachment "Xorg.0.log" of type "application/octet-stream" (96333 bytes)