[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] BAR 0: cirrusfb load errors prevent hvm domu from getting resolutions above 800x600
- To: Jan Beulich <JBeulich@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
- From: jim burns <jim_burn@xxxxxxxxxxxxx>
- Date: Sun, 20 Nov 2011 19:01:03 -0500
- Cc: Flavio <fbcyborg@xxxxxxxxx>, xen-users@xxxxxxxxxxxxxxxxxxx, "Fajar A. Nugraha" <list@xxxxxxxxx>
- Delivery-date: Mon, 21 Nov 2011 00:02:17 +0000
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1321833671; bh=PYELQoqRkx5nHcuckLhh3qhCSa1Gf59yH37NgO90Opo=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=q2/xGf1oA9vN/4WI/c3xdrlNeAlb3wn3WAinbbkErtvvsTZkuVtgKM7l+f4dJXF6hVOlWsKurHTtOitRJCsSxVpcUyEiLNcRiXVLvLizVHtoMqt8CQ0q2aHYFFMt6DibMD8Yqees344PzNQOUcua4nmutBR55eCuVYbbTmitUiU=
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
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
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 188.8.131.52-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
[ 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
[ 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
[ 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)
I would be grateful for nay clues you can give me & Flavio. Thanx.
Xen-devel mailing list