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
mmap-hold.c
Description: Text document
pt-dump
Description: Text document
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home