[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>On Tue, Jan 26, 2010 at 01:40:12AM +0100, Ronny.Hegewald@xxxxxxxxx wrote:
>> Software: xen 3.4.1, lastest xen/master (version 2.6.31.6), both 32bit
>> Hardware: Intel Core2Duo System
>>           4GB Ram
>>           Realtek ALC888 soundchip
>
>Motherboard?
MSI P35 Neo.

>
>What I think you are saying is that, when you perform these steps:
>
>1). Boot up machine, have swiotlb=16384 set (or just hand-coded
>swiotlb.c to have a default size of 32MB).
>
>2). Start a DomU with more than 66MB allocated to it.
>
>3). Load the sound modules in Dom0
>
>4). Play music/sound/etc in Dom0, the sound works fine.

Generally right except a little difference.

1.) if i let the swiotlb unchanged at 64 MB and start a DomU with 66 MB or more 
Ram and do steps 3 and 4 the sound appears; with less RAM there is no sound
2.) if i lower the swiotlb to 32 MB and start a DomU with less then 66 MB Ram 
and do steps 3 and 4, then the sound is fine.


>What I am curious is your E820 table. That is the first thing Xen
>prints. You can get that by doing 'xm dmesg'
>
>Also include your 'dmesg' output for good measure. 

Attached.

>Lastly, try adding this line to your Xen line: dom0_mem=max:2GB and
>don't do any of the above mentioned hacks. Just start the sound module
>and see if it works.

I tried that too but used as parameter dom0_mem=2GB. But i will retry it anyway 
because i tried many several things so i might have done something wrong in the 
process.

>Back to the sound card. The sound card can (I think) only DMA up to 4GB,
>so when it tries to fetch data from above 4GB it ends up truncating the
>physical address down to 32-bit and fetches data from somewhere else. So
>you are probably listening to binary code being played :-)

In that case shouldnt i have that problem on bare metal too? And there is no 
such problem under a 2.6.31 kernel with the forwardported dom0 patches from 
gentoo either. 

>Having a DomU start makes Xen shrink Dom0 by a certain size and the DMA
>window for the sound is moved "down" below the 4GB mark (that I think is
>the problem you are encountering). This should NOT happen if the sound
>card driver is using DMA libraries to allocate that buffer (ie,
>dma_alloc_coherent, dma_alloc_free, etc). But it might be using
>'vmalloc_32' which on virtualized environments is not guaranteed to give
>a swatch of memory below 4GB. Here are the steps to investigate:
>look in the sound card drivers and see where and how it allocates the buffer.

Thanks alot for all the explanations. Now i have a starting-point to do some 
further investigations.

Attachment: dmesg.log
Description: Binary data

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.