From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com ([192.55.52.93]:54471 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750876AbeEKP6a (ORCPT ); Fri, 11 May 2018 11:58:30 -0400 Subject: Re: [PATCH] drm/i915/oa: Disable OA on Haswell To: Chris Wilson , intel-gfx@lists.freedesktop.org Cc: Matthew Auld , Joonas Lahtinen , Rodrigo Vivi , Jani Nikula , stable@vger.kernel.org References: <20180511135602.13071-1-chris@chris-wilson.co.uk> <152604831741.14639.14005844103011393462@mail.alporthouse.com> <754f7720-d8c7-a934-678c-faf0a726b6e1@intel.com> <152605386089.14639.3256384478973355617@mail.alporthouse.com> From: Lionel Landwerlin Message-ID: <31a65c2f-0660-66c3-06d5-5c9d5b14bf62@intel.com> Date: Fri, 11 May 2018 16:58:27 +0100 MIME-Version: 1.0 In-Reply-To: <152605386089.14639.3256384478973355617@mail.alporthouse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: stable-owner@vger.kernel.org List-ID: On 11/05/18 16:51, Chris Wilson wrote: > Quoting Lionel Landwerlin (2018-05-11 16:43:02) >> On 11/05/18 15:18, Chris Wilson wrote: >>> Quoting Lionel Landwerlin (2018-05-11 15:14:13) >>>> My understanding of the virtual memory addressing from the GPU is limited... >>>> But how can the GPU poke at the kernel's allocated data? >>>> I thought we mapped into the GPU's address space only what is allocated >>>> through gem. >>> Correct. The HW should only be accessing the pages through the GTT and >>> the GTT should only contain known pages (or a pointer to the scratch >>> page). There is maybe a hole where we are freeing the memory before >>> the HW has finished using it (still writing through stale TLB and >>> whatnot even though the system has reallocated the pages), but other >>> than that quite, quite scary. Hence this awooga. >>> -Chris >>> >> I managed to reproduce a kasan backtrace on the same test. >> So it's not just the CI machine. >> >> But I can't even startup a gdm on that machine with drm-tip. So maybe >> there is some much more broken... > Don't leave us in suspense... Your first patch (check that OA is actually disabled) seems to get rid of the issue on my machine. Thanks a lot a for finding that! Trying to find when HSW when wrong now. Same kernel works just fine on my SKL. > >> i915/perf unpins the object correctly before freeing (at which point it >> could be reused). > Sure, but does perf know that the OA unit has stopped writing at that > point... That's not so clear (from my pov). Clearly it wasn't :( > >> Should we ensure i915_vma_destroy() i915/perf maybe? >> >> It almost seems like this is an issue that could arise in other part of >> the driver too. > The problem of the HW continuing to access the pages after unbinding is > inherent to the system (and what actually happens if we change PTE in > flight is usually undefined), hence the great care we go to track HW > activity and try not to release pages while it is still using them. > -Chris >