xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
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

  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 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).