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:25:26 +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>,
	"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 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.

- 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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ