From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arvind R Subject: Re: Nouveau on dom0 Date: Wed, 3 Mar 2010 22:41:19 +0530 Message-ID: References: <20100225125552.GC9040@phenom.dumpdata.com> <20100225174411.GA13270@phenom.dumpdata.com> <20100301160130.GB7881@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Konrad Rzeszutek Wilk Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Wed, Mar 3, 2010 at 3:04 AM, Arvind R wrote: > On Mon, Mar 1, 2010 at 9:31 PM, Konrad Rzeszutek Wilk > wrote: >> On Fri, Feb 26, 2010 at 09:04:33PM +0530, Arvind R wrote: >>> On Thu, Feb 25, 2010 at 11:14 PM, Konrad Rzeszutek Wilk >>> wrote: >>> > On Thu, Feb 25, 2010 at 09:01:48AM -0800, Arvind R wrote: >>> >> On Thu, Feb 25, 2010 at 6:25 PM, Konrad Rzeszutek Wilk >>> >> wrote: >>> >> > On Thu, Feb 25, 2010 at 02:16:07PM +0530, Arvind R wrote: >>> >> >> I merged the drm-tree from 2.6.33-rc8 into jeremy's 2.6.31.6 mast= er and >>> >> =3D=3D=3D=3D=3D=3D=3D snip =3D=3D=3D=3D=3D=3D=3D >>> >> > is not. Would it be possible to trace down who allocates that *cha= n? You >>> >> > say it is 'PRAMIN' - is that allocated via pci_alloc_* call? >>> =3D=3D=3D=3D=3D=3D=3D snip =3D=3D=3D=3D=3D=3D=3D >>> >> So, there must be a mmap call somewhere to map the area to user-spac= e >>> >> for that problem write to work on non-Xen boots. Will try track down= some more >>> >> and post. With mmaps and PCIGARTs - it will be some hunt! >>> =A0=3D=3D=3D=3D=3D=3D=3D snip =3D=3D=3D=3D=3D=3D=3D >>> > to the drm_radeon driver which used it as a ring buffer. Took a bit o= f >>> > hoping around to find who allocated it in the first place. >>> > >>> The pushbuf (FIFO/RING) is the only means of programming the card DMA >> the 'ttm_bo_init'. I remember Pasi having an issue with this on Radeon >> and I provided a hack to see if it would work. Take a look at this >> e-mail: >> >> http://lists.xensource.com/archives/cgi-bin/extract-mesg.cgi?a=3Dxen-dev= el&m=3D2010-01&i=3D20100115071856.GD17978%40reaktio.net >> >>> >> It looks to be using 'ioremap' which is Xen safe. Unless your card has >> an AGP bridge on it, at which point it would end up using >> dma_alloc_coherent in all likehood. Can't do that - some later allocations are huge. >>> >>> As of now, accelerator on Xen stops right at the initialisation stage -= when >> I think that the ttm_bo calls set up pages in the 4KB size, but the >> initial channel requests a 64KB one. I think it also sets up > Your ttm patch using dma_alloc_coherent instead of alloc_page resulted in > the same problem as with the Radeon report - leaking pages, erroneous pag= e count >> page-table directory so that when the GPU accesses the addresses, it >> gets the real bus address. I wonder if it fails at that thought - >> meaning that the addresses that are written to the page table are >> actually the guest page numbers (gpfn) instead of the machine page numbe= rs (mfn). > > No, I don't think thats how it works. The user-space write triggers an > aio-write - which triggers do_page_fault, handle_mm_fault, do_linear_fault, __do_fault and finally ttm_bo_vm_fault. ttm_bo_fault returns VM_FAULT_NOPAGE - but xen-boot keeps on re-triggering the same fault. when vm_fault calls ttm_tt_get_page, the page is already there, and the handler does another vm_insert_page (i changed vm_insert_mixed vm_insert_page/pfn based on io_mem, now the only patch, and it works on bare machine) on and on and on. What can possibly cause the fault-handler to repeat endlessly? If a wrong page is backed at the user-address, it should create bad_access = or some other subsequent events - but the system is running fine minus all loc= al consoles! If the insertion is to a wrong place, this can happen; but the top-level trap is the only provider of the address - and the fault addres and vma address match, and the same code works fine on bare-boot. ttm_tt_get_page calls alloc in a loop - so it may allocate multiple pages f= rom start/end depending on Highmem memory or not - implying asynchronous alloca= tion and mapping. All I want now is *ptr =3D (uint32_t)data to work as of now!