vesafb problem with 1GB Ram and possible fix

vesafb problem with 1GB Ram and possible fix

[Walt H]

I've got a Chaintech 7KDD dual processor 760MPX MB with 1 GB RAM. I had 
   problem getting vesafb or rivafb to work. I got ioremap errors during 
nitialization, which appear to be because vesafb tries to ioremap the 
entire 128MB framebuffer of my video card. It's a GeForce 4 Ti4600 with 
128MB Ram. Through correspondence on the general linux-kernel mailing 
list, I learned about changing the vmalloc reserved space from 128 to 
256MB, but that didn't work for me as it evidently blows away high-mem IO.

Well, here's what I've done. I've made a change in video/vesafb.c to
change __init vesafb_init to only allocate the amount of memory required 
  for the requested video mode of the framebuffer (I think). So far, it 
appears to work fine. I haven't tried many modes yet, but it's worked 
with what I've thrown at it. Thanks again,

The trivial change I made was changing this:

video_size	= screen_info.lfb_size * 65536;

to this:

video_size	= screen_info.lfb_width * screen_info.lfb_height * video_bpp;


I'm not a kernel hacker, so if I'm overlooking something please let me 
know. I've tested this a fair amount and it appears to be working on my 
end. Please CC me on any replies. Thanks,

-Walt




-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en

Re: vesafb problem with 1GB Ram and possible fix

[Antonino Daplas]

[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]

On Sat, 2003-03-29 at 04:59, Walt H wrote:
> I've got a Chaintech 7KDD dual processor 760MPX MB with 1 GB RAM. I had 
>    problem getting vesafb or rivafb to work. I got ioremap errors during 
> nitialization, which appear to be because vesafb tries to ioremap the 
> entire 128MB framebuffer of my video card. It's a GeForce 4 Ti4600 with 
> 128MB Ram. Through correspondence on the general linux-kernel mailing 
> list, I learned about changing the vmalloc reserved space from 128 to 
> 256MB, but that didn't work for me as it evidently blows away high-mem IO.
> 
> Well, here's what I've done. I've made a change in video/vesafb.c to
> change __init vesafb_init to only allocate the amount of memory required 
>   for the requested video mode of the framebuffer (I think). So far, it 
> appears to work fine. I haven't tried many modes yet, but it's worked 
> with what I've thrown at it. Thanks again,
> 
> The trivial change I made was changing this:
> 
> video_size	= screen_info.lfb_size * 65536;
> 
> to this:
> 
> video_size	= screen_info.lfb_width * screen_info.lfb_height * video_bpp;
> 
> 
> I'm not a kernel hacker, so if I'm overlooking something please let me 
> know. I've tested this a fair amount and it appears to be working on my 
> end. Please CC me on any replies. Thanks,
> 
> -Walt

I've submitted a similar patch to address problems such as the one
you're encountering.  It just adds an extra boot option to specify
amount of memory to remap.  Some applications will need more graphics
memory than the minimum required to display a particular mode (such as
for buffer flipping, offscreen caching, etc).  Attached is the message I
sent to the list a few days ago.

Tony



 

[-- Attachment #2: vesafb.txt --]
[-- Type: text/plain, Size: 4878 bytes --]

From linux-fbdev-devel-admin@lists.sourceforge.net Thu Mar 27 15:41:09 2003
Return-Path: <linux-fbdev-devel-admin@lists.sourceforge.net>
X-Sieve: cmu-sieve 2.0
Received: from sc8-sf-list2.sourceforge.net (lists.sourceforge.net
	[66.35.250.206]) by tom.po.com (8.12.8/8.12.2) with ESMTP id h2RKf9fP027806
	for <adaplas@pol.net>; Thu, 27 Mar 2003 15:41:09 -0500 (EST)
Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13]
	helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with
	esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 18yeA1-0003Q5-00; Thu, 27 Mar 2003
	12:39:41 -0800
Received: from pine.compass.com.ph ([202.70.96.37]) by
	sc8-sf-list1.sourceforge.net with smtp (Exim 3.31-VA-mm2 #1 (Debian)) id
	18ye9G-0003zY-00 for <linux-fbdev-devel@lists.sourceforge.net>; Thu, 27 Mar
	2003 12:38:54 -0800
Received: (qmail 78519 invoked from network); 27 Mar 2003 20:38:50 -0000
Received: from ap-202-70-105-57.compass.com.ph (202.70.105.57) by
	pine.compass.com.ph with SMTP; 27 Mar 2003 20:38:50 -0000
From: Antonino Daplas <adaplas@pol.net>
To: Linux Fbdev development list <linux-fbdev-devel@lists.sourceforge.net>
Content-Type: text/plain
Message-Id: <1048796361.977.6.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) 
Subject: [Linux-fbdev-devel] [PATCH]: vesafb - vram option
Sender: linux-fbdev-devel-admin@lists.sourceforge.net
Errors-To: linux-fbdev-devel-admin@lists.sourceforge.net
X-BeenThere: linux-fbdev-devel@lists.sourceforge.net
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
List-Help:
	<mailto:linux-fbdev-devel-request@lists.sourceforge.net?subject=help>
List-Post: <mailto:linux-fbdev-devel@lists.sourceforge.net>
List-Subscribe:
	<https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel>,
	<mailto:linux-fbdev-devel-request@lists.sourceforge.net?subject=subscribe>
List-Id: <linux-fbdev-devel.lists.sourceforge.net>
List-Unsubscribe:
	<https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel>,
	<mailto:linux-fbdev-devel-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive:
	<http://sourceforge.net/mailarchive/forum.php?forum=linux-fbdev-devel>
X-Original-Date: 28 Mar 2003 04:20:12 +0800
Date: 28 Mar 2003 04:20:12 +0800
X-Evolution-Source: pop://adaplas@pop.po.com/inbox
Content-Transfer-Encoding: 8bit

Attached is a diff against linux-2.5.66.

- Added vesafb option to specify amount of video RAM to remap.  This is
perhaps useful for people with machines with large amounts of system and
graphics RAM and vesafb fails to load due to failure to ioremap.

To use:  to remap only 1MiB of ram, add the ff. in your boot option:

video=vesafb:vram:1,<your other options>

Tony

diff -Naur linux-2.5.66-orig/Documentation/fb/vesafb.txt linux-2.5.66/Documentation/fb/vesafb.txt
--- linux-2.5.66-orig/Documentation/fb/vesafb.txt	2003-03-26 02:24:54.000000000 +0000
+++ linux-2.5.66/Documentation/fb/vesafb.txt	2003-03-27 20:10:01.000000000 +0000
@@ -146,7 +146,9 @@
 
 mtrr	setup memory type range registers for the vesafb framebuffer.
 
-
+vram:n  remap 'n' MiB of video RAM. If 0 or not specified, remap all
+	available video RAM. 
+  
 Have fun!
 
   Gerd
diff -Naur linux-2.5.66-orig/drivers/video/vesafb.c linux-2.5.66/drivers/video/vesafb.c
--- linux-2.5.66-orig/drivers/video/vesafb.c	2003-02-16 00:49:23.000000000 +0000
+++ linux-2.5.66/drivers/video/vesafb.c	2003-03-27 20:01:11.000000000 +0000
@@ -50,7 +50,7 @@
 
 static int             inverse   = 0;
 static int             mtrr      = 0;
-
+static int        vram __initdata = 0;
 static int             pmi_setpal = 0;	/* pmi for palette changes ??? */
 static int             ypan       = 0;  /* 0..nothing, 1..ypan, 2..ywrap */
 static unsigned short  *pmi_base  = 0;
@@ -206,6 +206,8 @@
 			pmi_setpal=1;
 		else if (! strcmp(this_opt, "mtrr"))
 			mtrr=1;
+		else if (! strncmp(this_opt, "vram:", 5))
+			vram = simple_strtoul(this_opt+5, NULL, 0);
 	}
 	return 0;
 }
@@ -226,6 +228,8 @@
 	vesafb_defined.yres = screen_info.lfb_height;
 	vesafb_fix.line_length = screen_info.lfb_linelength;
 	vesafb_fix.smem_len = screen_info.lfb_size * 65536;
+	if (vram && vram * 1024 * 1024 < vesafb_fix.smem_len)
+		vesafb_fix.smem_len = vram * 1024 * 1024;
 	vesafb_fix.visual   = (vesafb_defined.bits_per_pixel == 8) ?
 		FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR;
 



-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: vesafb problem with 1GB Ram and possible fix

[Walt H]

Antonino Daplas wrote:

> I've submitted a similar patch to address problems such as the one
> you're encountering.  It just adds an extra boot option to specify
> amount of memory to remap.  Some applications will need more graphics
> memory than the minimum required to display a particular mode (such as
> for buffer flipping, offscreen caching, etc).  Attached is the message I
> sent to the list a few days ago.
> 
> Tony
> 
<Patch snipped>

One question I've been wondering about with either one of these 
approaches has to do with mode changes. I might be mistaken, but if I 
remember correctly, video mode changes aren't supported for vesa 
framebuffers. Would you ever need to allocate additional memory other 
than that allocated at startup? I'm thinking that in the small tweak 
that I did, you can perhaps not allocate enough memory for some 
unforseen future event, although I can't think of any off hand. Then 
again, I'm not a kernel programmer, I could be way off base here.

-Walt



-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en

Re: vesafb problem with 1GB Ram and possible fix

[Antonino Daplas]

On Sun, 2003-03-30 at 04:24, Walt H wrote:
> > 
> <Patch snipped>
> 
> One question I've been wondering about with either one of these 
> approaches has to do with mode changes. I might be mistaken, but if I 
> remember correctly, video mode changes aren't supported for vesa 
> framebuffers. Would you ever need to allocate additional memory other 
> than that allocated at startup? I'm thinking that in the small tweak 
> that I did, you can perhaps not allocate enough memory for some 
> unforseen future event, although I can't think of any off hand. Then 
> again, I'm not a kernel programmer, I could be way off base here.
> 

True, vesafb does not support mode changes.  However, the extra graphics
memory is useful for some framebuffer-based applications that implement
multi-buffering. DirectFB, for instance, takes advantage of this since
it uses a frontbuffer and a backbuffer (display the frontbuffer, render
to the backbuffer, swap the front and backbuffer pointers, then display
the new frontbuffer).  Xine and mplayer using the framebuffer backend
are probably using similar setups. 

Tony  



-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en

Re: vesafb problem with 1GB Ram and possible fix

[Walt H]

Antonino Daplas wrote:

> True, vesafb does not support mode changes.  However, the extra graphics
> memory is useful for some framebuffer-based applications that implement
> multi-buffering. DirectFB, for instance, takes advantage of this since
> it uses a frontbuffer and a backbuffer (display the frontbuffer, render
> to the backbuffer, swap the front and backbuffer pointers, then display
> the new frontbuffer).  Xine and mplayer using the framebuffer backend
> are probably using similar setups. 
> 
> Tony  
> 
> 

Thanks for the info Tony. Sounds like my setup wouldn't be ideal for 
mass consumption. I don't use vesafb for anything other than the 
graphical console with large number of columns and rows, so it shouldn't 
affect me. I just needed a quick hack for a fix since I got a new MP 
system with lots 'o ram and no penguins :(  It's all good now though..

-Walt



-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en