Re: [BISECTED] agp/intel: revert "Remove confusion of stolen entries not stolen memory"

[Chris Wilson <chris@chris-wilson.co.uk>]

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();

> 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.

Thanks,
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre