[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 Attachment:
next.config Attachment:
fb_mmap_instrument.txt Attachment:
debugoutput.txt _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |