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

Re: [Xen-devel] pvops dom0: no sound after boot; possibly causedby swiot

To: <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] pvops dom0: no sound after boot; possibly causedby swiotlb
From: Ronny.Hegewald@xxxxxxxxx
Date: Mon, 01 Feb 2010 21:54:02 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 01 Feb 2010 12:54:24 -0800
Envelope-to: www-data@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>Well, since you are volunteering. The problem sounds like the sound card
>allocates a buffer from the region above 4GB and tries to DMA to it.
>Keep in mind that on most machines, when you have 4GB, 768 MB of it are 
>offset
>past the 4GB mark. You have these two mega regions: 0-3.3GB, 4GB-4.7GB,
>the 3.3GB to 4GB is called the PCI hole.

I added some log-messages in the sound-driver and indeed, it allocates memory 
from above 4GB.

On bare metal and with dom0 based on the forward-ported xen-patches from gentoo 
the dma-memory is allocated in the 4GB range.

When i checked the dma-memory allocation in the driver i noticed that depending 
if the sound-card reports that it is 64bit-compatible the driver sets the 
dma_mask to 64, else to 32 (by calling pci_set_consistent_dma_mask).

So i changed the driver that it always sets the dma-mask to 32 - and the sound 
worked without the need to start a domU. 

Which left the question why it didnt worked out of the box on pvops-dom0.

So i followed the code for the dma-allocation from the sound-driver and found 
the problem in the xen-swiotlb code in arch/x86/xen/pci-swiotlb.

Bare metal and the forward-ported dom0 both call dma_alloc_coherent_mask if 
they try to allocate coherent dma-memory - pvops dom0 doesnt. This call sets 
the DMA-mask to 24 bit when __GFP_DMA is set, else to 32-bit. 

I guess this is the right fix for pvops-dom0 too? I will sent a proper patch 
for that soon.

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

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