09.11.2010 16:48, malc wrote:
> On Tue, 9 Nov 2010, Jan Kiszka wrote:
>
>> Am 09.11.2010 00:48, Michael Tokarev wrote:
[]
>>> Yes, sound in 0.13 appears to be broken. It is looping in
>>> select/read loop forever, read returns EAGAIN and select
>>> says the filedescriptor is ready.
>>
>> Try to set QEMU_AUDIO_DAC_TRY_POLL=0 for the environment of the qemu
>> process. That's long required to get sound out of the Musicpal emulation
>> as well (malc, you may recall this). It even got worse with current
>> qemu.git: previously, the sounds was just quirky. Now the system is
>> booting way slower in polling mode and is partially not reactive anymore.
>
> Wich driver is being used? ALSA stuff should have been fixed by Jindrich
> Makovicka in:
> 38cc9b607f85017b095793cab6c129bc9844f441 and
> 22d948a2d97434192018bdabaf0a50cda7f994be
As far as I can see, both are in 0.13.0 release, which is
the one I'm running currently.
This is with QEMU_AUDIO_DRV=alsa (default on Debian):
...
gettimeofday({1289311843, 426751}, NULL) = 0
select(24, [0 5 13 18 20 23], [], [], {1, 0}) = 1 (in [13], left {0, 999998})
poll([{fd=13, events=POLLIN|POLLERR|POLLNVAL}], 1, 0) = 1 ([{fd=13, revents=POLLIN}])
ioctl(14, 0xc0844123, 0x8e75200) = 0
ioctl(14, 0xc0844123, 0x8e75200) = 0
clock_gettime(CLOCK_MONOTONIC, {654227, 9502215}) = 0
clock_gettime(CLOCK_MONOTONIC, {654227, 9521568}) = 0
gettimeofday({1289311843, 426911}, NULL) = 0
select(24, [0 5 13 18 20 23], [], [], {1, 0}) = 1 (in [13], left {0, 999998})
poll([{fd=13, events=POLLIN|POLLERR|POLLNVAL}], 1, 0) = 1 ([{fd=13, revents=POLLIN}])
ioctl(14, 0xc0844123, 0x8e75200) = 0
ioctl(14, 0xc0844123, 0x8e75200) = 0
clock_gettime(CLOCK_MONOTONIC, {654227, 9660799}) = 0
clock_gettime(CLOCK_MONOTONIC, {654227, 9680088}) = 0
gettimeofday({1289311843, 427070}, NULL) = 0
...
Fd#13 is /dev/snd/timer.
For this test, I tried -soundhw ac97. The same happens with
es1370 too.
With oss or pulseaudio it works just fine.
Note that the problem does not occur always. I just
booted a win7 guest with ac97, installed a driver, and it
whole thing appears to work without this 100% cpu loop, at
least after settling down. But several attempts to run a
linux guest with es1370 or ac97 results in a reproduceable
tight loop - right after bootup.
And I just discovered another issue with QUEMU_AUDIO_DRV=pa:
when I tried to close sdl window, kvm wents into tight loop
waitpid(30478, 0xffa84ccc, 0) = -1 ECHILD (No child processes)
waitpid(30478, 0xffa84ccc, 0) = -1 ECHILD (No child processes)
waitpid(30478, 0xffa84ccc, 0) = -1 ECHILD (No child processes)
waitpid(30478, 0xffa84ccc, 0) = -1 ECHILD (No child processes)
waitpid(30478, 0xffa84ccc, 0) = -1 ECHILD (No child processes)
waitpid(30478, 0xffa84ccc, 0) = -1 ECHILD (No child processes)
waitpid(30478, 0xffa84ccc, 0) = -1 ECHILD (No child processes)
...
obviously consuming 100% cpu, and the only way to stop this is to
kill it. Unrelated, but also buggy ;)
Thanks!
/mjt
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
