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/
Home Products Support Community News


[Xen-devel] Re: xen-swiotlb

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: [Xen-devel] Re: xen-swiotlb
From: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
Date: Mon, 16 Aug 2010 21:32:27 +0200
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 16 Aug 2010 12:33:26 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100816144353.GB29351@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>
Organization: Eikelenboom IT services
References: <1045449371.20100815232839@xxxxxxxxxxxxxx> <20100816144353.GB29351@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Monday, August 16, 2010, 4:43:53 PM, you wrote:

> 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.

I suspect the xhci drivers, because usb2 (ohci/ehci) works fine, but it's all 
hard to find due to the freeze without debug output.
And for linux, xen and pci-passthrough is still somewhat a corner case :(

xhci-isoc patches required for webcams/videograbbers to work got merged in 
2.6.36 merge window, together with xen-swiotlb.
(isoc patch series by "Xu, Andiry" <Andiry.Xu@xxxxxxx> , maintainer of the 
complete xhci tree is Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>)

So what i have as domU kernel is:
- from Linus tree 2.6.36-pre with latest commit 
- pulled your devel/xen-pcifront-0.5 tree, and fixed the merge conflicts due to 
the pv on hvm patches, in the same way Jeremy did for his 2.6.36 branch.

- Added a patch for xhci isoc that fixes another bug. (attached 
- Added a patch that shows extra debug info for xhci from the author of the 
xhci-isoc pathes (attached isoc_length5.patch)

- Changed some debug lines from dbg to warn level, (just enabling xhci-debug in 
kernel config floods the logs too fast, so i just enabled them in xhci-mem.c)
  (Attached a patch with all my changes to xhci*, including the 2 patches above 

- Added some printk's to swiotlb-xen.c to see which functions were used, and 
let some of them print the address as well, in the hope i could find some debug 
info there.(attached)

Apart from fixing the xhci in the end, is there a way to prevent xen from 
freezing altogether without leaving a trace ?
Even an Oops is much easier to debug than a freeze. Due to the nature of DMA 
that could perhaps be difficult, although there is an DMA API ...

Had a fruitful LinuxCon ?


Attachment: all-xhci-patches
Description: Binary data

Attachment: swiotlb-xen-debug-patch
Description: Binary data

Attachment: 0001-xHCI-update-ring-dequeue-pointer-when-process-missed.patch
Description: Binary data

Attachment: isoc_length5.patch
Description: Binary data

Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>