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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <0d30dc$kh41r4@orsmga001.jf.intel.com>
Date:	Mon, 20 Dec 2010 21:06:47 +0000
From:	Chris Wilson <chris@...is-wilson.co.uk>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	linux-kernel@...r.kernel.org, David Airlie <airlied@...ux.ie>
Subject: Re: [BISECTED] agp/intel: revert "Remove confusion of stolen entries not stolen memory"

On Mon, 20 Dec 2010 21:52:38 +0100, Arnd Bergmann <arnd@...db.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/