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
| ||
|
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/
Powered by blists - more mailing lists