[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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |