Messages in this thread |  | | | From | Arnd Bergmann <> | | Subject | Re: [BISECTED] agp/intel: revert "Remove confusion of stolen entries not stolen memory" | | Date | Mon, 20 Dec 2010 22:54:35 +0100 |
| |
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
|  |