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

[Xen-devel] Re: xen-swiotlb

To: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: xen-swiotlb
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Mon, 16 Aug 2010 10:43:53 -0400
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 16 Aug 2010 08:10:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1045449371.20100815232839@xxxxxxxxxxxxxx>
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: <1045449371.20100815232839@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-12-10)
On Sun, Aug 15, 2010 at 11:28:39PM +0200, Sander Eikelenboom wrote:
> Hi Konrad,
> 
> After i have exhausted all kernel debug options without getting a pointer to 
> my freezes, i have added some printk's to all functions in swiotlb-xen.c
> I see a lot of calls to xen_swiotlb_dma_mapping_error, which doesn't seem to 
> be good ?

The driver looks to be actually testing the value, which is great. Some
of the older drivers (r8169) don't even do that.
> 
> Although all the errors the device works fine (grabs video), but eventually 
> the machine freezes, probably due to overwriting some mem it shouldn't.

Looking at the output, the physical addresses that DMA-ed are:

0x1f2962dc0
0x1f24f2e68

and they look to be called quite often. In fact, there looks to be a
loop that does something like this:

again:
  p = kmalloc(..)

  dma = pci_map_single(p)
  pci_dma_mapping_error(dma);
  /* get some data.. */
  /* parse the: (pipe 0x80000280): IN:  c0 00 00 00 0c 00 01 00 */
  pci_unmap_sg(dma);
  goto again;

As the virtual address sent to pci_map_single looks to be sequentially
increasing.

It might be:
 a). the pci_dma_mapping_error is used incorrectly, ie, it is used
     as !pci_dma_mapping_error,  but I doubt that - the Linux kernel
     has soo many exampples of how to proper use that.
 b). The pci_dma_mapping_error implementation in Xen-SWIOTLB is busted,
     but I can't see how. The logic is basically 'return !addr' so, if
     you have addr = 0xf200000', you will get 0, which is the proper
     return value.
 c). the xhci driver does something similar to the pseudo-code I've
     pointed out. It is missing a kfree somewhere.

Can you point me to the git tree for the xhci and I can take a look
there? Also could you send me yor debug patch - that will help in
finding the culprit.


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

<Prev in Thread] Current Thread [Next in Thread>