From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Pasi Kärkkäinen" <pasik@iki.fi>
Cc: Eamon Walsh <ewalsh@tycho.nsa.gov>,
Daniel De Graaf <dgdegra@tycho.nsa.gov>,
xen-devel@lists.xensource.com
Subject: Re: Frame buffer mmap not working in pvops dom0
Date: Wed, 21 Jul 2010 10:42:09 -0400 [thread overview]
Message-ID: <20100721144209.GA5031@phenom.dumpdata.com> (raw)
In-Reply-To: <20100721141613.GG17817@reaktio.net>
[-- Attachment #1: Type: text/plain, Size: 1966 bytes --]
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 guess many (most?) graphics related fixes are in Konrad's git tree..
<nods>
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.
[-- Attachment #2: fb_test.c --]
[-- Type: text/plain, Size: 1525 bytes --]
#include <stdio.h>
#include <errno.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <fcntl.h>
#include <ctype.h>
#include <linux/fb.h>
static char filename[] = "/dev/fb0";
int main(int argc, char *argv[])
{
struct fb_var_screeninfo screeninfo;
int fd = -1;
int rc;
unsigned char *fbuf;
struct stat buf;
int row, column;
int i;
int len;
printf("Starting..[%s]\n", filename);
fd = open(filename, O_RDWR);
if (fd <= 0) {
printf("Could not open; err: %d\n", errno);
return errno;
}
if (stat(filename, &buf) != 0) {
printf("Could not open; err: %d\n", errno);
return errno;
}
printf("%s: len:%d\n", filename, buf.st_size);
rc = ioctl(fd, FBIOGET_VSCREENINFO, &screeninfo);
if (rc) {
printf("Could not do ioctl. err: %d\n", errno);
return errno;
}
printf("%s: bits/pixel%d\n", filename, screeninfo.bits_per_pixel);
len = screeninfo.xres * screeninfo.yres;
fbuf = mmap(0, len, PROT_WRITE|PROT_READ, MAP_SHARED, fd, 0);
if (fbuf == MAP_FAILED) {
printf("Could not map: error: %d\n", errno);
return errno;
}
if (argc > 1) {
int outfd;
outfd = open(argv[1], O_RDWR|O_CREAT, 0644);
if (outfd != -1) {
write(outfd, fbuf, len);
close(outfd);
}
}
printf("(%lx): Writting .. [%d:%d]\n", fbuf, screeninfo.xres,screeninfo.yres);
i = 0;
for (i = 0; i < len; i++) {
fbuf[i] = (i % 255);
}
printf("Done!\n");
if (munmap(fbuf, len)) {
printf("Could not unmap: %d\n", errno);
return errno;
}
close(fd);
return 0;
}
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2010-07-21 14:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-21 13:47 Frame buffer mmap not working in pvops dom0 Daniel De Graaf
2010-07-21 14:16 ` Pasi Kärkkäinen
2010-07-21 14:42 ` Konrad Rzeszutek Wilk [this message]
2010-07-21 14:49 ` Pasi Kärkkäinen
2010-07-21 15:26 ` Daniel De Graaf
2010-07-21 19:00 ` Konrad Rzeszutek Wilk
2010-07-21 19:12 ` Konrad Rzeszutek Wilk
2010-07-21 19:22 ` Daniel De Graaf
2010-07-21 19:50 ` Konrad Rzeszutek Wilk
2010-07-21 20:27 ` Daniel De Graaf
2010-07-28 14:29 ` Konrad Rzeszutek Wilk
2010-07-28 15:33 ` Konrad Rzeszutek Wilk
2010-07-28 18:09 ` Daniel De Graaf
2010-07-21 20:36 ` Eamon Walsh
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=20100721144209.GA5031@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=ewalsh@tycho.nsa.gov \
--cc=pasik@iki.fi \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.