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

[jim burns <jim_burn@xxxxxxxxxxxxx>]

On Thu November 17 2011, 9:38:56 AM, Jan Beulich wrote:
> >>> On 17.11.11 at 09:31, jim burns <jim_burn@xxxxxxxxxxxxx> wrote:
> > On Thu November 17 2011, 8:10:08 AM, Jan Beulich wrote:
> >> >>> On 17.11.11 at 00:28, jim burns <jim_burn@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel