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
signature.asc
Description: OpenPGP digital signature
