From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ronny.Hegewald@online.de Subject: Re: pvops dom0: no sound after boot; possibly causedby swiotlb Date: Mon, 01 Feb 2010 21:54:02 +0100 Message-ID: <5670117.3805321265057642467.JavaMail.servlet@kundenserver> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: konrad.wilk@oracle.com Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >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.