From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: George Coker <gscoker@tycho.nsa.gov>,
Eamon Walsh <ewalsh@tycho.nsa.gov>,
Xen-devel <xen-devel@lists.xensource.com>
Subject: Re: Fbdev graphics broken in xen/next dom0
Date: Mon, 15 Mar 2010 20:46:30 -0400 [thread overview]
Message-ID: <20100316004630.GA7622@phenom.dumpdata.com> (raw)
In-Reply-To: <4B9AE192.30104@goop.org>
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.
next prev parent reply other threads:[~2010-03-16 0:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-12 20:24 Fbdev graphics broken in xen/next dom0 Eamon Walsh
2010-03-12 21:42 ` Jeremy Fitzhardinge
2010-03-13 0:44 ` Eamon Walsh
2010-03-13 0:51 ` Jeremy Fitzhardinge
2010-03-16 0:46 ` Konrad Rzeszutek Wilk [this message]
2010-03-16 21:52 ` Eamon Walsh
2010-03-16 22:19 ` Konrad Rzeszutek Wilk
2010-03-25 23:55 ` Eamon Walsh
2010-03-27 9:14 ` Arvind R
2010-03-27 21:52 ` Jeremy Fitzhardinge
2010-03-28 9:33 ` Arvind R
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100316004630.GA7622@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=ewalsh@tycho.nsa.gov \
--cc=gscoker@tycho.nsa.gov \
--cc=jeremy@goop.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).