From: Arvind R <arvino55@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: Nouveau on dom0
Date: Fri, 5 Mar 2010 13:16:13 +0530 [thread overview]
Message-ID: <d799c4761003042346k1bc2477mb7711927ea54fb7a@mail.gmail.com> (raw)
In-Reply-To: <20100304182518.GB20263@phenom.dumpdata.com>
On Thu, Mar 4, 2010 at 11:55 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Thu, Mar 04, 2010 at 02:47:58PM +0530, Arvind R wrote:
>> On Wed, Mar 3, 2010 at 11:43 PM, Konrad Rzeszutek Wilk
>> <konrad.wilk@oracle.com> 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
>> Have patched - did not apply clean. Will compile and get some info.
> take the print_data function and just jam it in the tt_bo_vm_fault code
Linking problems. But compiled and run
!!! CANNOT lookup_address()!!! Returns NULL on bare AND Xen
Before AND After vm_insert/remap_pfn. Address looked_up is what
fault_handler passes in. Had to add a NULL check in print_data.
Bare-boot log.
[TTM] ttm_bo_vm_fault: faulting-in pages, TTM_PAGE_FLAGS=0x0
[ Before:]PFN: Failed lookup_address of 0x7fd82e9aa000
[ After :]PFN: Failed lookup_address of 0x7fd82e9aa000
Ring any bells?
>> > 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.
>> 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
>
> Let me take a look at it tomorrow. Bit swamped.
>
next prev parent reply other threads:[~2010-03-05 7:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-25 8:46 Nouveau on dom0 Arvind R
2010-02-25 12:55 ` Konrad Rzeszutek Wilk
2010-02-25 17:01 ` Arvind R
2010-02-25 17:44 ` Konrad Rzeszutek Wilk
2010-02-26 15:34 ` Arvind R
2010-03-01 16:01 ` Konrad Rzeszutek Wilk
2010-03-02 21:34 ` Arvind R
2010-03-03 17:11 ` Arvind R
2010-03-03 18:13 ` Konrad Rzeszutek Wilk
2010-03-04 9:17 ` Arvind R
2010-03-04 18:25 ` Konrad Rzeszutek Wilk
2010-03-05 7:46 ` Arvind R [this message]
2010-03-05 20:23 ` Konrad Rzeszutek Wilk
2010-03-06 8:16 ` Arvind R
2010-03-06 20:59 ` Arvind R
2010-03-06 23:56 ` Arvind R
2010-03-08 17:51 ` Konrad Rzeszutek Wilk
2010-03-10 12:50 ` [Solved] " Arvind R
2010-03-10 14:00 ` Pasi Kärkkäinen
2010-03-10 19:37 ` Jeremy Fitzhardinge
[not found] ` <20100311201536.GA22182@phenom.dumpdata.com>
2010-03-12 6:12 ` Arvind R
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=d799c4761003042346k1bc2477mb7711927ea54fb7a@mail.gmail.com \
--to=arvino55@gmail.com \
--cc=konrad.wilk@oracle.com \
--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).