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@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.
Right. I don't think it would help you immediately - I was thinking you could
take the print_data function and just jam it in the tt_bo_vm_fault code
and use it to print the PTE data.
> > 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?
> 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.
Xen-devel mailing list