[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
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |