Re: [Xen-devel] Fbdev graphics broken in xen/next dom0

[Eamon Walsh <ewalsh@xxxxxxxxxxxxx>]

On 03/12/2010 04:42 PM, Jeremy Fitzhardinge wrote:
> On 03/12/2010 12:24 PM, Eamon Walsh wrote:
>   
>> I work in the same group as Dave Quigley and George Coker.  I'm working
>> on a graphical switcher application for Xen which uses the DirectFB
>> library on top of Linux VESA fbdev.  This runs in dom0 at the moment.
>> I'm using the latest xen/next pvops dom0 and xen-unstable hypervisor
>> compiled from source, with vga=ask so I can boot dom0 in a graphical mode.
>>
>> The problem I'm having is illustrated by the attached test program that
>> displays a green background with a white square for 10 seconds when run
>> as root.  It doesn't work on the xen/next / xen-unstable combo.  The
>> program runs and exits normally but all I see is a black screen.
>>
>> The program *does* work on xen/next running on the bare metal.  It also
>> works using the xen-unstable hypervisor with an older dom0, the 2.6.31.4
>> kernel with Novell patches.  So I think the issue is in the xen/next
>> kernel.  I've run the test program on different machines and observed
>> the same behavior.
>>
>> The xen-unstable / 2.6.31.4 dom0 combination works and I'm using that
>> for the moment but I'd like to be using pvops.  I would be happy to run
>> more tests / provide more data if needed.
>>    
>>     
> What's the hardware?  Do any messages appear either on the dom0 console 
> or the Xen console?  Does booting with a vga console help?
>   

The hardware is a Dell Latitude E6500 with nvidia graphics.  I also see
the issue on a Dell Optiplex 960 desktop with Intel graphics.  No
obvious messages on the consoles.  I am booting in VGA mode.

I have narrowed the problem down: it has something to do with mmap of
/dev/fb0 not syncing.  The attached C code mmaps /dev/fb0 and writes
some random bits.  On a configuration that does work (2.6.31.4 on
4.0-rc6, or xen/next on bare metal) the random bits are visible on the
screen.  With xen/next on 4.0-rc6, nothing is visible.  Calling msync()
before the sleep has no effect.  Also, using write() on /dev/fb0 always
works so it appears to be mmap related.


-- 

Eamon Walsh 
National Security Agency

Attachment: mmaptest.c
Description: Text document

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