[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Frame buffer mmap not working in pvops dom0
On 07/21/2010 10:42 AM, Konrad Rzeszutek Wilk wrote: > On Wed, Jul 21, 2010 at 05:16:13PM +0300, Pasi Kärkkäinen wrote: >> On Wed, Jul 21, 2010 at 09:47:57AM -0400, Daniel De Graaf wrote: >>> I'm trying to confirm the fix to the VESA fbdev mmap issue that was >>> brought up a few months ago >>> (http://marc.info/?l=xen-devel&m=126842551306571&w=2). The wiki page at > > Weird. I don't remember seeing that e-mail.. > >>> http://wiki.xensource.com/xenwiki/XenPVOPSDRM says that this bug should >>> be fixed, but doesn't point to a patch for the fix. I am still able to >>> reproduce the issue both on real hardware and by running Xen under qemu >>> (using cirrusfb on the dom0). Eamon (the original reporter) has also not >>> been able to confirm a fix. >>> >>> I'm currently testing using Xen 4.1 built from hg 21831:6bebaf40e925 and >>> a pvops dom0 from xen/stable-2.6.32.x revid c0a00fbe. >>> >>> So far, I've been able to determine that an mmap requesting multiple >>> pages from /dev/fb0 will result in page table entries all pointing to >>> the same physical page, which is not in the framebuffer address space. >>> Writing to the mapped page ends up corrupting parts of kernel memory. >>> I'd be happy to run further tests, try patches, or provide more >>> information if needed. > > Goodies. Let me fix up a tree that cleanly merges with Jeremy's xen/next > (or xen/stable-2.6.32.x) and give you a go with that. And then from > there we can come up with a fix. > > Can you tell me how you came up with the analysis? (that should speed up > finding the culprit). Any serial/dmesg outputs would be appreciated. > I have been dumping the page tables (using the attached pt-dump script, as qemu's "info tlb" only works on i386) from a paused qemu instance that is running a simple mmap-and-spin program (also attached). All 100 pages map to physical memory address 39a4c000. >From a bit more debugging, I've been able to trace the correct address (0xf0000000) being lost when it is passed by xen_make_pte to pte_pfn_to_mfn and eventually to get_phys_to_machine(0xf0000) which returns -1. Still not sure where the final physical address is coming from, but I'm guessing this is part of the problem. > > Daniel, > > I honestly don't remember which patch I thought fixed it. But I do know > that when the /dev/fb0 was backed by DRM (nvidia) it worked (I used the > below program). > > Granted now that I tested it with fbxine and it hangs with a Xen error. > Let me start using Eamon's program. > The attached program has no visible effect on the screen when run, so it's likely also not working here. -- Daniel De Graaf National Security Agency Attachment:
mmap-hold.c Attachment:
pt-dump _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |