Looks like same bug as 58151.

Can you please improve the "*ERROR* Attempting to bind an object larger than the aperture" so that it includes the requested size and the aperture size so that we can see which of those values is odd?

Need to recompile kernel. Since kernel is optimized for a specific pc the drm modules were not compiled as modules and since I removed the kernelsources by mistake. Also enabled debugging for the i915/drm modules.

Sorry, this will take a little time.

Will be continued later.

Need some help here:
The kernel is configured, part of the graphics drivers.
CONFIG_AGP=y
CONFIG_AGP_INTEL=y
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=16
CONFIG_VGA_SWITCHEROO=y
CONFIG_DRM=m
CONFIG_DRM_KMS_HELPER=m
CONFIG_DRM_I915=m
CONFIG_DRM_I915_KMS=y
CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DDC=m
CONFIG_FB_CFB_FILLRECT=m
CONFIG_FB_CFB_COPYAREA=m
CONFIG_FB_CFB_IMAGEBLIT=m
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
CONFIG_FB_INTEL=m
CONFIG_FB_INTEL_DEBUG=y
CONFIG_FB_INTEL_I2C=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=m
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_DISPLAY_SUPPORT=m

Problem: module is loaded when I log in and I can't unload it since it's being used. Where can I see what memory is requested? What options I need to use and where?

I tried unloading and loading the module manually, but without result.

The fact that the system is not working does not mean the module can't be removed, unfortunately. Some service is still locking the i915 module...

We need to add something like:

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b3c8abd..f0b9ee81 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2995,7 +2995,10 @@ i915_gem_object_bind_to_gtt(struct drm_i915_gem_object *obj,
 	 */
 	if (obj->base.size >
 	    (map_and_fenceable ? dev_priv->gtt.mappable_end : dev_priv->gtt.total)) {
-		DRM_ERROR("Attempting to bind an object larger than the aperture\n");
+		DRM_ERROR("Attempting to bind an object larger than the aperture: object=%ld > %s aperture=%ld\n",
+			  obj->base.size,
+			  map_and_fenceable ? "mappable" : "total",
+			  map_and_fenceable ? dev_priv->gtt.mappable_end : dev_priv->gtt.total);
 		return -E2BIG;
 	}

Compilation is running. Hope to post the results later this evening.

Rewrote the patch to:
--- drivers/gpu/drm/i915/i915_gem.c     2013-05-20 18:12:16.045666581 +0200
+++ ../linux-3.2.45-2/drivers/gpu/drm/i915/i915_gem.c   2013-05-20 18:06:12.947864729 +0200
@@ -2759,7 +2759,10 @@
         */
        if (obj->base.size >
            (map_and_fenceable ? dev_priv->mm.gtt_mappable_end : dev_priv->mm.gtt_total)) {
-               DRM_ERROR("Attempting to bind an object larger than the aperture\n");
+                DRM_ERROR("Attempting to bind an object larger than the aperture: object=%ld > %s aperture=%ld\n",
+                      obj->base.size,
+                      map_and_fenceable ? "mappable" : "total",
+                      map_and_fenceable ? dev_priv->mm.gtt_mappable_end : dev_priv->mm.gtt_total);
                return -E2BIG;
        }

With the patch the dmesg information reads like this:

[   18.886066] [drm] initialized overlay support
[   19.102610] [drm:i915_gem_object_bind_to_gtt] *ERROR* Attempting to bind an object larger than the aperture: object=7057408 > mappable aperture=0
[   19.258809] [drm:intelfb_create] *ERROR* failed to pin fb: -7
[   19.328556] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

For completeness I'll add the used config later.

Created attachment 102101 [details]
Kernel configuration used

Created attachment 102111 [details]
Extended output from dmesg 

Just for completeness the drm debug output from dmesg.
(cmdline: BOOT_IMAGE=/boot/vmlinuz-3.2.45-vanilla-2 root=/dev/sda2 ro drm.debug=14)

Just lots of messages.

Bisect result would be rather interesting here. Also, are more recent kernels (like 3.9) also affected?

Haven used 3.9.x yet, since I haven't had the time to configure it.

I'll see if I can find some time later this week.

First results:
3.9.3 works fine
first bisection between 3.2.44 and 3.2.45 also (1st of 6 steps...).

I'll continue bisecting later this week.

Results of bisecting are a little unexpected:
 $ git bisect good
..
 $ git bisect good
..
 $ git bisect good
Bisecting: 14 revisions left to test after this (roughly 4 steps)
[40c157ba78681c45cc62dabde406b44ca3c76c2b] iucv: Fix missing msg_namelen update in  iucv_sock_recvmsg()
..
$ git bisect good
Bisecting: 7 revisions left to test after this (roughly 3 steps)
[8431bc6fb3dc3784973cc9471197e34b16f38b3b] sparc64: Fix race in TLB batch processing.
..
$ git bisect good
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[0e6f42bb651bb61744d529a9cfe540e292fad98a] kernel/audit_tree.c: tree will leak memory when failure occurs in audit_trim_trees()
..
 $ git bisect bad
..
 $ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[03000102c151f4dab9a38aee831182df3be748d1] r8169: fix 8168evl frame padding.

Could anyone help me with a manual how to revise the last patch, just to be sure?

git bisect output is a bit confusing, but you still have one more step to go (i.e. you need to still the git bisect whether the commit 03000102c151f4da is good/bad). Then git bisect should tell you the first bad commit.

$ git bisect good
53e587aa5ca81497d0ea6e340320ec5778d1f311 is the first bad commit
commit 53e587aa5ca81497d0ea6e340320ec5778d1f311
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Nov 15 11:32:18 2012 +0000

    drm/i915: Fix detection of base of stolen memory
    
    commit e12a2d53ae45a69aea499b64f75e7222cca0f12f upstream.
    
    The routine to query the base of stolen memory was using the wrong
    registers and the wrong encodings on virtually every platform.
    
    It was not until the G33 refresh, that a PCI config register was
    introduced that explicitly said where the stolen memory was. Prior to
    865G there was not even a register that said where the end of usable
    low memory was and where the stolen memory began (or ended depending
    upon chipset). Before then, one has to look at the BIOS memory maps to
    find the Top of Memory. Alas that is not exported by arch/x86 and so we
    have to resort to disabling stolen memory on gen2 for the time being.
    
    Then SandyBridge enlarged the PCI register to a full 32-bits and change
    the encoding of the address, so even though we happened to be querying
    the right register, we read the wrong bits and ended up using address 0
    for our stolen data, i.e. notably FBC.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    [bwh: Backported to 3.2: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

:040000 040000 323812cac24bd796efa71220b496ee5a2a00d298 101967a69bc453f845daf3a7a3024ebd932984dc M      drivers

Hm, that's interesting. Can you please test 3.9.x also to check whether this regression is due to backporting into 3.2.x kernels or a general issue with the upstream code?

I suspect the former since the code seems to work on most upstream systems and shouldn't even be used on 3.2 for anything at all.

Oh,I see the problem now. The stray 'return 0' from moving the code from i915_gem_init_stolen to i915_load_gem_init.

See comment #12: "3.9.3 works fine".

Thanks for your support.

(In reply to comment #18)
> See comment #12: "3.9.3 works fine".

Oops, I've tried to look for it but failed to find it. I'll send a mail to the 3.2 stable maintainer asking him to revert this patch. That should take care of things.

Thanks a lot for reporting this issue.

*** Bug 58151 has been marked as a duplicate of this bug. ***

Since I'll like loose track closing. Please yell if the revert doesn't land in a 3.2.x release soon.

3.9.2 works fine.
@Daniel Vetter, please gime the patch for test in 3.2.44 and confirm.

@Daniel Vetter

I can confirm. Using the commit 53e587aa5ca81497d0ea6e340320ec5778d1f311 as
.patch file, the bug is solved:


[root@nix linux-3.2.45]# patch -R -p1 < patch-revert-i915.patch 
patching file drivers/gpu/drm/i915/i915_dma.c
patching file drivers/gpu/drm/i915/i915_drv.h
patch unexpectedly ends in middle of line
Hunk #1 succeeded at 581 with fuzz 1.


Boot with screen, fb, backlight control and resolution ok.