Re: [PATCH 2.4.21-rc1] vesafb with large memory

Re: [PATCH 2.4.21-rc1] vesafb with large memory

[O.Sezer]

So far, so good...

I can happily boot, halt, play some opengl games, perform my daily
routines, etc.  This should also be related to the bug recorded at
Mandrake-bugzilla: http://qa.mandrakesoft.com/show_bug.cgi?id=3198 .
I also reported this to kernel@mandrakesoft.com .

Regards;
Özkan Sezer


-------- Original Message --------
Subject: Re: [PATCH 2.4.21-rc1] vesafb with large memory
Date: Wed, 30 Apr 2003 21:58:42 +0300
From: O.Sezer <sezero@superonline.com>
To: linux-kernel@vger.kernel.org
CC: alan@lxorguk.ukuu.org.uk,  kernel@mandrakesoft.com

For the record:

This patch posted by Adam Mercer solved my previously reported
problem about the mmio clash of CDM680 and GeForce3-Ti200 / 128MB
(see thread: "IDE siimage Problem" at:
   http://marc.theaimsgroup.com/?l=linux-kernel&m=104773593910239&w=2
   disscussed offlist with Alan).
Very preliminary testing (no modules built, no initrd, only the
vmlinuz) did not show any mmio clash and boot was fine.
Dmesg and syslog files (gzipped) are attached. I may/will report
more results upon more testing if/when necessary.

Regards,
Özkan Sezer

Re: [PATCH 2.4.21-rc1] vesafb with large memory

[Thomas Backlund]

O.Sezer wrote:

> So far, so good...
> 
> I can happily boot, halt, play some opengl games, perform my daily
> routines, etc.  This should also be related to the bug recorded at
> Mandrake-bugzilla: http://qa.mandrakesoft.com/show_bug.cgi?id=3198 .
> I also reported this to kernel@mandrakesoft.com .
> 

No need ;-)....
We already have a (IMHO) better patch in current Cooker...
(and if you need it to install MDK 9.1, head over to www.iki.fi/tmb,
 grab the install disks, and follow the instructions...)

The problem with the patch you discussed, is that it allocates
framebuffer memory only according to the display mode...,
but there are programs that benefits from the "extra" memory...
this according to Antonino Daplas...
(AFAIK double/triple buffering is one thing...)

The patch that we have in current Cooker, allows the user to
request the size himself by a command line option...
and it does not change the setup/configuration for users that
does not suffer from this problem...


the patch works like this:

you request the framebuffer size with "video=vesa:vram:32"
where 32 is the requested size in MB... 
(you can choose the size yourself)
but a gemeric rule IMHO is to not go beyond the amount
of video memory you have... 

and when the system boots:

- if no vram option, boot as normal (like without the patch)
- if probed memory > requested, use requested
- if probed memory < requested, use probed (like without the patch)

As a test I used this "video=vesa:vram:32" on a card
with 64MB of ram, and on a card with only 4MB of ram
to se if I could mess it up, with the following results:

64MB card: allocated FB -> 32MB
(this is also confirmed on a 128MB card, by other Cooker users)
 4MB card: allocated FB ->  4MB 
(here the original probe worked, so we use it...)


So this way we wont break current systems, 
but have an option for those cards that has problem...
(seems to be AGP + >=128MB VideoRAM + >=1024MB system RAM only)

and finally... the patch itself:

----- cut -----
diff -Naru tmb7/Documentation/fb/vesafb.txt tmb9/Documentation/fb/vesafb.txt
--- tmb7/Documentation/fb/vesafb.txt    2000-07-28 22:50:51.000000000 +0300
+++ tmb9/Documentation/fb/vesafb.txt    2003-04-03 10:48:50.000000000 +0300
@@ -146,6 +146,10 @@

 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. (2.5.66 patch by Antonino Daplas backported
+       to 2.4 by tmb@iki.fi)
+

 Have fun!

diff -Naru tmb7/drivers/video/vesafb.c tmb9/drivers/video/vesafb.c
--- tmb7/drivers/video/vesafb.c 2002-11-29 01:53:15.000000000 +0200
+++ tmb9/drivers/video/vesafb.c 2003-04-03 10:46:52.000000000 +0300
@@ -94,6 +94,7 @@

 static int             inverse   = 0;
 static int             mtrr      = 0;
+static int      vram __initdata = 0; /* needed for vram boot option */
 static int             currcon   = 0;

 static int             pmi_setpal = 0; /* pmi for palette changes ??? */
@@ -479,6 +480,10 @@
                        pmi_setpal=1;
                else if (! strcmp(this_opt, "mtrr"))
                        mtrr=1;
+               /* checks for vram boot option */
+               else if (! strncmp(this_opt, "vram:", 5))
+                       vram = simple_strtoul(this_opt+5, NULL, 0);
+
                else if (!strncmp(this_opt, "font:", 5))
                        strcpy(fb_info.fontname, this_opt+5);
        }
@@ -521,6 +526,9 @@
        video_height        = screen_info.lfb_height;
        video_linelength    = screen_info.lfb_linelength;
        video_size          = screen_info.lfb_size * 65536;
+       /* sets video_size according to boot option */
+        if (vram && vram * 1024 * 1024 < video_size)
+                video_size = vram * 1024 * 1024;
        video_visual = (video_bpp == 8) ?
                FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR;
----- cut -----


Best Regards

Thomas Backlund

tmb@iki.fi
www.iki.fi/tmb

Re: [PATCH 2.4.21-rc1] vesafb with large memory

[Alan Cox]

On Iau, 2003-05-01 at 13:00, Thomas Backlund wrote:
> but there are programs that benefits from the "extra" memory...
> this according to Antonino Daplas...
> (AFAIK double/triple buffering is one thing...)

I've actually looke through the traces  for some situations
and the "how much memory" case is reporting banked RAM on some 
cards so you don't know that RAM exists.

The change proposed is definitely correct for the default. Whether
you want to support overriding it I don't know - I'm not worried
either way.

Re: [PATCH 2.4.21-rc1] vesafb with large memory

[Alan Cox]

On Iau, 2003-05-01 at 16:01, Thomas Backlund wrote:
> You mean the patch that only looks at videomode, dont you...

I do

> Well maybe it's best to use it as default, to avoid this bug 
> "out of the box"...
> 
> But I will remake a patch to ovverride it so that the users who 
> need/want the extra memory to be able to allocate it...
> since I like the idea of giving the user the choice...

Sounds right to me

Re: [PATCH 2.4.21-rc1] vesafb with large memory

[Thomas Backlund]

Viestissä Torstai 1. Toukokuuta 2003 15:07, Alan Cox kirjoitti:
> On Iau, 2003-05-01 at 13:00, Thomas Backlund wrote:
> > but there are programs that benefits from the "extra" memory...
> > this according to Antonino Daplas...
> > (AFAIK double/triple buffering is one thing...)
>
> I've actually looke through the traces  for some situations
> and the "how much memory" case is reporting banked RAM on some
> cards so you don't know that RAM exists.
>
> The change proposed is definitely correct for the default. Whether
> you want to support overriding it I don't know - I'm not worried
> either way.

You mean the patch that only looks at videomode, dont you...

Well maybe it's best to use it as default, to avoid this bug 
"out of the box"...

But I will remake a patch to ovverride it so that the users who 
need/want the extra memory to be able to allocate it...
since I like the idea of giving the user the choice...

The next thing that comes to mind is of course that
it need to be done so that you can't kill the system with the
vram setting... but that should not be to hard...

Thomas

-- 
Thomas Backlund

tmb@iki.fi
www.iki.fi/tmb

Re: [PATCH 2.4.21-rc1] vesafb with large memory

[Thomas Backlund]

Viestissä Torstai 1. Toukokuuta 2003 17:49, Alan Cox kirjoitti:
> On Iau, 2003-05-01 at 16:01, Thomas Backlund wrote:
> > You mean the patch that only looks at videomode, dont you...
>
> I do
>
> > Well maybe it's best to use it as default, to avoid this bug
> > "out of the box"...
> >
> > But I will remake a patch to ovverride it so that the users who
> > need/want the extra memory to be able to allocate it...
> > since I like the idea of giving the user the choice...
>
> Sounds right to me

Yeah, so merging the two patches ends up like this:
----- cut -----
--- tmb3/Documentation/fb/vesafb.txt	2003-05-01 19:53:26.000000000 +0300
+++ tmb3/Documentation/fb/vesafb.txt.vram	2003-05-01 20:11:08.000000000 
+0300
@@ -146,6 +146,11 @@

 mtrr	setup memory type range registers for the vesafb framebuffer.

+vram:n  remap 'n' MiB of video RAM. If 0 or not specified, remap memory
+        according to video mode. (2.5.66 patch/idea by Antonino Daplas
+	reversed to give override possibility (allocate more fb memory
+	than the kernel would) to 2.4 by tmb@iki.fi)
+  
 
 Have fun!
 
--- tmb3/drivers/video/vesafb.c	2003-05-01 19:49:34.000000000 +0300
+++ tmb3/drivers/video/vesafb.c.vram	2003-05-01 20:07:57.000000000 +0300
@@ -94,6 +94,7 @@

 static int             inverse   = 0;
 static int             mtrr      = 0;
+static int	 vram __initdata = 0;	/* needed for vram boot option */
 static int             currcon   = 0;

 static int             pmi_setpal = 0;	/* pmi for palette changes ??? */
@@ -479,6 +480,10 @@
 			pmi_setpal=1;
 		else if (! strcmp(this_opt, "mtrr"))
 			mtrr=1;
+		/* checks for vram boot option */
+		else if (! strncmp(this_opt, "vram:", 5))
+			vram = simple_strtoul(this_opt+5, NULL, 0);
+
 		else if (!strncmp(this_opt, "font:", 5))
 			strcpy(fb_info.fontname, this_opt+5);
 	}
@@ -520,7 +525,10 @@
 	video_width         = screen_info.lfb_width;
 	video_height        = screen_info.lfb_height;
 	video_linelength    = screen_info.lfb_linelength;
-	video_size          = screen_info.lfb_size * 65536;
+	video_size          = screen_info.lfb_size * screen_info.lfb_height * 
video_bpp;
+	/* sets video_size according to boot option */
+        if (vram && vram * 1024 * 1024 > video_size)
+                video_size = vram * 1024 * 1024;
 	video_visual = (video_bpp == 8) ?
 		FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR;
----- cut -----

And yes...
This is still without a "failsafe" since I don't have an upper limit,
but it occurred to me that maybe it isn't that easy after all...
 - I can't trust the videocard memory probe...,
 - to just calculate the video_size * 3 (for tripple buffering) is bad ;-)
 - videocards with everyhing between 256k and 256 MB of memory,
   makes choosing the limit somewhat impossible...
 - of course there is also endless range of installed system memory...

So, any thoughts...?
Or should one just leave it open due to:
" it's your system, feel free to break it..." ;-)

Oh well,
I'm building my testkernel now with the above patch, 
and will be testing different vram options to "kill" my system...

-- 
Thomas Backlund

tmb@iki.fi
www.iki.fi/tmb

Re: [PATCH 2.4.21-rc1] vesafb with large memory

[Thomas Backlund]

Thomas Backlund wrote:
>Viestissä Torstai 1. Toukokuuta 2003 17:49, Alan Cox kirjoitti:
>> On Iau, 2003-05-01 at 16:01, Thomas Backlund wrote:
>> > You mean the patch that only looks at videomode, dont you...
>>
>> I do
>>
>> > Well maybe it's best to use it as default, to avoid this bug
>> > "out of the box"...
>> >
>> > But I will remake a patch to ovverride it so that the users who
>> > need/want the extra memory to be able to allocate it...
>> > since I like the idea of giving the user the choice...
>>
>> Sounds right to me
>
>>Oh well,
>I'm building my testkernel now with the above patch, 
>and will be testing different vram options to "kill" my system...

And here are the results...

the testsystem: 
Amd XP 1800+
nForce2 m/b
256MB DDR RAM
Geforce4 Ti4200 64MB, videomode 1024x768x32
kernel-2.4.21-0.16mdk (i586 optimized)
kernel-2.4.21-0.16mdkent (i686 optimized + HIGHMEM)

without any vram option it allocated:
vesafb: framebuffer at 0xc0000000, mapped to 0xd0800000, size 24576k
as it should...

the standard kernel maxed out at about 755 MB
the enterprise kernel maxed out at about 720 MB

with the enterprise kernel I managed to get it to boot
with an allocation request for 1536MB, but the screen
blacked out at the berginning, even if the kernel seemed
to boot without errors....

booting with 800MB or 1024MB request resulted in an direct 
lockup with flashing keyboard leds....

so it seems to be the 1GB magical limit again...

So it seems useless to try and set an upper limit,
instead just leving it to the users choice to set whatever
he/she wants...


Now I have to get some sleep....

-- 
Thomas Backlund

tmb@iki.fi
www.iki.fi/tmb

Re: [PATCH 2.4.21-rc1] vesafb with large memory

[Willy Tarreau]

On Fri, May 02, 2003 at 03:14:01AM +0300, Thomas Backlund wrote:
> And here are the results...
[snip]

Hi Thomas,

With this patch, vesafb doesn't work anymore on my vaio notebook in 1400x1050
nor 1280x1024, because scree_info.lfb_size is reported to be 127, while it
should be 175 and 160 instead ! So I modified your patch a little bit to get it
right :

- video_size          = screen_info.lfb_size * screen_info.lfb_height * video_bpp;
+ video_size          = screen_info.lfb_width/8 * screen_info.lfb_height * video_bpp;

and it now works again.
Maybe I have a broken bios, but other people might have the problem too.

Cheers,
Willy

Re: [PATCH 2.4.21-rc1] vesafb with large memory

[Thomas Backlund]

Viestissä Perjantai 2. Toukokuuta 2003 16:03, Willy Tarreau kirjoitti:
> On Fri, May 02, 2003 at 03:14:01AM +0300, Thomas Backlund wrote:
> > And here are the results...
>
> [snip]
>
> Hi Thomas,
>
> With this patch, vesafb doesn't work anymore on my vaio notebook in
> 1400x1050 nor 1280x1024, because scree_info.lfb_size is reported to be
> 127, while it should be 175 and 160 instead ! So I modified your patch a
> little bit to get it right :
>
> - video_size          = screen_info.lfb_size * screen_info.lfb_height *
> video_bpp; + video_size          = screen_info.lfb_width/8 *
> screen_info.lfb_height * video_bpp;
>
> and it now works again.
> Maybe I have a broken bios, but other people might have the problem too.
>
> Cheers,
> Willy

Oh man...
I must have been sleeping when I posted that patch...

the correct line should AFAIK be:
video_size = screen_info.lfb_width * screen_info.lfb_height * video_bpp;

(AFAIK we are calculating bits here, not bytes so the '/8' you used is 
wrong... could you try without it, and let me know...)

or even shorter:

video_size = video_width * video_height * video_bpp;


I'll be rebuilding and retesting my system today or tommorrow,
but I wuold like to hear if it works for you...


-- 
Thomas Backlund

tmb@iki.fi
www.iki.fi/tmb

Re: [PATCH 2.4.21-rc1] vesafb with large memory

[Willy Tarreau]

On Sat, May 03, 2003 at 03:46:57PM +0300, Thomas Backlund wrote:
 
> Oh man...
> I must have been sleeping when I posted that patch...

no problem, we all need some sleep at least once a week ;-)

> the correct line should AFAIK be:
> video_size = screen_info.lfb_width * screen_info.lfb_height * video_bpp;
> 
> (AFAIK we are calculating bits here, not bytes so the '/8' you used is 
> wrong... could you try without it, and let me know...)

OK, I was assuming that video_size was in bytes. I will retry without the /8.

> I'll be rebuilding and retesting my system today or tommorrow,
> but I wuold like to hear if it works for you...

I just come back home this evening, so let's say you'll get a feedback tomorrow
morning.

Regards,
Willy

Re: [PATCH 2.4.21-rc1] vesafb with large memory

[Willy TARREAU]

Hi Thomas,

 
> the correct line should AFAIK be:
> video_size = screen_info.lfb_width * screen_info.lfb_height * video_bpp;
> 
> (AFAIK we are calculating bits here, not bytes so the '/8' you used is 
> wrong... could you try without it, and let me know...)

No, after verification, I insist, we're really calculating BYTES here. Please
take a look :

================== with lfb_width/8 :

wtap:~$ dmesg|grep vesafb
vesafb: framebuffer at 0xe9000000, mapped to 0xe0825000, size 1435k
vesafb: mode is 1400x1050x8, linelength=1400, pages=4
vesafb: protected mode interface info at c000:50ae
vesafb: scrolling: redraw

wtap:~$ grep vesafb /proc/iomem
    e9000000-e9166e2f : vesafb

wtap:~$ cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size= 512MB: write-back, count=1
reg01: base=0xe9000000 (3728MB), size=   1MB: write-combining, count=1

================== with lfb_width :

wtap:~$ dmesg|grep vesafb
vesafb: framebuffer at 0xe9000000, mapped to 0xe0825000, size 11484k
vesafb: mode is 1400x1050x8, linelength=1400, pages=4
vesafb: protected mode interface info at c000:50ae
vesafb: scrolling: redraw

wtap:~$ grep vesafb /proc/iomem
    e9000000-e9b3717f : vesafb

wtap:~$ cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size= 512MB: write-back, count=1
reg01: base=0xe9000000 (3728MB), size=   8MB: write-combining, count=1

============

So I think that the correct line really is :
  video_size = screen_info.lfb_width * screen_info.lfb_height * video_bpp / 8;

(Which also handles line widths which are not multiple of 8).

BTW, I wonder why we truncate the mtrr size to the highest lower power of 2.
Shouldn't we round it up to the next one ?

Personnally, I would find this change more logical. For instance, it returns
1 MB for video_size between 1MB and 2MB-1 inclusive.

Any comments ?

Willy

--- ./drivers/video/vesafb.c
+++ ./drivers/video/vesafb.c
@@ -647,4 +647,5 @@
-		int temp_size = video_size;
+		int temp_size = video_size - 1;
 		/* Find the largest power-of-two */
 		while (temp_size & (temp_size - 1))
 			temp_size &= (temp_size - 1);
+		temp_size <<= 1;

Re: [PATCH 2.4.21-rc1] vesafb with large memory

[Thomas Backlund]

Viestissä Sunnuntai 4. Toukokuuta 2003 12:49, Willy TARREAU kirjoitti:
> Hi Thomas,
>
> > the correct line should AFAIK be:
> > video_size = screen_info.lfb_width * screen_info.lfb_height *
> > video_bpp;
> >
> > (AFAIK we are calculating bits here, not bytes so the '/8' you used is
> > wrong... could you try without it, and let me know...)
>
> No, after verification, I insist, we're really calculating BYTES here.
> Please take a look :

Yes, 
you are right...

[...]
>
> So I think that the correct line really is :
>   video_size = screen_info.lfb_width * screen_info.lfb_height *
> video_bpp / 8;

There is a problem with this, ...
If we calculate the exact memory like this, there wont be any
memory remapped to do double/tripple buffering...
So the question is: shoud one take the formula and add ' * 2' to 
atleast get the double buffering supported...
(in the patch I made for mdk, I kept a modified override part so that
the user can change this, if he needs it....)

Alan,
any comments on this?

> (Which also handles line widths which are not multiple of 8).

Well actually, in that formula it does not matter where you put the '/8',
the result is always the same...

> BTW, I wonder why we truncate the mtrr size to the highest lower power
> of 2. Shouldn't we round it up to the next one ?
>

Isn't it a hardware requirement?
I think I read it in a nvidia document once... 
(of course they may be wrong...)

-- 
Thomas Backlund

tmb@iki.fi
www.iki.fi/tmb

Re: [PATCH 2.4.21-rc1] vesafb with large memory

[Walt H]

> There is a problem with this, ...
> If we calculate the exact memory like this, there wont be any
> memory remapped to do double/tripple buffering...
> So the question is: shoud one take the formula and add ' * 2' to
> atleast get the double buffering supported...
> (in the patch I made for mdk, I kept a modified override part so that
> the user can change this, if he needs it....)

Hello.  I realize that there won't be enough memory for double/triple
buffering using my patch. I even thought of doing the *2 thing, but
decided against it. The idea I had is that more and more video cards are
coming out with 128+ MB Ram, and that machines with >=1GB Ram are also
becoming common, especially for gamers etc...  Those users, I believe,
are less likely to use vesafb for anything other than graphics boot
splash and this just removes one little out-of-the-box problem many have
been having. I thought it to be a safer default than attempting to
ioremap the entire framebuffer. Just my thoughts,

-Walt Holman

Re: [PATCH 2.4.21-rc1] vesafb with large memory

[O.Sezer]

You cann see that in my logfiles (in the archived messages in MARC I
had referenced).

Regards;
Özkan Sezer



Thomas Backlund wrote:
> Viestissä Torstai 1. Toukokuuta 2003 17:20, O.Sezer kirjoitti:
> 
>>Thomas Backlund wrote:
>>
>>[SNIPPED]
>>
>> > So this way we wont break current systems,
>> > but have an option for those cards that has problem...
>> > (seems to be AGP + >=128MB VideoRAM + >=1024MB system RAM only)
>>
>>AGP			-> Yes
>>
>> >= 128MB RAM		-> Yes
>> >=1024MB system RAM	-> _ NO _.  Only 256MB
>>
> 
> Now thats new to me...
> all reports I've seen earlier has been with 1024MB or more...
> Oh well... every day you learn something new...
> 
> 
>>>(OK, I added another 128 today, so it's 384 now :))
>>
>>Regards;
>>Özkan Sezer
> 
> 

Re: [PATCH 2.4.21-rc1] vesafb with large memory

[Thomas Backlund]

Viestissä Torstai 1. Toukokuuta 2003 17:20, O.Sezer kirjoitti:
> Thomas Backlund wrote:
>
> [SNIPPED]
>
>  > So this way we wont break current systems,
>  > but have an option for those cards that has problem...
>  > (seems to be AGP + >=128MB VideoRAM + >=1024MB system RAM only)
>
> AGP			-> Yes
>
>  >= 128MB RAM		-> Yes
>  >=1024MB system RAM	-> _ NO _.  Only 256MB
>
Now thats new to me...
all reports I've seen earlier has been with 1024MB or more...
Oh well... every day you learn something new...

> > (OK, I added another 128 today, so it's 384 now :))
>
> Regards;
> Özkan Sezer

-- 
Thomas Backlund

tmb@iki.fi
www.iki.fi/tmb

Re: [PATCH 2.4.21-rc1] vesafb with large memory

[O.Sezer]

Thomas Backlund wrote:

[SNIPPED]
 >
 > So this way we wont break current systems,
 > but have an option for those cards that has problem...
 > (seems to be AGP + >=128MB VideoRAM + >=1024MB system RAM only)

AGP			-> Yes
 >= 128MB RAM		-> Yes
 >=1024MB system RAM	-> _ NO _.  Only 256MB
(OK, I added another 128 today, so it's 384 now :))

Regards;
Özkan Sezer

Re: [PATCH 2.4.21-rc1] vesafb with large memory

[O.Sezer]

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

For the record:

This patch posted by Adam Mercer solved my previously reported
problem about the mmio clash of CDM680 and GeForce3-Ti200 / 128MB
(see thread: "IDE siimage Problem" at:
  http://marc.theaimsgroup.com/?l=linux-kernel&m=104773593910239&w=2
  disscussed offlist with Alan).
Very preliminary testing (no modules built, no initrd, only the
vmlinuz) did not show any mmio clash and boot was fine.
Dmesg and syslog files (gzipped) are attached. I may/will report
more results upon more testing if/when necessary.

Regards,
Özkan Sezer

[-- Attachment #2: dmesg.out.gz --]
[-- Type: application/gzip, Size: 2786 bytes --]

[-- Attachment #3: syslog.out.gz --]
[-- Type: application/gzip, Size: 5202 bytes --]

Re: [PATCH 2.4.21-rc1] vesafb with large memory

[Alan Cox]

On Mer, 2003-04-30 at 09:09, Adam Mercer wrote:
> -	video_size          = screen_info.lfb_size * 65536;

The above is correct. It returns the size of the frame buffer

> +	video_size          = screen_info.lfb_width *	screen_info.lfb_height * video_bpp;
> 	video_visual = (video_bpp == 8) ?
> 		FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR;						#

The change computes the mode size. Thats probably safe for the ioremap
range

[PATCH 2.4.21-rc1] vesafb with large memory

[Adam Mercer]

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

Hi

I've recently been having a problem with the vesafb refusing to boot on
my system, after investigation the problem further I found that it had
been mentioned on the 27 March 2003, in this thread

http://marc.theaimsgroup.com/?l=linux-kernel&m=104878364823195&w=2

In the thread Walt H, waltabbyh <at> comcast <dot> net, provides a fix.
After just downloading 2.4.21-rc1 I noticed that this fix was not
present. So heres a patch against 2.4.21-rc1 to fix this probelm.

Please CC me with any responses as I'm not on the list.

Cheers

Adam

diff -urN linux-2.4.21-rc1-orig/drivers/video/vesafb.c linux-2.4.21-rc1/drivers/video/vesafb.c
--- linux-2.4.21-rc1-orig/drivers/video/vesafb.c  2002-11-28 23:53:15.000000000 +0000
+++ linux-2.4.21-rc1/drivers/video/vesafb.c 2003-04-30 08:32:02.000000000 +0100
@@ -520,7 +520,7 @@
	video_width         = screen_info.lfb_width;
	video_height        = screen_info.lfb_height;
	video_linelength    = screen_info.lfb_linelength;
-	video_size          = screen_info.lfb_size * 65536;
+	video_size          = screen_info.lfb_width *	screen_info.lfb_height * video_bpp;
	video_visual = (video_bpp == 8) ?
		FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR;						

[-- Attachment #2: 2.4.21-rc1-vesafb-highmem.patch --]
[-- Type: text/plain, Size: 651 bytes --]

diff -urN linux-2.4.21-rc1-orig/drivers/video/vesafb.c linux-2.4.21-rc1/drivers/video/vesafb.c
--- linux-2.4.21-rc1-orig/drivers/video/vesafb.c	2002-11-28 23:53:15.000000000 +0000
+++ linux-2.4.21-rc1/drivers/video/vesafb.c	2003-04-30 08:32:02.000000000 +0100
@@ -520,7 +520,7 @@
 	video_width         = screen_info.lfb_width;
 	video_height        = screen_info.lfb_height;
 	video_linelength    = screen_info.lfb_linelength;
-	video_size          = screen_info.lfb_size * 65536;
+	video_size          = screen_info.lfb_width * screen_info.lfb_height * video_bpp;
 	video_visual = (video_bpp == 8) ?
 		FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR;