On Mon, May 06, 2013 at 08:37:37PM +0200, Daniel Vetter wrote: > On Mon, May 6, 2013 at 8:03 PM, Ben Widawsky <ben at bwidawsk.net> wrote: > > On Mon, May 06, 2013 at 11:48:05AM +0200, Daniel Vetter wrote: > >> On Thu, May 02, 2013 at 01:28:23PM -0700, Jesse Barnes wrote: > >> > On Tue, 23 Apr 2013 23:15:30 -0700 > >> > Ben Widawsky <ben at bwidawsk.net> wrote: > >> > > >> > > Because PPGTT PDEs within the GTT are calculated in cachelines > >> > > (HW guys consistency ftw) we do a divide which will wreak havoc if this > >> > > is wrong, and I know that from experience). > >> > > > >> > > If/when we move to multiple PPGTTs this will have to become a WARN, and > >> > > return an error. For now however it should always be considered fatal, > >> > > and only a developer could hit it. > >> > > > >> > > Signed-off-by: Ben Widawsky <ben at bwidawsk.net> > >> > > --- > >> > > drivers/gpu/drm/i915/i915_gem_gtt.c | 2 ++ > >> > > 1 file changed, 2 insertions(+) > >> > > > >> > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c > >> > > index 50df194..0503f09 100644 > >> > > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c > >> > > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > >> > > @@ -85,6 +85,8 @@ static int gen6_ppgtt_enable(struct drm_device *dev) > >> > > uint32_t pd_entry; > >> > > int i; > >> > > > >> > > + BUG_ON(ppgtt->pd_offset & 0x3f); > >> > > + > >> > > pd_addr = (gen6_gtt_pte_t __iomem*)dev_priv->gtt.gsm + > >> > > ppgtt->pd_offset / sizeof(gen6_gtt_pte_t); > >> > > for (i = 0; i < ppgtt->num_pd_entries; i++) { > >> > > >> > Reviewed-by: Jesse Barnes <jbarnes at virtuousgeek.org> > >> > >> Queued for -next with the same s/BUG/WARN bikeshed, thanks for the patch. > >> -Daniel > > > > If you're going to change to WARN, please fixup the patch to return > > early... if (WARN_ON(...)) return > > > > The GPU will end up hanging if we've messed this up... > > I don't care about the gpu, only that the logs hit the disc. And I > don't see how an early return can safe anything in here, since > something went horribly wrong already anyway. > -Daniel Seriously? Feels a bit like this has become an argument for arguments sake, but: I'd much rather have an assertion fail than a gpu error state from same random point in time later. > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Ben Widawsky, Intel Open Source Technology Center