[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] pvops dom0: no sound after boot; possibly causedby swiotlb
>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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |