From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Fbdev graphics broken in xen/next dom0 Date: Mon, 15 Mar 2010 20:46:30 -0400 Message-ID: <20100316004630.GA7622@phenom.dumpdata.com> References: <4B9AA301.6090303@tycho.nsa.gov> <4B9AB559.1070709@goop.org> <4B9ADFDB.1070300@tycho.nsa.gov> <4B9AE192.30104@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <4B9AE192.30104@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: George Coker , Eamon Walsh , Xen-devel List-Id: xen-devel@lists.xenproject.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). 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.