[Intel-gfx] xf86-video-intel: Commit 08ebde4715b87867184d42b60762cd774e151f5c breaks kernel memory manager allocation

Wu Fengguang fengguang.wu at intel.com
Thu Apr 30 10:41:27 CEST 2009


On Wed, Apr 22, 2009 at 10:05:00PM +0800, Magnus Kessler wrote:
> On Wednesday 22 Apr 2009 13:00:03 Wu Fengguang wrote:
> > On Wed, Apr 22, 2009 at 07:56:37PM +0800, Wu Fengguang wrote:
> > > On Wed, Apr 22, 2009 at 06:06:18PM +0800, Magnus Kessler wrote:
> > > > On Wednesday 22 Apr 2009 01:40:05 Zhenyu Wang wrote:
> > > > > On 2009.04.21 20:29:26 +0800, Magnus Kessler wrote:
> > > > > > Hi Zhenyu,
> > > > > >
> > > > > > your commit 08ebde4715b87867184d42b60762cd774e151f5c to the intel
> > > > > > video driver breaks kernel memory allocation for me on a 64 bit
> > > > > > platform. Reverting the patch gets me back to a working driver. The
> > > > > > relevant output from xorg.log is:
> > > > >
> > > > > sorry, I didn't test Fengguang's patch on 64 bit system, on which his
> > > > > patch aims to fix a compiler warning...
> > > > >
> > > > > Fengguang, have you tested this on x86_64 with recent kernel?
> > >
> > > Sorry I just tested it out - I found the drm mode was not enabled
> > > because of another bug (which I'll report later).
> > >
> > > My configurations are:
> > >         - 64bit kernel/user space
> > >         - kernel is 2.6.30-rc2-next-20090417
> > >         - intel gfx driver is 2.7.99.1.
> > >
> > > The interesting thing is that the lines
> > >
> > >        pScrn->videoRam = ~0UL / KB(1);
> > > or
> > >        pScrn->videoRam = UINT_MAX / KB(1);
> > > or
> > >        pScrn->videoRam = INT_MAX / KB(1);
> > >
> > > produce output
> > >
> > >         (==) intel(0): VideoRam: -1 KB
> > > or
> > >         (==) intel(0): VideoRam: 4194303 KB
> > > or
> > >         (EE) intel(0): Failed to allocate space for kernel memory manager
> > >         (==) intel(0): VideoRam: 2097151 KB
> > >
> > > The first two produces no further error messages in my system, and
> > > _all_ have cluttered display (which I'm not sure if is related to the
> > > videoRam madness).
> > >
> > > > > Magnus, any possible to ErrorF some debug message on why memory
> > > > > manager allocation failed?
> > > >
> > > > I'm happy to try out any suggestion. What part of the code do you want
> > > > additional debug output for?
> > > >
> > > > As a general observation I note that the VideoRam size value goes
> > > > through a succession of (int) <-> (unsigned long) conversions before
> > > > reaching i830_allocate_aperture, which ultimately fails with commit
> > > > 08ebde47. This strikes me as not particularly 64-bit clean.
> > >
> > > Yep, 'unsigned long' should be better for 'videoRam' in the long term.
> >
> > Oh, it looks like the change of type is discouraged:
> >
> > /*
> >  * ScrnInfoRec
> >  *
> >  * There is one of these for each screen, and it holds all the
> > screen-specific * information.
> >  *
> >  * Note: the size and layout must be kept the same across versions.  New
> >  * fields are to be added in place of the "reserved*" fields.  No fields
> >  * are to be dependent on compile-time defines.
> >  */
> >
> > Thanks,
> > Fengguang
> >
> 
> I wasn't suggesting to change any Xorg SDK types. Widening the integer type in 
> the intel driver should not be a problem. However, looking closely at the 
> calling chain leading up to i830_allocate_aperture() in i830_allocator_init () 
> the unsigned long size parameter to i830_allocator_init() is narrowed to int 
> when it is assigned to mmsize just prior to calling i830_allocate_aperture() 
> (lines 497-526). i830_allocate_aperture() then expects to get an unsigned long 
> again. The obvious change here (making mmsize unsigned long) does not change 
> the outcome, though, when videoRam is INT_MAX / 1024.
> 
> I will gladly test any changes you come up with.

Magnus, this patch worked for me :-)

Thanks,
Fengguang
---
Use zero videoRam size in drm mode

Explictly set videoRam to 0 in drm mode, to indicate "no size limit".
The previous "~0UL / KB(1)" is a hack and is not 64bit clean.

Signed-off-by: Wu Fengguang <fengguang.wu at intel.com>
---
 src/i830_driver.c |    2 +-
 src/i830_memory.c |    5 ++++-
 2 files changed, 5 insertions(+), 2 deletions(-)

--- xf86-video-intel.orig/src/i830_driver.c
+++ xf86-video-intel/src/i830_driver.c
@@ -2550,7 +2550,7 @@ I830ScreenInit(int scrnIndex, ScreenPtr 
 
    if (pI830->use_drm_mode) {
        pI830->stolen_size = 0;
-       pScrn->videoRam = ~0UL / KB(1);
+       pScrn->videoRam = 0;
    } else {
        I830AdjustMemory(pScreen);
    }
--- xf86-video-intel.orig/src/i830_memory.c
+++ xf86-video-intel/src/i830_memory.c
@@ -394,6 +394,9 @@ i830_allocator_init(ScrnInfoPtr pScrn, u
 	return FALSE;
     }
 
+    if (size == 0) /* use_drm_mode: no size limit */
+	    size = ULONG_MAX;
+
     start->key = -1;
     start->offset = offset;
     start->end = start->offset;
@@ -425,7 +428,7 @@ i830_allocator_init(ScrnInfoPtr pScrn, u
      * rather than after DRIFinishScreenInit.
      */
     if (pI830->directRenderingType == DRI_DRI2 && has_gem) {
-	int mmsize;
+	unsigned long mmsize;
 
 	/* Take over all of the graphics aperture minus enough to for
 	 * physical-address allocations of cursor/overlay registers.



More information about the Intel-gfx mailing list