[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 03/15/2010 08:46 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 12, 2010 at 04:51:30PM -0800, Jeremy Fitzhardinge wrote:
>   
>> On 03/12/2010 04:44 PM, Eamon Walsh wrote:
>>     
>>> 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
>>>       
> Is the machine spinning? Meaning if you start writting to the mmap
> region the machine looks to be stuck?
>   

No, the machine keeps running just fine.  Although I tried reading out
of the mmap region and it is definitely not framebuffer memory, it's
filled with some kind of binary data on one of my machines which is not
there if I just read() from /dev/fb0.



>   
>>> 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.
>>>    
>>>       
>> Yes.  I suspect there's a missing VM_IO in there, and so the mmap is  
>> mapping the wrong pages (if you're lucky you might be able to crash the  
>> machine to see something juicy).
>>     
> <scratches his head>
>
> The nvidia framebuffer (drivers/video/nvidia/nvidia.c) does this:
>
> 1369         info->screen_base = ioremap(nvidiafb_fix.smem_start, 
> par->FbMapSize);
>
> where the start of memory is obtained via
> 1328         nvidiafb_fix.smem_start = pci_resource_start(pd, 1);
>
> I believe the 'ioremap' works pretty good, otherwise we would have other
> PCI devices having trouble.
>
> ... and in another code (fbmem.c):
>
> 1321 static int
> 1322 fb_mmap(struct file *file, struct vm_area_struct * vma)
> ..
> 1345         start = info->fix.smem_start;
> ..
> 1363         /* This is an IO map - tell maydump to skip this VMA */
> 1364         vma->vm_flags |= VM_IO | VM_RESERVED;
>
> .. it _does_ set the VM_IO, but that is OK since the memory is actually
> backed by the PCI device.
>
> Eamon, can you provide a more detail serial output? That could shed some
> light on this. Another thing you could try to make sure you are actually
> hitting the right mmap, is to instrument fb_mmap. I would recommend
> printing out the vma->vm_start, vm_end, and start to see if the look
> reasonable.
>
>
>   

The serial output is attached.

The patch I used to instrument the fb_mmap function and the output it
produced for a couple of runs are also attached.

And I tossed in my kernel .config for good measure.

What else is needed?


-- 

Eamon Walsh 
National Security Agency

Attachment: fb_mmap_instrument.patch
Description: Text Data

Attachment: next.config
Description: Text document

Attachment: fb_mmap_instrument.txt
Description: Text document

Attachment: debugoutput.txt
Description: Text document

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.