Hi.
Actually, this is extracted from bug# 12712 at bugzilla.kernel.org.
drivers/video/vesafb.c
static int __init vesafb_probe(struct platform_device *dev)
if (!request_mem_region(vesafb_fix.smem_start, size_total, "vesafb")) {
printk(KERN_WARNING
"vesafb: cannot reserve video memory at 0x%lx\n",
vesafb_fix.smem_start);
/* We cannot make this fatal. Sometimes this comes from magic
spaces our resource handlers simply don't know about */
}
info = framebuffer_alloc(sizeof(u32) * 256, &dev->dev);
if (!info) {
release_mem_region(vesafb_fix.smem_start, size_total);
return -ENOMEM;
}
My first question is why we cannot make request_mem_region failure fatal?
(Most framebuffers does.)
If we can't make request_mem_region error fatal, then my second question is - is it correct to call release_mem_region in case of unsuccessful framebuffer_alloc? The problem here is that we can release_mem_region which wasn't allocated by vesafb request_mem_region call. IMHO at least there should be some flag (e.g., bool) proving that request_mem_region was successful and it's "safe" to call release_mem_region. Otherwise it's possible to release "non-vesafb" memory region.
This leads to things like this (2 framebuffers on a single video card):
[ 1.502011] nvidiafb: CRTC 0 is currently programmed for DFP [ 1.502022] nvidiafb: Using DFP on CRTC 0 [ 1.502031] nvidiafb: Panel size is 1280 x 800 [ 1.502040] nvidiafb: Panel is LVDS [ 1.505580] nvidiafb: MTRR set to ON [ 1.505599] fbcvt: 1280x800@60: CVT Name - 1.024MA-R [ 1.505856] fbcon: NV1d (fb0) is primary device [ 1.657379] nvidiafb: Flat panel dithering disabled [ 1.658735] Console: switching to colour frame buffer device 160x50 [ 1.659929] nvidiafb: PCI nVidia NV1d framebuffer (64MB @ 0xC0000000) [ 1.660099] vesafb: cannot reserve video memory at 0xc0000000 [ 1.660386] vesafb: framebuffer at 0xc0000000, mapped to 0xfd180000, using 6144k, total 131072k [ 1.660419] vesafb: mode is 1024x768x32, linelength=4096, pages=1 [ 1.660445] vesafb: protected mode interface info at c000:d5d0 [ 1.660471] vesafb: pmi: set display start = c00cd606, set palette = c00cd670 [ 1.660498] vesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da [ 1.660714] vesafb: scrolling: redraw [ 1.660734] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0 [ 1.660825] fb1: VESA VGA frame buffer device
Should I submit it as new bug at bugzilla.kernel.org?
Thanks.
Sergey.
Multiple modules, one must fail
Your output show nvidiafb and vesafb contending for the video card. This is common because udev and other module loaders load all modules that claim to support the pci id of the video card or other device, and one of them have to fail, often producing the error you see. On some hardware, with vesafb loaded already (because of parameter passed to kernel of vga=0x315, for example, which invokes vesafb), two or more additional fb modules may fail. Try passing vga=0 (or any text mode <= 6) and then vesafb will not load and nvidiafb should load alone without any error.
As for your question of should this be made fatal, absolutely not, because then you have to boot from a rescue cd to clean up udev rules and blacklist one potential device (or rebuild kernel without one of the modules at all) before you can ever boot again whenever multiple drivers are loaded for a single device. Udev does this all the time, loading two or more drivers for certain network cards, sound cards, etc., because the modules state that they think they can handle the device.