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: <AANLkTi=aXG+mOku=23e9ssfVx7dnQqeFJd_T1GBk=-gK@mail.gmail.com>
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/