Mailing List Archive: BAR 0: cirrusfb load errors prevent hvm domu from getting resolutions above 800x600

BAR 0: cirrusfb load errors prevent hvm domu from getting resolutions above 800x600

Nov 16, 2011, 3:28 PM

Post #1 of 7 (320 views)

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-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: BAR 0: cirrusfb load errors prevent hvm domu from getting resolutions above 800x600 [ In reply to ]

JBeulich at suse

Nov 17, 2011, 12:10 AM

Post #2 of 7 (311 views)

Permalink

>>> On 17.11.11 at 00:28, jim burns <jim_burn@bellsouth.net> wrote:

Sounds more like a kernel problem.

> <4>[ 0.629101] vesafb: cannot reserve video memory at 0xf0000000

This doesn't tell what component did the reservation before this point,
but that's what he/you will need to find out. And then compare with
the cirrusfb case.

One significant difference of course is the DRM base fb driver in the
radeon case - to compare apples with apples, DRM should really be
removed from the picture.

Jan

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

Re: UNS: Re: BAR 0: cirrusfb load errors prevent hvm domu from getting resolutions above 800x600 [ In reply to ]

jim_burn at bellsouth

Nov 17, 2011, 12:31 AM

Post #3 of 7 (309 views)

Permalink

On Thu November 17 2011, 8:10:08 AM, Jan Beulich wrote:
> >>> On 17.11.11 at 00:28, jim burns <jim_burn@bellsouth.net> wrote:
> Sounds more like a kernel problem.
>
> > <4>[ 0.629101] vesafb: cannot reserve video memory at 0xf0000000
>
> This doesn't tell what component did the reservation before this point,
> but that's what he/you will need to find out. And then compare with
> the cirrusfb case.

I thought that's what this meant:

[ 0.667812] vesafb: framebuffer at 0xf0000000, mapped to
0xffffc90000580000, using 1875k, total 4096k

Looks like vesafb reserved it.

> One significant difference of course is the DRM base fb driver in the
> radeon case - to compare apples with apples, DRM should really be
> removed from the picture.

True. I was just pointing out that there is a mechanism for vesafb handing off
control to another video driver:

<3>[ 259.974310] fb: conflicting fb hw usage radeondrmfb vs VESA VGA -
removing generic driver

Any ideas where to go from here? Thanx.

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

Re: UNS: Re: BAR 0: cirrusfb load errors prevent hvm domu from getting resolutions above 800x600 [ In reply to ]

JBeulich at suse

Nov 17, 2011, 1:38 AM

Post #4 of 7 (308 views)

Permalink

>>> On 17.11.11 at 09:31, jim burns <jim_burn@bellsouth.net> wrote:
> On Thu November 17 2011, 8:10:08 AM, Jan Beulich wrote:
>> >>> On 17.11.11 at 00:28, jim burns <jim_burn@bellsouth.net> wrote:
>> Sounds more like a kernel problem.
>>
>> > <4>[ 0.629101] vesafb: cannot reserve video memory at 0xf0000000
>>
>> This doesn't tell what component did the reservation before this point,
>> but that's what he/you will need to find out. And then compare with
>> the cirrusfb case.
>
> I thought that's what this meant:
>
> [ 0.667812] vesafb: framebuffer at 0xf0000000, mapped to
> 0xffffc90000580000, using 1875k, total 4096k
>
> Looks like vesafb reserved it.

No - the absence of the former message means it reserved it. But its
presence does not provide information on what, in that case, managed
to reserve it before. But that's what you want to hunt down.

>> One significant difference of course is the DRM base fb driver in the
>> radeon case - to compare apples with apples, DRM should really be
>> removed from the picture.
>
> True. I was just pointing out that there is a mechanism for vesafb handing
> off
> control to another video driver:
>
> <3>[ 259.974310] fb: conflicting fb hw usage radeondrmfb vs VESA VGA -
> removing generic driver
>
> Any ideas where to go from here? Thanx.

You could have looked at this easily yourself - cirrusfb_register() (which
is what calls register_framebuffer(), which is where above message
originates from) gets called from cirrusfb_pci_register() only *after*
that function tried to reserve its resources via pci_request_regions().
(This is in 3.2-rc2, so even the most current driver isn't capable of
doing this sort of handshake, and afaict that's no different on native,
so not a Xen issue at all.)

Btw., looking at the title again - I don't think you need cirrusfb to
get higher resolutions, at least not if you're talking about X (only if
you merely care about the text consoles this would be the case),
as long as a respective X driver is present.

Jan

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

Re: BAR 0: cirrusfb load errors prevent hvm domu from getting resolutions above 800x600 [ In reply to ]

jim_burn at bellsouth

Nov 20, 2011, 4:01 PM

Post #5 of 7 (306 views)

Permalink

On Thu November 17 2011, 9:38:56 AM, Jan Beulich wrote:
> >>> On 17.11.11 at 09:31, jim burns <jim_burn@bellsouth.net> wrote:
> > On Thu November 17 2011, 8:10:08 AM, Jan Beulich wrote:
> >> >>> On 17.11.11 at 00:28, jim burns <jim_burn@bellsouth.net> wrote:
> >> Sounds more like a kernel problem.
> >>
> >> > <4>[ 0.629101] vesafb: cannot reserve video memory at
> >> > 0xf0000000
> >>
> >> This doesn't tell what component did the reservation before this
> >> point,
> >> but that's what he/you will need to find out. And then compare with
> >> the cirrusfb case.
> >
> > I thought that's what this meant:
> >
> > [ 0.667812] vesafb: framebuffer at 0xf0000000, mapped to
> > 0xffffc90000580000, using 1875k, total 4096k
> >
> > Looks like vesafb reserved it.
>
> No - the absence of the former message means it reserved it. But its
> presence does not provide information on what, in that case, managed
> to reserve it before. But that's what you want to hunt down.

Oops - didn't catch this right away. The 'cannot reserve video memory' message
(and all messages in my post that have <num> in front) is actually from the
bare metal case that worked (with radeon). No such message occurs in the
cirrus case.

I generated the cirrus case extract by searching dmesg for anything about
'0000:00:02.0', 'cirrus', 'vga', or 'vesa'.

> >> One significant difference of course is the DRM base fb driver in the
> >> radeon case - to compare apples with apples, DRM should really be
> >> removed from the picture.
> >
> > True. I was just pointing out that there is a mechanism for vesafb
> > handing off
> > control to another video driver:
> >
> > <3>[ 259.974310] fb: conflicting fb hw usage radeondrmfb vs VESA VGA -
> > removing generic driver
> >
> > Any ideas where to go from here? Thanx.
>
> You could have looked at this easily yourself - cirrusfb_register() (which
> is what calls register_framebuffer(), which is where above message
> originates from) gets called from cirrusfb_pci_register() only *after*
> that function tried to reserve its resources via pci_request_regions().
> (This is in 3.2-rc2, so even the most current driver isn't capable of
> doing this sort of handshake, and afaict that's no different on native,
> so not a Xen issue at all.)

I meant is a BAR 0: error a commonly understood problem with common steps to
find and fix the *configuration* problem, not where can I tinker with kernel
code. I would think suse's 2.6.37.1-1.2-desktop kernel would work as is in an
hvm domain. Or should he be using a different suse kernel 'flavor'? (-
default?) Although, since it doesn't work for his hand-compiled 3.1 either,
this looks more like a filesystem / sysconfig configuration problem.

> Btw., looking at the title again - I don't think you need cirrusfb to
> get higher resolutions, at least not if you're talking about X (only if
> you merely care about the text consoles this would be the case),
> as long as a respective X driver is present.

Actually, he is loading the xorg cirrus module. It loads two candidates - vesa
& cirrus. Then it unloads vesa in favor of the better cirrus candidate.
Unfortunately, after running through all the possible modes, it only accepts:

[ 33.240] (--) CIRRUS(0): Virtual size is 800x600 (pitch 1024)
[ 33.240] (**) CIRRUS(0): *Default mode "800x600": 40.0 MHz, 37.9 kHz, 60.3
Hz
[ 33.240] (II) CIRRUS(0): Modeline "800x600"x60.3 40.00 800 840 968 1056
600 601 605 628 +hsync +vsync (37.9 kHz)
[ 33.240] (**) CIRRUS(0): *Default mode "800x600": 36.0 MHz, 35.2 kHz, 56.2
Hz
[ 33.240] (II) CIRRUS(0): Modeline "800x600"x56.2 36.00 800 824 896 1024
600 601 603 625 +hsync +vsync (35.2 kHz)
[ 33.240] (**) CIRRUS(0): *Default mode "640x480": 25.2 MHz, 31.5 kHz, 59.9
Hz
[ 33.240] (II) CIRRUS(0): Modeline "640x480"x59.9 25.18 640 656 752 800
480 490 492 525 -hsync -vsync (31.5 kHz)
[ 33.240] (==) CIRRUS(0): DPI set to (96, 96)

Xorg.0.log: http://pastebin.com/d49wcUxD

I would be grateful for nay clues you can give me & Flavio. Thanx.

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

Re: BAR 0: cirrusfb load errors prevent hvm domu from getting resolutions above 800x600 [ In reply to ]

JBeulich at suse

Nov 21, 2011, 12:04 AM

Post #6 of 7 (318 views)

Permalink

>>> On 21.11.11 at 01:01, jim burns <jim_burn@bellsouth.net> wrote:
> I meant is a BAR 0: error a commonly understood problem with common steps to
> find and fix the *configuration* problem, not where can I tinker with kernel
> code. I would think suse's 2.6.37.1-1.2-desktop kernel would work as is in an
> hvm domain. Or should he be using a different suse kernel 'flavor'? (-
> default?) Although, since it doesn't work for his hand-compiled 3.1 either,
> this looks more like a filesystem / sysconfig configuration problem.

Using any fb driver other than VESA and the DRM base ones is - afaik -
uncommon, if not unsupported.

> Actually, he is loading the xorg cirrus module. It loads two candidates -
> vesa
> & cirrus. Then it unloads vesa in favor of the better cirrus candidate.
> Unfortunately, after running through all the possible modes, it only
> accepts:
>
> [ 33.240] (--) CIRRUS(0): Virtual size is 800x600 (pitch 1024)
> [ 33.240] (**) CIRRUS(0): *Default mode "800x600": 40.0 MHz, 37.9 kHz,
> 60.3
> Hz
> [ 33.240] (II) CIRRUS(0): Modeline "800x600"x60.3 40.00 800 840 968
> 1056
> 600 601 605 628 +hsync +vsync (37.9 kHz)
> [ 33.240] (**) CIRRUS(0): *Default mode "800x600": 36.0 MHz, 35.2 kHz,
> 56.2
> Hz
> [ 33.240] (II) CIRRUS(0): Modeline "800x600"x56.2 36.00 800 824 896
> 1024
> 600 601 603 625 +hsync +vsync (35.2 kHz)
> [ 33.240] (**) CIRRUS(0): *Default mode "640x480": 25.2 MHz, 31.5 kHz,
> 59.9
> Hz
> [ 33.240] (II) CIRRUS(0): Modeline "640x480"x59.9 25.18 640 656 752
> 800
> 480 490 492 525 -hsync -vsync (31.5 kHz)
> [ 33.240] (==) CIRRUS(0): DPI set to (96, 96)

That's something that may need looking at from the X side then. And
again, it may well be that 800x600 is all that's supposed to be
supported for a HVM guest here (i.e. anything beyond might be
considered a feature request rather than a bug, but it may also be
that all you need is some extension to the default monitor definition
[which admittedly shouldn't be really meaningful in a virtual environment]).

Jan

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

Re: BAR 0: cirrusfb load errors prevent hvm domu from getting resolutions above 800x600 [ In reply to ]

fbcyborg at gmail

Nov 21, 2011, 1:48 AM

Post #7 of 7 (309 views)

Permalink

On 21 November 2011 01:01, jim burns <jim_burn@bellsouth.net> wrote:
> I meant is a BAR 0: error a commonly understood problem with common steps to
> find and fix the *configuration* problem, not where can I tinker with kernel
> code. I would think suse's 2.6.37.1-1.2-desktop kernel would work as is in an
> hvm domain. Or should he be using a different suse kernel 'flavor'? (-
> default?) Although, since it doesn't work for his hand-compiled 3.1 either,
> this looks more like a filesystem / sysconfig configuration problem.
Just to make some precisation here: I took the configuration file from /boot
(i.e. the config file of 2.6.37.1-1.2-desktop kernel which comes bundled with
the installation) and copied into the 3.1 source kernel directory and compiled
again the kernel. I even modified something about XEN, making it domU capable
(like if it was a PV domU and not a hvm domU).

Thank you so much for your support,

--
Flavio

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