From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: WIP POSTING_READ fix series Date: Fri, 3 Jun 2011 14:05:50 -0700 Message-ID: <20110603140550.1a39892c@jbarnes-desktop> References: <1307128822-9709-1-git-send-email-eric@anholt.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by gabe.freedesktop.org (Postfix) with SMTP id 8ACC59E8B1 for ; Fri, 3 Jun 2011 14:06:10 -0700 (PDT) In-Reply-To: <1307128822-9709-1-git-send-email-eric@anholt.net> 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: Eric Anholt Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Fri, 3 Jun 2011 12:20:18 -0700 Eric Anholt wrote: > Here's what I've been talking about on IRC today. Patch 3 appears to > make things work. Patch 4 should work, but re-breaks things (hangs > but no dmesg complaints). I want to understand why, but I'm running > out of theories. Perhaps there's some period of time where a write > has been PCI write posted but has not yet appeared in the GT FIFO? Or > perhaps there's some time after GT FIFO but before it's really handled > by hardware? Note that I was also able to fix the problem without > this series by just POSTING_READing 4 times instead of 1. The fact that patch 4 re-introduces the issue makes me think we still have a timing issue separate from the FIFO depth or force wake handling. How long does the function take to complete in both cases? Does simply delaying the posting_read to match the approximate force wake get/put time also get rid of the missed interrupts? If so, maybe we're missing some other aspect of the interrupt masking dance instead? -- Jesse Barnes, Intel Open Source Technology Center