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: Tue, 21 Dec 2010 08:08:16 +1000 From: Dave Airlie <airlied@...il.com> To: Arnd Bergmann <arnd@...db.de> Cc: Chris Wilson <chris@...is-wilson.co.uk>, 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 Tue, Dec 21, 2010 at 7:54 AM, Arnd Bergmann <arnd@...db.de> wrote: > On Monday 20 December 2010 22:06:47 Chris Wilson wrote: >> 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(); > > 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. I wonder if the ACPI table mapping stuff is in -next yet. As a first guess. Dave. -- 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