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.
i'm all for removing tng, personally. reassigning to kernel team
Wouldn't just removing the 'vram' option work for you? Vesafb-tng, just like normal vesafb, limits the framebuffer size to 16MB by default.
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...
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.
Cheers, works for me. Thanks for confirming the color depth and resolution as I was not too sure on this.
