[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Nouveau on dom0


  • To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
  • 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
  • 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=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.