[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-users] BAR 0: cirrusfb load errors prevent hvm domu from getting resolutions above 800x600



Flavio is having a problem getting a functional cirrus emulation (stdvga=0) in 
his opensuse 11.4 hvm domu. He has two kernels installed on the virtual disk - 
suse's 2.6.37, and a hand compiled 3.1, with all the xen frontends builtin. 
Both kernels have the same problem with the cirrusfb driver.

Here are the relevant messages from the 2.6.37 kernel:

[    0.201973] pci 0000:00:02.0: [1013:00b8] type 0 class 0x000300
[    0.202546] pci 0000:00:02.0: reg 10: [mem 0xf0000000-0xf1ffffff pref]
[    0.203075] pci 0000:00:02.0: reg 14: [mem 0xf3000000-0xf3000fff]
[...]
[    0.453890] vgaarb: device added: 
PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[    0.453894] vgaarb: loaded
[...]
[    0.492167] pci 0000:00:02.0: Boot video device
[...]
[    0.667812] vesafb: framebuffer at 0xf0000000, mapped to 
0xffffc90000580000, using 1875k, total 4096k
[    0.667815] vesafb: mode is 800x600x16, linelength=1600, pages=3
[    0.667817] vesafb: scrolling: redraw
[    0.667820] vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
[    0.668044] bootsplash 3.1.6-2004/03/31: looking for picture...
[    0.668047] bootsplash: silentjpeg size 124451 bytes
[    0.674284] bootsplash: ...found (800x600, 62872 bytes, v3).
[    0.688156] Console: switching to colour frame buffer device 96x33
[    0.701329] fb0: VESA VGA frame buffer device
[...]
[   32.626308] cirrusfb 0000:00:02.0: BAR 0: can't reserve [mem 
0xf0000000-0xf1ffffff pref]
[   32.626312] cirrusfb 0000:00:02.0: cannot reserve region 0xf0000000, abort
[   32.626324] cirrusfb: probe of 0000:00:02.0 failed with error -16

So cirrusfb is trying to reserve memory the pci device already has, and 
controlled by the builtin vesa kernel driver. I would think vesa should hand 
off the device to cirrusfb? Here's what happens on my bare metal opensuse 11.4 
machine, with a radeon card:

<7>[    0.131665] pci 0000:01:00.0: [1002:5960] type 0 class 0x000300
<7>[    0.131682] pci 0000:01:00.0: reg 10: [mem 0xf0000000-0xf7ffffff pref]
<7>[    0.131691] pci 0000:01:00.0: reg 14: [io  0xec00-0xecff]
<7>[    0.131700] pci 0000:01:00.0: reg 18: [mem 0xff8f0000-0xff8fffff]
<7>[    0.131726] pci 0000:01:00.0: reg 30: [mem 0x80000000-0x8001ffff pref]
<7>[    0.131747] pci 0000:01:00.0: supports D1 D2
[...]
<6>[    0.162384] vgaarb: device added: 
PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
<6>[    0.162396] vgaarb: loaded
[...]
<6>[    0.222150] pci 0000:01:00.0: no compatible bridge window for [mem 
0x80000000-0x8001ffff pref]
<6>[    0.222224] pci 0000:01:00.0: BAR 6: assigned [mem 0xff800000-0xff81ffff 
pref]
[...]
<7>[    0.225419] pci 0000:01:00.0: Boot video device
[...]
<4>[    0.629101] vesafb: cannot reserve video memory at 0xf0000000
<6>[    0.630029] vesafb: framebuffer at 0xf0000000, mapped to 0xf8080000, 
using 5120k, total 262144k
<6>[    0.630038] vesafb: mode is 1280x1024x16, linelength=2560, pages=101
<6>[    0.630043] vesafb: protected mode interface info at c000:56f7
<6>[    0.630049] vesafb: pmi: set display start = c00c578b, set palette = 
c00c57d7
<6>[    0.630054] vesafb: pmi: ports = e010 e016 e054 e038 e03c e05c e000 e004 
e0b0 e0b2 e0b4 
<6>[    0.630069] vesafb: scrolling: redraw
<6>[    0.630075] vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
[...]
<6>[    0.814211] fb0: VESA VGA frame buffer device
[...]
<6>[  259.930780] [drm] radeon defaulting to kernel modesetting.
<6>[  259.952873] [drm] radeon kernel modesetting enabled.
<7>[  259.974306] checking generic (f0000000 10000000) vs hw (f0000000 
8000000)
<3>[  259.974310] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - 
removing generic driver

In other words, the kernel causes vesafb to relinquish control to radeon, 
which is not happening in Flavio's cirrusfb case.

I've already had him try stdvga=1, videoram=8 & 16 & 32. lspci -vvv tells us 
the Region 0 memory size for the video device keeps increasing for 8 & 16, but 
stays at 16M for videoram=32, so stdvga=1 does not help him. It also says 
there is no kernel module - in other words, the builtin vesa driver is still 
in charge.

So, does anybody know how to correct BAR errors for an emulated device? It's 
not like I can put it in a different virtual pci slot.

Thanx.

His 2.6.37 dmesg: http://pastebin.com/vNpumSik
His 3.1.0  dmesg: http://pastebin.com/ikKPe6n3

His hvm config:

kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory = 1024

shadow_memory = 8
name = "opensuse-11.4"
vif = [ 'type=ioemu, mac=00:16:3e:00:00:21, bridge=xenbr0' ]
acpi = 1
apic = 1
disk = [ 'file:/mnt/xen/vmstore/opensuse-11.4/opensuse-11.4.img,hda,w' ]

boot="dc"
sdl=0
vnc=1
vncconsole=1
vncpasswd=''
vnclisten="192.168.1.100"
stdvga=0
videoram=16
keymap="it"

serial='pty'
usbdevice='tablet'


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.