Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 19061

Summary: vesafb broken with large memory
Product: Gentoo Linux Reporter: Christopher Rude <crude>
Component: [OLD] Core systemAssignee: x86-kernel (DEPRECATED) <x86-kernel>
Status: RESOLVED FIXED    
Severity: normal CC: gurligebis, r.a.mercer
Priority: High    
Version: unspecified   
Hardware: x86   
OS: Linux   
URL: http://lkml.org/archive/2003/3/27/119/index.html
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: Patch that shold work on 2.4 series kernel
Should correct issue with developmental sources
updated 2.4 patch
this patches the patch ;)

Description Christopher Rude 2003-04-09 19:24:28 UTC
~~~~~~~System~~~~~~~
Motherboard:  Tyan S2462
Processor:    2 x AMD Athlon MP 1900+
Memory:       1GB Registerd DDR
Video Card:   VisionTek GeForce 4 Ti 4600
Kernel(s):    2.4.20-gentoo-r2; 2.4.20-gaming-r1; 2.5.67; 2.5.67-mm1 (previous
kernels also assumed to be affected)

When I upgraded my computer from 512 MB to 1024 MB my vesa framebuffer faild to
load, leaving me with a blank screen from which I could blindly log in and start X. 

I tested the memory for 48 hrs w/ memtest86 before even booting into gentoo w/o
errors, I original suspected it because it was new.

this is what demesg had to say on the subject
<snip>
vesafb: abort, cannot ioremap video memory 0x8000000 @ 0xf0000000
</snip>

I tested the system w the foloeing memory configs: 
2X512 + 2x256 = 1536 MB
1X512 + 3x256 = 1280 MB
2x512 + 1x256 = 1280 MB
2x512 + 0x256 = 1024 MB
1x512 + 2x256 = 1024 MB
0x512 + 4x256 = 1024 MB
1x512 + 1x256 =  768 MB No Problem
0x512 + 3x256 =  768 MB No Problem 
1x512 + 0x256 =  512 MB No Problem
0x512 + 2x256 =  512 MB No Problem
0x512 + 1x256 =  256 MB No Problem

Video Cards:
Gforce 4 ti 4600 w/128MB DDR
Gforce 4 ti 4200 w/128MB DDR
Gforce 2 GTS w/32MB DDR No Problem
Radeon 7500 w/64MB DDR No Problem

This is Some Documentation I found
http://www.nvnews.net/vbulletin/showthread.php?s=&postid=100543#post100543
http://lkml.org/archive/2003/3/27/119/index.html
http://forums.gentoo.org/viewtopic.php?p=274717#274717

To Resolve the problem w/ 2.4.20
Change /usr/src/{2.4.20 Kernel}/drivers/video/vesafb.c
From:
<snip>
video_size = screen_info.lfb_size * 65536;
</snip>
To:
<snip>
video_size = screen_info.lfb_width * screen_info.lfb_height * video_bpp;
</snip>
 
To Resolve w/ 2.5.67
Change /usr/src/{2.5 Kernel}/drivers/video/vesafb.c
From:
<snip>
vesafb_fix.smem_len = screen_info.lfb_size * 65536;
</snip>
To:
<snip>
vesafb_fix.smem_len = screen_info.lfb_width * screen_info.lfb_height *
vesafb_defined.bits_per_pixel;
</snip>

I have tested on gentoo-2.4.20-r2, gaming-2.4.20-r1, 2.5.67, 2.5.67-mm1

I hope that this is of some use.

Thank You
Chris ;~>

Reproducible: Always
Steps to Reproduce:
1.install < 1024 MB Ram on a gforce 4 ti w/ 128MB ram computer
2.using kernel command line: root=/dev/hda3 vga=794 video=vesa:1280x1024@70
3.Boot

Actual Results:  
System boots w/ blank screen... working system (will load X) just no framebuffer
console

Expected Results:  
Happy penguins looking back at me, and working computer
Comment 1 Christopher Rude 2003-04-16 20:03:21 UTC
Created attachment 10768 [details, diff]
Patch that shold work on 2.4 series kernel

bump ;~>....

I have been rather busy, but this is the patch for 2.4 kernel, it needs testing
tho

Thanks

Chris
Comment 2 Christopher Rude 2003-04-16 20:05:37 UTC
Created attachment 10769 [details, diff]
Should correct issue with developmental sources

This patch I have tested on !!MY!! system, and have aplied it to vanilla and mm
series

 once again thanks
Comment 3 Bjarke Istrup Pedersen (RETIRED) gentoo-dev 2003-04-23 19:42:04 UTC
Thank you, this solved my problems with my framebuffers :)
Please somebody make sure this patch gets submitted to the people at www.kernel.org .
Comment 4 Adam Mercer 2003-04-30 17:23:44 UTC
I submitted the patch to the kernel mailing list and got the following response from Alan Cox

Date: 30 Apr 2003 12:26:43 +0100
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Adam Mercer <r.a.mercer@blueyonder.co.uk>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Marcelo Tosatti <marcelo@conectiva.com.br>
Subject: Re: [PATCH 2.4.21-rc1] vesafb with large memory

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
Comment 5 Christopher Rude 2003-05-01 04:10:29 UTC
My question is then..... is there a more appropriate way to correct this problem ;)
seems to me that if the way it is done is correct, in short time we are going to see many more people running into the problem (memory is cheap, and graphics cards improve pushing up the base line), and it will need to be "fixed" in order to not push (read scare)people away from our wonderfull os... 

I guess what I am trying to say is how do we fix it (and get it accepted in to the kernel :) so that people with configurations like mine and others (systems that should be able to do framebuffer) don't have to do something that is not correct (even though it may be "safe")

Thanks....

btw if my tone was off, I am sorry no sleep and long work days does that to me now and again, and thanks for taking the time to post to lkml (and reporting back ;)
Comment 6 Jarkko Haapalainen 2003-05-05 06:06:07 UTC
I'm using pfeifer-sources and this patch is working here too.

Comment 7 Adam Mercer 2003-05-05 15:23:58 UTC
I've just checked the changelog for 2.4.21-rc1-ac4 and Alans applied the patch I sent - so hopefully it should find its way to Marcelo before 2.4.21
Comment 8 Jay Pfeifer (RETIRED) gentoo-dev 2003-05-05 23:34:08 UTC
i've got that patch here as well one from mandrake & a combo of the 2, i am going at least 
add the fix that computes the mode size. 
 
look for it in pfeifer-sources-2.4.20_pre11 
 
Thanks, 
 
Jay 
Comment 9 Christopher Rude 2003-05-06 05:38:54 UTC
Thank You...  
nuff said ;~> 
Comment 10 Adam Mercer 2003-05-08 17:22:39 UTC
Created attachment 11697 [details, diff]
updated 2.4 patch
Comment 11 Adam Mercer 2003-05-08 17:23:15 UTC
the patch has been applied to Marcelo's BitKeeper tree, but I've received the following in an email from Geert Uytterhoeven


    video_size must be in bytes, hence it must be

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

which makes sense, find attached a new patch (against 2.4.21-rc1, but it cleanly applies to 2.4.20)

Cheers

Adam
Comment 12 Jay Pfeifer (RETIRED) gentoo-dev 2003-05-08 17:29:54 UTC
i already divided it by 8 as we are calculating bytes. the patch was already in 
pfeifer-sources-2.4.20_pre11 *and* pre11 has now become 
gentoo-sources-2.4.20-r4 - the tarball has been uploaded and it should be 
mirroring now. 
 
Get it while it's hot. 
 
Have a good one, 
 
Jay 
Comment 13 Christopher Rude 2003-05-09 01:50:31 UTC
Thanks..... me thinks I will give my brand spanking new watercooled rig a compile job ;~> 
Comment 14 FL 2003-06-07 04:25:30 UTC
In course of this patch, the SuSE bootsplash patch won't run anymore in silent mode because it generates not enough "size" to run in that mode:

vesafb: framebuffer at 0xd0000000, mapped to 0xd0800000, size 1536k
vesafb: mode is 1024x768x16, linelength=2048, pages=0
vesafb: protected mode interface info at c000:0eb9
vesafb: pmi: set display start = c00c0ef2, set palette = c00c0f68
vesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf
3d0 3d1 3d2 3d3 3d4 3d5 3da
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
Looking for splash picture.... silenjpeg size 21768 bytes, does not fit into
framebuffer.
found (1024x768, 20089 bytes, v3).

with the old option:

vesafb: framebuffer at 0xd0000000, mapped to 0xd0800000, size 65526k
vesafb: mode is 1024x768x16, linelength=2048, pages=0
vesafb: protected mode interface info at c000:0eb9
vesafb: pmi: set display start = c00c0ef2, set palette = c00c0f68
vesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf
3d0                                                                         
            
 3d1 3d2 3d3 3d4 3d5 3da 
vesafb: scrolling: ywrap using protected mode interface, yres_virtual=32763
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
Looking for splash picture.... silenjpeg size 21768 bytes, found (1024x768,
2008                                                                         
            
9 bytes, v3).
Got silent jpeg.
Got silent jpeg.
Console: switching to colour frame buffer device 122x40

this is an example from the wolk kernel version 4.2

the solution for this problem you can get here ( a diff which can be applied to the kernel (wolk)):

http://article.gmane.org/gmane.linux.wolk.devel/26

or maybe easyer:

video=vesa:vram:x


in course of many people experience this problem when they try to use bootsplash, this maybe has to be offered somewhere to the community. 
Comment 15 Christopher Rude 2003-06-11 03:33:20 UTC
Created attachment 13093 [details, diff]
this patches the patch ;)

This should take care of the problem. I have let a person on the forums test
it, results were good.

Apply this patch to the gentoo-sources-2.4.20-r5, and change:
Console drivers --> Frame-buffer support -->
<*> VESA VGA graphics console
(n) remap x times the graphics memory needed

n= intiger should be greater than 1

I hope this helps 

--adapted a patch from the wolk kernel
Comment 16 Christopher Rude 2003-06-11 03:50:47 UTC
I changed the status, as I am not sure if posting to it gets the info in the right place... 
 
Sory for my ignorance