From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757357Ab3GZIZe (ORCPT ); Fri, 26 Jul 2013 04:25:34 -0400 Received: from mail-wg0-f44.google.com ([74.125.82.44]:58846 "EHLO mail-wg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753006Ab3GZIZ2 (ORCPT ); Fri, 26 Jul 2013 04:25:28 -0400 MIME-Version: 1.0 Reply-To: sedat.dilek@gmail.com In-Reply-To: <20130726072646.GH13295@cantiga.alporthouse.com> References: <20130725190006.GD11514@cantiga.alporthouse.com> <20130725192248.GA13295@cantiga.alporthouse.com> <20130725215259.GB13295@cantiga.alporthouse.com> <20130725232556.GF13295@cantiga.alporthouse.com> <20130726072646.GH13295@cantiga.alporthouse.com> Date: Fri, 26 Jul 2013 10:25:26 +0200 Message-ID: Subject: Re: [Intel-gfx] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ] From: Sedat Dilek To: Chris Wilson , Sedat Dilek , Daniel Vetter , Jani Nikula , Stephen Rothwell , intel-gfx , Linux Kernel Mailing List , DRI , linux-next , "s.dilek" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 26, 2013 at 9:26 AM, Chris Wilson 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sedat Dilek Subject: Re: linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ] Date: Fri, 26 Jul 2013 10:25:26 +0200 Message-ID: References: <20130725190006.GD11514@cantiga.alporthouse.com> <20130725192248.GA13295@cantiga.alporthouse.com> <20130725215259.GB13295@cantiga.alporthouse.com> <20130725232556.GF13295@cantiga.alporthouse.com> <20130726072646.GH13295@cantiga.alporthouse.com> Reply-To: sedat.dilek@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130726072646.GH13295@cantiga.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Chris Wilson , Sedat Dilek , Daniel Vetter , Jani Nikula , Stephen Rothwell , intel-gfx , Linux Kernel Mailing List , DRI , linux-next , "s.dilek" List-Id: linux-next.vger.kernel.org On Fri, Jul 26, 2013 at 9:26 AM, Chris Wilson 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