vesafb problem

vesafb problem

[Walt H]

Hello all,

I've got a strange problem with my 760MPX system dual proc system. If I 
try to use vesafb to setup the video on boot, the system will boot fine, 
but will be unable to display anything on the console. The system 
appears to be largely unaffacted by any underlying problem, as it is 
stable after boot and seems to run fine. In looking through logs 
afterward, I find these suspect messages:

mtrr: your CPUs had inconsistent fixed MTRR settings
vesafb: abort, cannot ioremap video memory 0x8000000 @ 0xe8000000

I've tried using the rivafb frame buffer, which also does not work. From 
what I could see in scanning the archives, this appears to possibly be a 
BIOS issue, however, I'm game to throw nearly anything at it to try and 
resolve it. Hardware is as follows:

Chaintech 7KDD 760MPX chipset motherboard
2 x AMD 2400MP
1 GB Ram
Nvidia GeForce 4600

I've tried a vanilla 2.4.20 linux kernel as well as my current 2.4.20-ck 
patched kernel, both with same result. I've also tried compiling as UP, 
which has no effect. I'm currently using acpi and apic, however, I've 
tried disabling both, to no avail. Any other ideas? Please CC me, as I'm 
not susbscribed. Thanks,

-Walt

PS. Maybe unrelated, but... I have to pass mem=nopentium as boot param, 
otherwise I system appears to get corrupted memory issues within short 
period of time after boot. ie: unable to launch apps, segfaults etc...

Re: vesafb problem

[Jurriaan]

From: Walt H <waltabbyh@comcast.net>
Date: Thu, Mar 27, 2003 at 08:41:54AM -0800
> Hello all,
> 
> I've got a strange problem with my 760MPX system dual proc system. If I 
> try to use vesafb to setup the video on boot, the system will boot fine, 
> but will be unable to display anything on the console. The system 
> appears to be largely unaffacted by any underlying problem, as it is 
> stable after boot and seems to run fine. In looking through logs 
> afterward, I find these suspect messages:
> 
> mtrr: your CPUs had inconsistent fixed MTRR settings
> vesafb: abort, cannot ioremap video memory 0x8000000 @ 0xe8000000
> 
> I've tried using the rivafb frame buffer, which also does not work. From 
> what I could see in scanning the archives, this appears to possibly be a 
> BIOS issue, however, I'm game to throw nearly anything at it to try and 
> resolve it. Hardware is as follows:
> 
> Chaintech 7KDD 760MPX chipset motherboard
> 2 x AMD 2400MP
> 1 GB Ram
> Nvidia GeForce 4600
> 
I had a similar problem with 1 Gb Ram, and received this answer on the
linux-kernel mailinglist:

======================================================
To: thunder7@xs4all.nl
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.5.64: ioremap_nocache() failes with 1 gigabyte memory, works with 512 Mb?
From: Roland Dreier <roland@topspin.com>
Date: 14 Mar 2003 00:15:26 -0800

    thunder7> Now I added some information to the printk, and I now
    thunder7> know:

    thunder7> fb: Can't remap 3Dfx Voodoo5 register area. (start d0000000 length 8000000)

Length 0x8000000 means the driver is trying to ioremap a 128MB.

    thunder7> If I boot my kernel with 'mem=512M' I can use the
    thunder7> framebuffer just fine (well, it doesn't work and writes
    thunder7> funky patters to the screen, but at least
    thunder7> ioremap_nocache() works fine).

    thunder7> What is the reason ioremap_nocache() fails? Is this
    thunder7> something that can be prevented? I am not entirely clear
    thunder7> on what is happening anyway (real memory, virtual
    thunder7> memory, nocache-memory, io-memory - a little bit above
    thunder7> my head :-) ).

ioremap_nocache() uses "vmalloc space".  The kernel has some address
space it uses for kernel virtual memory mappings -- that is, for
mapping vmalloc()'ed memory and ioremap()'ed memory.

On i386, the kernel uses whatever part of the top 1 GB of address space
is not used for directly mapped RAM (aka lowmem).  (There are a few
other things that take some address space but that is approximately
true).

This means with "mem=512M", you will probably have about 500M of
vmalloc space, which is more than enough to ioremap the framebuffer.

With the full 1 GB of memory, you might think that there would be no
vmalloc space available at all.  However, <asm/page.h> defines a
constant VMALLOC_RESERVE (which by default is 128 MB), and the kernel
makes sure that there is at least this much vmalloc space available.
However, by the time you load the module, at least some of this space
has been consumed, so the ioremap fails.  (If nothing else uses
vmalloc space, just loading a module will call vmalloc() to get space
for the module to be loaded into!)

One not very good way for you to proceed would be to change the
definition of VMALLOC_RESERVE from (128 << 20) to something like (256
<< 20), which should leave the driver room to ioremap the framebuffer.
This is a little ugly.  However, I don't see why a framebuffer driver
would need to ioremap _all_ of a video card's memory -- so a better
solution would be to fix the driver to only ioremap what it needs to.

Best,
  Roland
======================================================

To see if this is it, booting with mem=512M would be a good test.

Kind regards,
Jurriaan
-- 
War does not determine who is right -- only who is left.
	Bertrand Russell
Debian (Unstable) GNU/Linux 2.5.65-mm3 4276 bogomips load av: 0.90 0.80 0.61

Re: vesafb problem

[Walt H]

Jurriaan wrote:

> 
> I had a similar problem with 1 Gb Ram, and received this answer on the
> linux-kernel mailinglist:
> 
> ======================================================
> To: thunder7@xs4all.nl
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: 2.5.64: ioremap_nocache() failes with 1 gigabyte memory, works with 512 Mb?
> From: Roland Dreier <roland@topspin.com>
> Date: 14 Mar 2003 00:15:26 -0800
> 
>     thunder7> Now I added some information to the printk, and I now
>     thunder7> know:
> 
>     thunder7> fb: Can't remap 3Dfx Voodoo5 register area. (start d0000000 length 8000000)
> 
> Length 0x8000000 means the driver is trying to ioremap a 128MB.
> 
>     thunder7> If I boot my kernel with 'mem=512M' I can use the
>     thunder7> framebuffer just fine (well, it doesn't work and writes
>     thunder7> funky patters to the screen, but at least
>     thunder7> ioremap_nocache() works fine).
> 
>     thunder7> What is the reason ioremap_nocache() fails? Is this
>     thunder7> something that can be prevented? I am not entirely clear
>     thunder7> on what is happening anyway (real memory, virtual
>     thunder7> memory, nocache-memory, io-memory - a little bit above
>     thunder7> my head :-) ).
> 
> ioremap_nocache() uses "vmalloc space".  The kernel has some address
> space it uses for kernel virtual memory mappings -- that is, for
> mapping vmalloc()'ed memory and ioremap()'ed memory.
> 
> On i386, the kernel uses whatever part of the top 1 GB of address space
> is not used for directly mapped RAM (aka lowmem).  (There are a few
> other things that take some address space but that is approximately
> true).
> 
> This means with "mem=512M", you will probably have about 500M of
> vmalloc space, which is more than enough to ioremap the framebuffer.
> 
> With the full 1 GB of memory, you might think that there would be no
> vmalloc space available at all.  However, <asm/page.h> defines a
> constant VMALLOC_RESERVE (which by default is 128 MB), and the kernel
> makes sure that there is at least this much vmalloc space available.
> However, by the time you load the module, at least some of this space
> has been consumed, so the ioremap fails.  (If nothing else uses
> vmalloc space, just loading a module will call vmalloc() to get space
> for the module to be loaded into!)
> 
> One not very good way for you to proceed would be to change the
> definition of VMALLOC_RESERVE from (128 << 20) to something like (256
> << 20), which should leave the driver room to ioremap the framebuffer.
> This is a little ugly.  However, I don't see why a framebuffer driver
> would need to ioremap _all_ of a video card's memory -- so a better
> solution would be to fix the driver to only ioremap what it needs to.
> 
> Best,
>   Roland
> ======================================================
> 
> To see if this is it, booting with mem=512M would be a good test.
> 
> Kind regards,
> Jurriaan

Thanks for the reply. That is indeed what is doing it. When I added 
mem=512M, I had two smiling penguins on boot :)  My vid card does have 
128MB Ram, but I also tend to agree that I'm not sure that the 
framebuffer needs to remap *all* of its memory. But, for now, I think 
I'll add the hack (256 << 20) to make it work. Any ideas if this might 
have unforseen bad effects? Might it screw up highmem I/O? Thanks again,

-Walt

Re: vesafb problem

[Bongani Hlope]

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

On Thu, 27 Mar 2003 11:34:25 -0800
Walt H <waltabbyh@comcast.net> wrote:

> Jurriaan wrote:
> 
> > 
> > I had a similar problem with 1 Gb Ram, and received this answer on the
> > linux-kernel mailinglist:

<sip>

> >     thunder7> framebuffer just fine (well, it doesn't work and writes
> >     thunder7> funky patters to the screen, but at least
> >     thunder7> ioremap_nocache() works fine).
> > 
> >     thunder7> What is the reason ioremap_nocache() fails? Is this
> >     thunder7> something that can be prevented? I am not entirely clear
> >     thunder7> on what is happening anyway (real memory, virtual
> >     thunder7> memory, nocache-memory, io-memory - a little bit above

<snip>

> > This means with "mem=512M", you will probably have about 500M of
> > vmalloc space, which is more than enough to ioremap the framebuffer.
> > 

<snip>

> > To see if this is it, booting with mem=512M would be a good test.
> > 
> > Kind regards,
> > Jurriaan
> 
> Thanks for the reply. That is indeed what is doing it. When I added 
> mem=512M, I had two smiling penguins on boot :)  My vid card does have 
> 128MB Ram, but I also tend to agree that I'm not sure that the 
> framebuffer needs to remap *all* of its memory. But, for now, I think 
> I'll add the hack (256 << 20) to make it work. Any ideas if this might 
> have unforseen bad effects? Might it screw up highmem I/O? Thanks again,
> 
> -Walt


Strange I'm having the same problem, but I only have 256MB of memory and my GeForce 2 only has 32MB. This is what's on my messages file:


vesafb: framebuffer at 0xe0000000, mapped to 0xd0807000, size 32768k
vesafb: mode is 800x600x16, linelength=1600, pages=3
vesafb: protected mode interface info at c000:c060
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
Looking for splash picture.... found (800x600, 13683 bytes).
Console: switching to colour frame buffer device 82x30
fb0: VESA VGA frame buffer device


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: vesafb problem

[Walt H]

> One not very good way for you to proceed would be to change the
> definition of VMALLOC_RESERVE from (128 << 20) to something like (256
> << 20), which should leave the driver room to ioremap the framebuffer.
> This is a little ugly.  However, I don't see why a framebuffer driver
> would need to ioremap _all_ of a video card's memory -- so a better
> solution would be to fix the driver to only ioremap what it needs to.
> 
> Best,
>   Roland
> ======================================================
> 
> To see if this is it, booting with mem=512M would be a good test.
> 
> Kind regards,
> Jurriaan

Well, I've answered my own question regarding highmem. Reserving 256MB 
ram causes high-mem mapped IO to fail. I can have penguins, but no 
filesystems or no penguins and a useable system. I'm guessing that I 
could probably turn off HIGHMEM and HIGHMEM-IO and might be able to get 
penguins back, but at the cost of reduced system performance. I'm not a 
kernel hacker, but I might just see how bad I can break vesafb to remap 
only the necessary memory for the requested video mode. Perhaps that 
would fix the whole thing?

-Walt

Re: vesafb problem

[Walt H]

Bongani Hlope wrote:

> Strange I'm having the same problem, but I only have 256MB of memory and my GeForce 2 only has 32MB. This is what's on my messages file:
> 
> 
> vesafb: framebuffer at 0xe0000000, mapped to 0xd0807000, size 32768k
> vesafb: mode is 800x600x16, linelength=1600, pages=3
> vesafb: protected mode interface info at c000:c060
> vesafb: scrolling: redraw
> vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
> Looking for splash picture.... found (800x600, 13683 bytes).
> Console: switching to colour frame buffer device 82x30
> fb0: VESA VGA frame buffer device
> 

Hmmm. That's a different problem than I'm experiencing. Your system 
appears to be correctly remapping the framebuffer and switching to it. 
You don't get a graphical boot? Seems as if you should from the log 
snippet you posted.

-Walt

Re: vesafb problem

[Walt H]

Walt H wrote:

> Well, I've answered my own question regarding highmem. Reserving 256MB 
> ram causes high-mem mapped IO to fail. I can have penguins, but no 
> filesystems or no penguins and a useable system. I'm guessing that I 
> could probably turn off HIGHMEM and HIGHMEM-IO and might be able to get 
> penguins back, but at the cost of reduced system performance. I'm not a 
> kernel hacker, but I might just see how bad I can break vesafb to remap 
> only the necessary memory for the requested video mode. Perhaps that 
> would fix the whole thing?
> 
> -Walt
> 

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 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;


-Walt

Re: vesafb problem

[Bongani Hlope]

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

On Thu, 27 Mar 2003 14:30:21 -0800
Walt H <waltabbyh@comcast.net> wrote:

> Bongani Hlope wrote:
> 
> > Strange I'm having the same problem, but I only have 256MB of memory and my GeForce 2 only has 32MB. This is what's on my messages file:
> > 
> > 
> > vesafb: framebuffer at 0xe0000000, mapped to 0xd0807000, size 32768k
> > vesafb: mode is 800x600x16, linelength=1600, pages=3
> > vesafb: protected mode interface info at c000:c060
> > vesafb: scrolling: redraw
> > vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
> > Looking for splash picture.... found (800x600, 13683 bytes).
> > Console: switching to colour frame buffer device 82x30
> > fb0: VESA VGA frame buffer device
> > 
> 
> Hmmm. That's a different problem than I'm experiencing. Your system 
> appears to be correctly remapping the framebuffer and switching to it. 
> You don't get a graphical boot? Seems as if you should from the log 
> snippet you posted.


It is just black until X starts up, and if I try to switch to a virtual 
terminal I get a corrupt screen

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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