[Qemu-devel] Re: no sound in MusicPal with qemu 0.12.2

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1735 bytes --]

Jan Kiszka wrote:
> malc wrote:
>> On Sat, 23 Jan 2010, ondrej drbohlav wrote:
>>
>>> Hi there,
>>>
>>> I have compiled qemu 0.12.2 on an x64 ubuntu (8.10) and run MusicPal
>>> in it with SDL.
>>> MusicPal works OK but there is no sound.
>> Confirmed.
>>
>>> I have done essentially the same with qemu 0.11.1. The sound is there
>>> (thanks jki for suggesting a previous version).
>>>
>>> Please find below the configs and logs & contact me if additional info
>>> is needed.
>>>
>>> Cheers, Ondrej
>>>
>>> 1) qemu-0.12.2
>> [..snip..]
>>
>> Someone would have to bisect it.
> 
> Already done: it's b3a219883ebe21f55a8ee5e7e5b38b9eb309e9c0. But that
> patch looks sane. I guess it just revealed a hidden bug in Musicpal's
> i2c use. Need to dig deeper.

Found, trivial patch on the way.

> 
>> BTW, Jan, 2e87c5b937444c1155073f7b10d630e0e383e5d8 doesn't quite do
>> what i said helps[1] and conseqently musicpal enters an infinite loop
>> again...
>>
>> [1] http://lists.gnu.org/archive/html/qemu-devel/2009-09/msg00920.html
>>
> 
> OK, I will have to look into the Linux driver code to check the loop
> termination conditions again.

This still makes no sense, at least based on available driver sources
and so far observed behavior with existing firmware images: the TX queue
is always setup to form a ring, at no point the driver destroys this
ring before triggering a TX. So we are only left with a potentially
undefined (NULL) ring entry pointer, and that is what my commit tried to
catch. I rather suspect we see a subtle memory corruption here.

Malc, when do you get this? Could you instrument the loop to check if we
get off-track before, scanning random guest memory?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]