Bug 65340 – vesafb-tng breaks with 1GB memory AND grub.conf (vram:128)

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Can 2004-09-25 11:55:22 UTC]

Hi there, it seems related to #19061, which was apparently on 2.4.

After installing 1GB RAM, load of vesafb-tng fails with:
vesafb: abort, cannot ioremap video memory 0x8000000 @ 0xe0000000

Grub: video=vesafb:mtrr,vram:128
board: nvidia GeFX5500 generic 128MB

There is a relevant link to this:
http://www.ussg.iu.edu/hypermail/linux/kernel/0303.3/1161.html

The link thread suggests 2 solutions:
(1) asm/page.h: change #define __VMALLOC_RESERVE	(128 << 20)
TO: #define __VMALLOC_RESERVE	(256 << 20) . This works!

(2)video/vesafb.c, change: video_size = screen_info.lfb_size * 65536; 
TO:  video_size = screen_info.lfb_width * screen_info.lfb_height * video_bpp . Did not test this (see 1236.html) - This is mentioned in #19061 and #29082. Anyhow, the 2.6.x code is slightly different and it appears to already have been implemented

(3): reduce vram to < 128. e,g. vram=32 or so. This works too without doing (1). So probably the easiest solution.

So I guess it is resolved for me. BUT a mention of this in the vesafb docs would probably be helpful, as it is a bit of a shot in the dark.

Reproducible: Always
Steps to Reproduce:
1.1GB RAM
2.vram=128 in grub.conf
3.

Actual Results:  
vesafb-tng failt to load: 
vesafb: abort, cannot ioremap video memory 0x8000000 @ 0xe0000000 

Expected Results:  
bootsplash of consoles, silent.

[Comment 1 Travis Tilley (RETIRED) 2004-09-25 12:23:16 UTC]

i'm all for removing tng, personally. reassigning to kernel team

[Comment 2 Michal Januszewski (RETIRED) 2004-09-25 16:00:12 UTC]

Wouldn't just removing the 'vram' option work for you? Vesafb-tng, just like normal vesafb, limits the framebuffer size to 16MB by default.

[Comment 3 Can 2004-09-26 06:48:24 UTC]

Yes, that works. The vram option works fine upto 64MB and breaks at 128MB (with 1GB RAM - 2.6.8-r3). Probably as installed memory increases, the nvram option will take less and less as the VMALLOC_RESERVE gets used up for mapping tasks? Assuming a linear relationship, 128:512, 64:1024, 32:2048, 16:4something; so 16 for vram appears safe for RAM upto 4GB. Is 16MB sufficient to cover truecolor (24-bit) at 1280x1024/Does the number of consoles matter? Is there a case for upping the VMALLOC, I wonder...

[Comment 4 Michal Januszewski (RETIRED) 2004-10-03 08:47:28 UTC]

16 MB is more than enough to handle 1600x1400 with 32-bit color depth (1600x1400x4 bytes = 8 MB) and the number of consoles doesn't matter here. I don't see too much reasons to mess with the vmalloc :) Using a large amount of VRAM for the framebuffer is usually a bad idea, because you won't gain anything from it, and you will loose a large chunk of the available address space.

I will add a note about the problem to the docs shortly. I'm closing this bug as fixed.

[Comment 5 Can 2004-10-03 12:59:12 UTC]

Cheers, works for me. Thanks for confirming the color depth and resolution as I was not too sure on this.