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