[Xen-devel] Re: xen-swiotlb

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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