Hi Linus,

Please pull the 'agp-next' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/agp-2.6.git agp-next

This just contains some suspend/resume fixes for the SiS, Intel memory 
sizing fix for new hw, and support for more memory types on the nvidia 
AGP.

Dave.

 drivers/char/agp/amd-k7-agp.c |   38 ++++++++++++++++++++++++++++++++------
 drivers/char/agp/intel-agp.c  |   18 ++++++++++--------
 drivers/char/agp/nvidia-agp.c |   22 ++++++++++++++++++----
 3 files changed, 60 insertions(+), 18 deletions(-)

commit a64d2b37c2259e169759c1701ac565f0a11dc0ea
Author: Thomas Hellstrom <thomas-at-tungstengraphics-dot-com>
Date:   Wed Sep 10 14:13:33 2008 +0200

    agp/nvidia: Support agp user-memory on nvidia agp.
    
    This adds user memory support required for TTM to the nvidia AGP driver.
    
    Signed-off-by: Dave Airlie <airlied@redhat.com>

commit 2a32c3c894bcd3b3f8cc7e23f5ecbebca4a9f8e8
Author: Stuart Bennett <stuart@freedesktop.org>
Date:   Tue Aug 12 15:19:18 2008 +0100

    agp/amd-k7: Suspend support for AMD K7 GART driver
    
    Reinitialize bridge registers after suspend, but avoid repeating the ioremap
    
    Tested and works on AMD761
    
    Signed-off-by: Stuart Bennett <stuart@freedesktop.org>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

commit 44d494417278e49f5b42bd3ded1801b6d2254db8
Author: Keith Packard <keithp@keithp.com>
Date:   Tue Oct 14 17:18:45 2008 -0700

    agp/intel: Reduce extraneous PCI posting reads during init
    
    Instead of doing a posting read after each GTT entry update, do a single one
    at the end of the writes. This should reduce boot time a tiny amount by
    avoiding a lot of extra uncached reads.
    
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Eric Anholt <eric@anholt.net>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

commit 82e14a6215cbc9804ecc35281e973c6c8ce22fe7
Author: Eric Anholt <eric@anholt.net>
Date:   Tue Oct 14 11:28:58 2008 ...
[ message continues ]

Hi Dave,

One of those patches breaks X on my laptop with:

(II) intel(0): xf86BindGARTMemory: bind key 0 at 0x01f7f000 (pgoffset 8063)
(WW) intel(0): xf86BindGARTMemory: binding of gart memory with key 0
    at offset 0x1f7f000 failed (Invalid argument)

Fatal server error:
Couldn't bind memory for exa offscreen

(Found via bisect with some guessing)

If neccessary I can bisect further, but I guess you know what the problem is.

Andres


Xorg is: 1.5.2-2
Xorg Intel: 2.4.1-1ubuntu9



[ message continues ]

What type of laptop is it and what GPU has it.
if distros are carrying GM45 supporting stuff we might be in trouble..

Dave.
--

[ message continues ]

Hi Dave,

Its a Thinkpad T500 with a hybrid ATI/intel card, but the ATI card is disabled 
in bios (Intel card is not recognized properly if its enabled, havent started 
trying to track this down).
Vendor classifies the intel card as GMA 4500 MHD, and X says:
(II) intel(0): Integrated Graphics Chipset: Intel(R) Mobile Intel® GM45 
Express 
(--) intel(0): Chipset: "Mobile Intel® GM45 Express Chipset"

Andres
--

[ message continues ]

The GM45/G45 support in both kernel and user space was horribly broken,
causing the kernel to either overwrite stolen entries with freshly
allocated pages, and potentially corrupt the system, or leave some GTT
entries uninitialized and cause the hardware to lock up.

You appear to have a happy situation where this bug isn't obviously
breaking things. We couldn't find any machines where even simple 2D
graphics was stable for very long.

We applied a patch to both kernel and 2D driver (as both end up
computing the size of the GTT stolen area for historical reasons) to fix
this mistake. Updating your 2D driver to 2.4.98 should get you the other

Yeah, I'm getting information about how 'hybrid' graphics hardware
works.

--=20
keith.packard@intel.com
[ message continues ]

Hi,

Interesting. I had the system running for some days without problems related 
If you need some information/testing/whatever...

Andres
--

[ message continues ]

Hm. But still, there is at least one distribution (ubuntu intrepid) which will 
propably will ship 2.4.1 in its stable version soon (it seems unlikely that 
they will update to an unstable version just before an release).
Which means, that this driver will get quite some spread...
Is it accepted that the kernel abi breaks that radically/fast?

Andres
--

[ message continues ]

The problem is this isn't a kernel ABI at all. This is two pieces of code 
which are doing the exact same thing to a piece of hardware, one from the 
kernel and one from userspace. When they disagree things break, however 
sometimes when they agree things are broken. . The solution is proper 
kernel graphics drivers, however that future is further away.

--

[ message continues ]

Hi,

I opened a bugreport on their bugtracker to make them aware of the issue:
Hm, I understand what you are saying, but I don't see a fundamental difference 
to an ABI here. But it doesn't matter anyway...


Andres

--

[ message continues ]

We tested a pile of hardware and didn't find any GM45s that worked, so
we assumed they were all broken and that fixing the bug wouldn't cause
any working configurations to stop working.

We can hack up the kernel so the old X server just gets a WARN_ON
instead of breaking. This is a bit worrying though; the "fix" would let
user space continue to mis-program the hardware.

My concern here is that a common failure mode with this bug was to lock
up the graphics hardware and require a reboot. Having the X server fail
to start and leave the system in text mode where new packages can be
installed seems like a better mode than making the system hang during
boot.

--=20
keith.packard@intel.com
[ message continues ]

Hi,

Its basically only this, right?

diff --git a/src/i830_driver.c b/src/i830_driver.c
index c1d61f4..eaf5d27 100644
--- a/src/i830_driver.c
+++ b/src/i830_driver.c
@@ -502,8 +502,8 @@ I830DetectMemory(ScrnInfoPtr pScrn)
    range = gtt_size + 4;
 
    /* new 4 series hardware has seperate GTT stolen with GFX stolen */
-   if (IS_G4X(pI830))
-       range = 0;
+   if (IS_G4X(pI830) || IS_GM45(pI830))
+       range = 4;
 
    if (IS_I85X(pI830) || IS_I865G(pI830) || IS_I9XX(pI830)) {
       switch (gmch_ctrl & I855_GMCH_GMS_MASK) {

Barring that I have absolutely idea about the code and all related stuff, do I 
see it correct, that this also will result in problems if the kernel doesn't 
If its really only a that small portion of hardware... At least the T500/T400 
series, containing the same hw as mine, from Lenovo propably is not yet really 
Right.

Andres
--

[ message continues ]

Yes, on this hardware, the kernel is smashing the last few stolen
entries with a bad value, so running a new driver against an old kernel
will fail as well. There's not a lot we can do about this direction
though; until we have all of this hardware management in one place,

I haven't even received my x200s yet as they've just entered production.
The problem here was that the prototype hardware had a different
behavior than what is now shipping, so we didn't catch this mistake
until the first production machines were tested.

If you care to try the above fix against your current driver sources,
that would be helpful for us.

--=20
keith.packard@intel.com
[ message continues ]

Hi,

Ugly situation. So the distribution can't really do anything, because it will 
Will do so tomorrow morning, its 4am here ;-) and I finished the work I had to 
do tonight...


Greetings,

Andres
--

[ message continues ]

Hi Keith,

Ok, tested with 2.4.1 and  current linus git 
(0cfd81031a26717fe14380d18275f8e217571615) and it works without problems so 
far.

I have a good reason to say no to bisection requests now ;-) switching drivers 
every bisection run is annoying (unfortunately I could just cherry-pick the fix 
and rebase, but who knows that...)

Andres

--

[ message continues ]

Ahem, this is with the patch out of 4dd00681dd0f9fce8dfd4592b46418edbbd2eeb4  
applied...

Andres
--

[ message continues ]