WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Nouveau on dom0

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] Nouveau on dom0
From: Arvind R <arvino55@xxxxxxxxx>
Date: Thu, 4 Mar 2010 14:47:58 +0530
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 04 Mar 2010 01:18:31 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=InGnm1Ta+7d4C+vdv+j1woMmRE063J5iHkYhWaEGkuY=; b=Qh8i8kISoMJHC4V7x64wT69ltzgnKO8E2sqceH8Pw0md6YekS7olRrMS1TeZFChH5S oAnCYceH7+HuwUH3W7qj85qHdoq2M5xsafurfhz/4BY9zXR8nNmPT/Z532TGrZJ1YdcU Rd58RZhRf/kEyC6j9yaT1hSJUvqjlrnaBDRwk=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xi24JfXnfuJKVvMQcCFvIGWQWQOzV14HiY+xLX1NUC41y4sh6A7AtV/utisFbqBRsn Z6RiosigB3IDg68iTsqZds20okAlOYftPfFVhAPeJ/10yMf0LzZNtC5n8T1fPk2pwIU2 G76Mpgw+KlS2OhBmCI5FV3f24mvJBh69EOrKk=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100303181303.GA21078@xxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <d799c4761002250046j4fc14785ue17db46d6e3e71ce@xxxxxxxxxxxxxx> <20100225125552.GC9040@xxxxxxxxxxxxxxxxxxx> <d799c4761002250901g6029a69et21fcf1d8556f047@xxxxxxxxxxxxxx> <20100225174411.GA13270@xxxxxxxxxxxxxxxxxxx> <d799c4761002260734j13bc01e3vfd7788b6196230ea@xxxxxxxxxxxxxx> <20100301160130.GB7881@xxxxxxxxxxxxxxxxxxx> <d799c4761003021334t58815ed3p96dc343635b2da2c@xxxxxxxxxxxxxx> <d799c4761003030911l51013f07mc1bf4aa15df519c4@xxxxxxxxxxxxxx> <20100303181303.GA21078@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Wed, Mar 3, 2010 at 11:43 PM, Konrad Rzeszutek Wilk
<konrad.wilk@xxxxxxxxxx> wrote:
>> > aio-write -
>>
>> which triggers do_page_fault, handle_mm_fault, do_linear_fault, __do_fault
>> and finally ttm_bo_vm_fault.

> I've attached a simple patch I wrote some time ago to get the real MFNs
> and its page protection. I think you can adapt it (print_data function to be 
> exact)
> to peet at the PTE and its protection values.
Have patched - did not apply clean. Will compile and get some info.

> There is an extra flag that the PTE can have when running under Xen: 
> _PAGE_IOMAP.
> This signifies that the PFN is actually the MFN. In this case thought
> it sholdn't be enabled b/c the memory is actually gathered from
> alloc_page. But if it is, it might be the culprit.

>> What can possibly cause the fault-handler to repeat endlessly?

FYI: about 2000 times a second - slowed by printk

>> 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 local
> So  you see this fault handler being called endlessly while the machine
> is still running and other pieces of code work just fine, right?
Right. Can ssh in - but no local console

>> ttm_tt_get_page calls alloc in a loop - so it may allocate multiple pages 
>> from
>> start/end depending on Highmem memory or not - implying asynchronous 
>> allocation
>> and mapping.
>
> I thought it had some logic to figure out that it already handled this
> page and would return an already allocate page?
Right.

I think the problem lies in the vm_insert_pfn/page/mixed family of functions.
These are only used (grep'ed kernel tree) and invariably for mmaping.
Scsi-tgt, mspec, some media/video, poch,android in staging and ttm
- and, surprise - xen/blktap/ring.c and device.c
- which both check XENFEAT_auto_translated_physmap

Pls. look at xen/blktap/ring.c - it looks to be what we need

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel