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?
>> 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.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home