From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com ([192.55.52.120]:16987 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751821AbdC0LJE (ORCPT ); Mon, 27 Mar 2017 07:09:04 -0400 From: Mika Kuoppala To: Chris Wilson Cc: intel-gfx@lists.freedesktop.org, "# v4 . 10+" Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/execlists: Wrap tail pointer after reset tweaking In-Reply-To: <20170327110004.GF10606@nuc-i3427.alporthouse.com> References: <20170327032815.19504-1-chris@chris-wilson.co.uk> <87fuhzxamn.fsf@gaia.fi.intel.com> <20170327110004.GF10606@nuc-i3427.alporthouse.com> Date: Mon, 27 Mar 2017 14:07:09 +0300 Message-ID: <87d1d3x9k2.fsf@gaia.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: stable-owner@vger.kernel.org List-ID: Chris Wilson writes: > On Mon, Mar 27, 2017 at 01:44:00PM +0300, Mika Kuoppala wrote: >> Chris Wilson writes: >> >> > If the request->wa_tail is 0 (because it landed exactly on the end of >> > the ringbuffer), when we reconstruct request->tail following a reset we >> > fill in an illegal value (-8 or 0x001ffff8). As a result, RING_HEAD is >> > never able to catch up with RING_TAIL and the GPU spins endlessly. If >> > the ring contains a couple of breadcrumbs, even our hangcheck is unable >> > to catch the busy-looping as the ACTHD and seqno continually advance. >> >> Tail is past ring size (on hw) and the ring contents has seqno writes. >> So we will replay the ring contents over and over and seqno advances >> and wraps back to the first breadcrumbs in ring? > > Yup. It was most confusing to watch. The execlist_port[] was static, > RING_START was static, yet the seqno kept changing. I felt like I was > hallucinating. That or insomnia. /o\ When we reset_common_ring() it is always after a hw reset. So the 'last' in sense of hardware's lrc contexts doesn't mean much. So can we actually get rid of the tail trickery as for first request after reset, as the lite restore can't happen and should not matter? -Mika > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre