lkml.org 
[lkml]   [2010]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [BISECTED] agp/intel: revert "Remove confusion of stolen entries not stolen memory"
    From
    On Tue, Dec 21, 2010 at 7:54 AM, Arnd Bergmann <arnd@arndb.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@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.

    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2010-12-20 23:11    [W:4.455 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site