From: Arnd Bergmann <arnd@arndb.de>
To: Chris Wilson <chris@chris-wilson.co.uk>
Subject: Re: [BISECTED] agp/intel: revert "Remove confusion of stolen entries not stolen memory"
Date: Mon, 20 Dec 2010 22:54:35 +0100
User-Agent: KMail/1.13.5 (Linux/2.6.37-rc6-next-20101220+; KDE/4.5.1; x86_64; ; )
Cc: linux-kernel@vger.kernel.org, David Airlie <airlied@linux.ie>
References: <201012201912.19051.arnd@arndb.de> <201012202152.38863.arnd@arndb.de> <0d30dc$kh41r4@orsmga001.jf.intel.com>
In-Reply-To: <0d30dc$kh41r4@orsmga001.jf.intel.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201012202254.35185.arnd@arndb.de>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2564
Lines: 62

On Monday 20 December 2010 22:06:47 Chris Wilson wrote:
> On Mon, 20 Dec 2010 21:52:38 +0100, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday 20 December 2010 20:52:07 Chris Wilson wrote:
> > > 
> > > Also, which modules do you have loaded when using VESA? i.e. is the
> > > i915.ko loaded, but in UMS mode (i915.modeset=0)?
> > 
> > This doesn't seem to matter, as far as I can tell, i915 can be loaded
> > or now.
> 
> Thanks, that rules out the likely explanation that we [i915] loaded the
> GTT with some conflicting entries. Instead it is likely the initialisation
> of the GTT to point to the scratch page that is triggering the problem.
> Can you try disabling it with:
> 
> diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
> index 356f73e..238848e 100644
> --- a/drivers/char/agp/intel-gtt.c
> +++ b/drivers/char/agp/intel-gtt.c
> @@ -867,11 +867,13 @@ static int intel_fake_agp_configure(void)
>  
>  	agp_bridge->gart_bus_addr = intel_private.gma_bus_addr;
>  
> +#if 0
>  	for (i = 0; i < intel_private.base.gtt_total_entries; i++) {
>  		intel_private.driver->write_entry(intel_private.scratch_page_dma,
>  						  i, 0);
>  	}
>  	readl(intel_private.gtt+i-1);	/* PCI Posting. */
> +#endif
>  
>  	global_cache_flush();

Yes, this works as well, good catch!

> > I've seen the system crash once while loading i915 with
> > modeset=1 and my revert patch applied and backed it out.
> > 
> > After that, I could no longer even get i915 to do modesetting,
> > the ioremap in intel_opregion_setup now fails because reserve_memtype
> > decides that the opregion should be write-back when we ask for
> > an uncached mapping. That's probably an unrelated problem, but
> > I'm mentioning it anyway in case it's significant.
> 
> I hope not. But it sounds like we're in for a turbulent ride if ioremap is
> failing in -next.

It only fails for the opregion. I feel I've done enough bisecting for today,
but it's certainly broken in -next and the ioremap works in 2.6.37-rc6.
Should the opregion actually be writeback cached? Maybe something is
wrong in reserve_memtype.

Loading i915 in -rc6 also crashes my system hard when modeset=1, but
that may be a hardware problem -- the same one that used to cause occasional
hangs with i915 KMS, forcing me to run X11 with the vesa driver.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/