Bug#685353: qemu-kvm 1.1.1 hangs using 100% CPU when using ES1370 emulation
Hi Michael, * Michael Tokarev schrieb: [ http://bugs.debian.org/685353 ] 05.09.2012 17:48, Mike Gerber wrote: Unfortunately I can't currently as this is going into daily use now with the working configuration and I don't really have a different machine at hand to reproduce this. The problem is that it takes up to two days to hit this bug... Hello Mike, Malc, others. So, has anything changed since qemu-kvm v.1.1 in this context of 44-vs-48 KHz audio frequency? Mike, did you try more recent version of qemu (2.1 currently)? Malc, did you do anything with this in the code between 1.1 and 2.1 versions, or do you know any changes which may affect this in the mentioned version-frame? No, I'm still using 1.1 (1.1.2+dfsg-6+deb7u5 on Debian 7) and had no issues since then. The system is in daily use, streaming from the soundcard on the host through the sound emulation on the guest for hours a day. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685353: qemu-kvm 1.1.1 hangs using 100% CPU when using ES1370 emulation
[ http://bugs.debian.org/685353 ] 05.09.2012 17:48, Mike Gerber wrote: [] Unfortunately I can't currently as this is going into daily use now with the working configuration and I don't really have a different machine at hand to reproduce this. The problem is that it takes up to two days to hit this bug... Michael: Maybe leave this bug open for others to find? For me, it's closed as a. I found a working configuration and b. I don't have the resources to triage the bug any further, unfortunately. (rehashing old bugrepots...) Hello Mike, Malc, others. So, has anything changed since qemu-kvm v.1.1 in this context of 44-vs-48 KHz audio frequency? Mike, did you try more recent version of qemu (2.1 currently)? Malc, did you do anything with this in the code between 1.1 and 2.1 versions, or do you know any changes which may affect this in the mentioned version-frame? Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685353: qemu-kvm 1.1.1 hangs using 100% CPU when using ES1370 emulation
Hi Vassily, Hi Michael,
* malc schrieb:
Audio compiled without optimzations which should give meaningful
backtrace and contents of local variables.
Here it is, (both host and guest had 48kHz capture sample rate). kvm.real
is the qemu-kvm binary, version 1.1.1, -O0.
0x7f18106dfb6e in st_rate_flow (opaque=0x7f1812c40550, ibuf=0x7f1812b41360,
obuf=0x7f1812b6b0e0, isamp=0x7fff8e3fe428, osamp=0x7fff8e3fe42c) at
/root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/audio/rate_template.h:73
73 rate-ipos++;
(gdb) info threads
Id Target Id Frame
2Thread 0x7f1804d1a700 (LWP 2157) kvm.real 0x7f180c833cec in
__lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0
* 1Thread 0x7f181055e8e0 (LWP 2156) kvm.real 0x7f18106dfb6e in
st_rate_flow (opaque=0x7f1812c40550, ibuf=0x7f1812b41360, obuf=0x7f1812b6b0e0,
isamp=0x7fff8e3fe428, osamp=0x7fff8e3fe42c) at
/root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/audio/rate_template.h:73
(gdb) thread apply all bt full
Thread 2 (Thread 0x7f1804d1a700 (LWP 2157)):
#0 0x7f180c833cec in __lll_lock_wait () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#1 0x7f180c82f339 in _L_lock_926 () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#2 0x7f180c82f15b in pthread_mutex_lock () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#3 0x7f181085be4f in qemu_mutex_lock (mutex=0x7f18115d3760) at
/root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/qemu-thread-posix.c:54
err = 0
__func__ = qemu_mutex_lock
#4 0x7f18108d95c8 in qemu_mutex_lock_iothread () at
/root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/cpus.c:897
No locals.
#5 0x7f1810910481 in kvm_cpu_exec (env=0x7f1812a4f520) at
/root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/kvm-all.c:1268
run = 0x7f1810654000
ret = 0
run_ret = 0
#6 0x7f18108d90fc in qemu_kvm_cpu_thread_fn (arg=0x7f1812a4f520) at
/root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/cpus.c:752
env = 0x7f1812a4f520
r = 65536
#7 0x7f180c82cb50 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#8 0x7f180c57770d in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#9 0x in ?? ()
No symbol table info available.
Thread 1 (Thread 0x7f181055e8e0 (LWP 2156)):
#0 0x7f18106dfb6e in st_rate_flow (opaque=0x7f1812c40550,
ibuf=0x7f1812b41360, obuf=0x7f1812b6b0e0, isamp=0x7fff8e3fe428,
osamp=0x7fff8e3fe42c) at
/root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/audio/rate_template.h:73
rate = 0x7f1812c40550
istart = 0x7f1812b1c340
iend = 0x7f1812b46bf0
ostart = 0x7f1812b6b0e0
oend = 0x7f1812b6b3a0
ilast = {l = 22085632, r = 111673344}
icur = {l = -12451840, r = -40763392}
out = {l = 4281343687, r = 139741334659632}
t = 3165658096
#1 0x7f18106d7e2f in audio_pcm_sw_read (sw=0x7f1812c3f160,
buf=0x7fff8e3fe5a0, size=4096) at
/root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/audio/audio.c:952
hw = 0x7f1812c28de0
samples = 1024
live = 15052
ret = 980
swlim = 44
isamp = 10891
osamp = 44
rpos = 0
total = -809300243
src = 0x7f1812b1c340
dst = 0x7f1812b6b0e0
__FUNCTION__ = audio_pcm_sw_read
#2 0x7f18106d5913 in alsa_read (sw=0x7f1812c3f160, buf=0x7fff8e3fe5a0,
size=4096) at /root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/audio/alsaaudio.c:1117
No locals.
#3 0x7f18106dabbd in AUD_read (sw=0x7f1812c3f160, buf=0x7fff8e3fe5a0,
size=4096) at /root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/audio/audio.c:1173
bytes = 4096
#4 0x7f18107a59e0 in es1370_transfer_audio (s=0x7f1812acb4a0,
d=0x7f1812acb9b8, loop_sel=32768, max=54560, irq=0x7fff8e3ff5fc) at
/root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/hw/es1370.c:803
acquired = 4096
to_copy = 4096
tmpbuf =
Bug#685353: qemu-kvm 1.1.1 hangs using 100% CPU when using ES1370 emulation
On Wed, 5 Sep 2012, Mike Gerber wrote:
Hi Vassily, Hi Michael,
* malc schrieb:
Audio compiled without optimzations which should give meaningful
backtrace and contents of local variables.
Here it is, (both host and guest had 48kHz capture sample rate). kvm.real
is the qemu-kvm binary, version 1.1.1, -O0.
To clarify things, i was under impression that you said that hang can not
be observed with 1:1 frequency? If this is the case how have you arrived
here to this state of things?
0x7f18106dfb6e in st_rate_flow (opaque=0x7f1812c40550,
ibuf=0x7f1812b41360, obuf=0x7f1812b6b0e0, isamp=0x7fff8e3fe428,
osamp=0x7fff8e3fe42c) at
/root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/audio/rate_template.h:73
73rate-ipos++;
(gdb) info threads
Id Target Id Frame
2Thread 0x7f1804d1a700 (LWP 2157) kvm.real 0x7f180c833cec in
__lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0
* 1Thread 0x7f181055e8e0 (LWP 2156) kvm.real 0x7f18106dfb6e in
st_rate_flow (opaque=0x7f1812c40550, ibuf=0x7f1812b41360,
obuf=0x7f1812b6b0e0, isamp=0x7fff8e3fe428, osamp=0x7fff8e3fe42c) at
/root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/audio/rate_template.h:73
(gdb) thread apply all bt full
Thread 2 (Thread 0x7f1804d1a700 (LWP 2157)):
#0 0x7f180c833cec in __lll_lock_wait () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#1 0x7f180c82f339 in _L_lock_926 () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#2 0x7f180c82f15b in pthread_mutex_lock () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#3 0x7f181085be4f in qemu_mutex_lock (mutex=0x7f18115d3760) at
/root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/qemu-thread-posix.c:54
err = 0
__func__ = qemu_mutex_lock
#4 0x7f18108d95c8 in qemu_mutex_lock_iothread () at
/root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/cpus.c:897
No locals.
#5 0x7f1810910481 in kvm_cpu_exec (env=0x7f1812a4f520) at
/root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/kvm-all.c:1268
run = 0x7f1810654000
ret = 0
run_ret = 0
#6 0x7f18108d90fc in qemu_kvm_cpu_thread_fn (arg=0x7f1812a4f520) at
/root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/cpus.c:752
env = 0x7f1812a4f520
r = 65536
#7 0x7f180c82cb50 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#8 0x7f180c57770d in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#9 0x in ?? ()
No symbol table info available.
Thread 1 (Thread 0x7f181055e8e0 (LWP 2156)):
#0 0x7f18106dfb6e in st_rate_flow (opaque=0x7f1812c40550,
ibuf=0x7f1812b41360, obuf=0x7f1812b6b0e0, isamp=0x7fff8e3fe428,
osamp=0x7fff8e3fe42c) at
/root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/audio/rate_template.h:73
rate = 0x7f1812c40550
istart = 0x7f1812b1c340
iend = 0x7f1812b46bf0
ostart = 0x7f1812b6b0e0
oend = 0x7f1812b6b3a0
ilast = {l = 22085632, r = 111673344}
icur = {l = -12451840, r = -40763392}
out = {l = 4281343687, r = 139741334659632}
t = 3165658096
#1 0x7f18106d7e2f in audio_pcm_sw_read (sw=0x7f1812c3f160,
buf=0x7fff8e3fe5a0, size=4096) at
/root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/audio/audio.c:952
hw = 0x7f1812c28de0
samples = 1024
live = 15052
ret = 980
swlim = 44
isamp = 10891
osamp = 44
rpos = 0
total = -809300243
^^ This is weird..
src = 0x7f1812b1c340
dst = 0x7f1812b6b0e0
__FUNCTION__ = audio_pcm_sw_read
set print pretty
p *hw
p *sw
if you can
#2 0x7f18106d5913 in alsa_read (sw=0x7f1812c3f160, buf=0x7fff8e3fe5a0,
size=4096) at /root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/audio/alsaaudio.c:1117
No locals.
#3 0x7f18106dabbd in AUD_read (sw=0x7f1812c3f160, buf=0x7fff8e3fe5a0,
size=4096) at /root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/audio/audio.c:1173
bytes = 4096
#4 0x7f18107a59e0 in es1370_transfer_audio (s=0x7f1812acb4a0,
d=0x7f1812acb9b8, loop_sel=32768, max=54560, irq=0x7fff8e3ff5fc) at
/root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/hw/es1370.c:803
acquired = 4096
to_copy = 4096
tmpbuf =
Bug#685353: qemu-kvm 1.1.1 hangs using 100% CPU when using ES1370 emulation
Hi, * malc schrieb: On Wed, 5 Sep 2012, Mike Gerber wrote: Here it is, (both host and guest had 48kHz capture sample rate). kvm.real is the qemu-kvm binary, version 1.1.1, -O0. To clarify things, i was under impression that you said that hang can not be observed with 1:1 frequency? If this is the case how have you arrived here to this state of things? Using 44.1kHz capture rate (h/g) the guest runs stable for at least three days (and I hope longer), using 48kHz (h/g) the kvm process hangs with 100% CPU within two days, predictably. I can't really tell if the darkice running on the guest sampling with 44.1kHz while the guest's hw_params capture rate is really 48kHz is somehow related to this bug. Or if a darkice/other software sampling at 48KHz would still trigger. guest darkice input sample rate:44.1 KHz 44.1 KHz guest darkice input device: default hw:0 host QEMU_ALSA_ADC_DEV: (unset) hw:0 capture sample rate host (according to hw_params): 48 KHz 44.1 KHz capture sample rate guest (according to hw_params): 48 KHz 44.1 KHz CRASH No crash, apparently The first three are configuration parameters I set (guest darkice.cfg and a wrapper script around kvm to set QEMU_ALSA_ADC_DEV), the capture sample rates are results of that configuration. ALSA configuration is unchanged from a Debian wheezy default install (no asoundrc in /etc or /root). #1 0x7f18106d7e2f in audio_pcm_sw_read (sw=0x7f1812c3f160, buf=0x7fff8e3fe5a0, size=4096) at /root/bug-mp3neu/qemu-kvm-1.1.1+dfsg/audio/audio.c:952 hw = 0x7f1812c28de0 samples = 1024 live = 15052 ret = 980 swlim = 44 isamp = 10891 osamp = 44 rpos = 0 total = -809300243 ^^ This is weird.. src = 0x7f1812b1c340 dst = 0x7f1812b6b0e0 __FUNCTION__ = audio_pcm_sw_read set print pretty p *hw p *sw if you can Unfortunately I can't currently as this is going into daily use now with the working configuration and I don't really have a different machine at hand to reproduce this. The problem is that it takes up to two days to hit this bug... Michael: Maybe leave this bug open for others to find? For me, it's closed as a. I found a working configuration and b. I don't have the resources to triage the bug any further, unfortunately. Thank you for your time, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685353: qemu-kvm 1.1.1 hangs using 100% CPU when using ES1370 emulation
On 30.08.2012 22:03, malc wrote: On Thu, 30 Aug 2012, Mike Gerber wrote: [] Vassily: Anything else you need when the hang happens again? Unfortunately I'll have to go into production with the guest, and I can't spend more weeks with this bug after this week end. Audio compiled without optimzations which should give meaningful backtrace and contents of local variables. Mike, are you able to do that? You can grab either the upstream qemu-kvm sources or debian sources, remove all -Oxx references or adding -O0, and recompile (`apt-get build-dep qemu-kvm' will install all necessary deps). Or I can compile it for you if you prefer. Indeed, with optimizations, while the stack trace is useful, it is not as useful as without... Michael: I noticed that this bug (#685353) is RC, so please rate it down if you think it is appropiate. I doubt that many people will hit it. It was you who marked this bug as grave, right? :) Yes it does not look like something many people will hit. Are you okay with downgrading it to normal or important ? Thanks! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685353: qemu-kvm 1.1.1 hangs using 100% CPU when using ES1370 emulation
retitle 685353 kvm process hangs with 100% CPU usage when using sound emulation severity 685353 normal thanks Hi Michael, * Michael Tokarev schrieb: On 30.08.2012 22:03, malc wrote: On Thu, 30 Aug 2012, Mike Gerber wrote: [] Vassily: Anything else you need when the hang happens again? Unfortunately I'll have to go into production with the guest, and I can't spend more weeks with this bug after this week end. Audio compiled without optimzations which should give meaningful backtrace and contents of local variables. Mike, are you able to do that? You can grab either the upstream qemu-kvm sources or debian sources, remove all -Oxx references or adding -O0, and recompile (`apt-get build-dep qemu-kvm' will install all necessary deps). I had to 1. Replace CFLAGS 2. Call configure with --enable-debug in debian/rules of the package to get rid of all -O2s. (Not sure what happens when you have both -O0 and -O2.) A test (full) backtrace didn't contain any optimized out values anymore, so I think this is OK. Or I can compile it for you if you prefer. Not necessary, but maybe you could consider adding a debug switch in debian/ rules to have the package built without optimizations. I'm somewhat familiar with customizing Debian packages, others maybe not. Michael: I noticed that this bug (#685353) is RC, so please rate it down if you think it is appropiate. I doubt that many people will hit it. It was you who marked this bug as grave, right? :) Yes, before I knew it was connected to excessive use of the sound emulation and weird sample rates :) Yes it does not look like something many people will hit. Are you okay with downgrading it to normal or important ? Yes, this email should do it. Thanks, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685353: qemu-kvm 1.1.1 hangs using 100% CPU when using ES1370 emulation
retitle 685353 kvm process hangs with 100% CPU usage when using sound emulation thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685353: qemu-kvm 1.1.1 hangs using 100% CPU when using ES1370 emulation
Hi, * malc schrieb: Question - what's the frequency that the emulated card is operated in (and what is the actual frequency host card provides)? The guest now survived 72 hours using 44.1khz capture rate on host guest, with the hda-intel emulation. Also runs stable for 72 hours using the es1370 emulation and 44.1 kHz sample rate on both host and guest. I will now run with 48 kHz by *not* setting QEMU_ALSA_ADC_DEV/QEMU_ALSA_DAC_DEV to hw:0 on the host and using device = default (instead of hw:0) in the guest's darkice.cfg. Still not sure what's resampling/happening here, as darkice is still streaming with 44.1kHz, but I guess it will hang the guest again within 2 days. I will then get the full values of *rate etc. Vassily: Anything else you need when the hang happens again? Unfortunately I'll have to go into production with the guest, and I can't spend more weeks with this bug after this week end. Michael: I noticed that this bug (#685353) is RC, so please rate it down if you think it is appropiate. I doubt that many people will hit it. Sample rates following, also notice the differences in format. host: # cat /proc/asound/card0/pcm0c/sub0/hw_params access: MMAP_INTERLEAVED format: S32_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 1024 buffer_size: 16384 guest: # cat /proc/asound/card0/pcm0c/sub0/hw_params access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (1411200/29) period_size: 1024 buffer_size: 16384 Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685353: qemu-kvm 1.1.1 hangs using 100% CPU when using ES1370 emulation
On Thu, 30 Aug 2012, Mike Gerber wrote: Hi, * malc schrieb: Question - what's the frequency that the emulated card is operated in (and what is the actual frequency host card provides)? The guest now survived 72 hours using 44.1khz capture rate on host guest, with the hda-intel emulation. Also runs stable for 72 hours using the es1370 emulation and 44.1 kHz sample rate on both host and guest. I will now run with 48 kHz by *not* setting QEMU_ALSA_ADC_DEV/QEMU_ALSA_DAC_DEV to hw:0 on the host and using device = default (instead of hw:0) in the guest's darkice.cfg. Still not sure what's resampling/happening here, as darkice is still streaming with 44.1kHz, but I guess it will hang the guest again within 2 days. I will then get the full values of *rate etc. Vassily: Anything else you need when the hang happens again? Unfortunately I'll have to go into production with the guest, and I can't spend more weeks with this bug after this week end. Audio compiled without optimzations which should give meaningful backtrace and contents of local variables. Michael: I noticed that this bug (#685353) is RC, so please rate it down if you think it is appropiate. I doubt that many people will hit it. Sample rates following, also notice the differences in format. host: # cat /proc/asound/card0/pcm0c/sub0/hw_params access: MMAP_INTERLEAVED format: S32_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 1024 buffer_size: 16384 guest: # cat /proc/asound/card0/pcm0c/sub0/hw_params access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (1411200/29) period_size: 1024 buffer_size: 16384 Mike -- mailto:av1...@comtv.ru -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685353: qemu-kvm 1.1.1 hangs using 100% CPU when using ES1370 emulation
Hi, * malc schrieb: Question - what's the frequency that the emulated card is operated in (and what is the actual frequency host card provides)? The guest now survived 72 hours using 44.1khz capture rate on host guest, with the hda-intel emulation. # cat /proc/asound/card0/pcm0c/sub0/hw_params access: RW_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 44100 (44100/1) period_size: 4096 buffer_size: 16384 So I consider this configuration stable. Now I'm going back to ES1370 emulation, and see if that runs stable with 44.1kHz. Thanks for the tip! Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685353: qemu-kvm 1.1.1 hangs using 100% CPU when using ES1370 emulation
Hi Michael, Vassili, * Michael Tokarev schrieb: Can you also check whenever hda emulated device also shows this issue? I'm now using sound model='ich6' alias name='sound0'/ address type='pci' domain='0x' bus='0x00' slot='0x06' function='0x0'/ /sound which libvirt is translating to: -device intel-hda,id=sound0,bus=pci.0,addr=0x6 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 I'll wait if that brings any improvement. (For now I get a bad IRQ in dmesg, but audio input works. Might deal with that later.) Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685353: qemu-kvm 1.1.1 hangs using 100% CPU when using ES1370 emulation
Hi, again,
(gdb) step
73 in /tmp/buildd/qemu-kvm-1.1.1+dfsg/audio/rate_template.h
(gdb)
75 in /tmp/buildd/qemu-kvm-1.1.1+dfsg/audio/rate_template.h
Btw, I started another gdb session today, before switching to ich6. qemu-kvm is
apparently looping here in rate_template.h because of those values (different
gdb session):
(gdb)
71while (rate-ipos = (rate-opos 32)) {
(gdb)
72ilast = *ibuf++;
(gdb)
73rate-ipos++;
(gdb)
75if (ibuf = iend) {
(gdb)
73rate-ipos++;
(gdb)
75if (ibuf = iend) {
(gdb)
71while (rate-ipos = (rate-opos 32)) {
(gdb) print rate-ipos
$1 = 1127898092
(gdb) print rate-opos 32
$2 = 4294967295
Mike
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685353: qemu-kvm 1.1.1 hangs using 100% CPU when using ES1370 emulation
[Removing kvm@ from Cc, adding bugs.debian.org.) * malc schrieb: [..snip..] It's also (appears) to be in the chunk of code written by Fabrice not me. Last comment at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685353 doesn't include a backtrace. To be honest I didn't do a backtrace for that new gdb session, but I suspect it must be the same as in the comments above. I'll see if the guest survives more than 48 hours with hda-intel, then go back again to es1370 to get another full backtrace and the i/opos values. Question - what's the frequency that the emulated card is operated in (and what is the actual frequency host card provides)? I can't check it sanely right now as I am testing with hda-intel, but will check again after switching back to es1370. (FWIW right now for hda-intel it *was* 48kHz for both host and guest according to /proc/asound, which is wrong, as darkice should be using 44.1kHz. Setting the capture device to hw:0 using QEMU_AUDIO_ADC_DEV and in darkice.cfg changed it to 44.1kHz in both host and guest according to /proc/asound. I will check es1370 with these settings. I have *no* idea what part of ALSA/qemu/darkice was resampling here or not.) Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685353: qemu-kvm 1.1.1 hangs using 100% CPU when using ES1370 emulation
* malc schrieb: What does p *rate yield? (i.e. other fields of rate are of interest too) I'll check that too, back on es1370, will take a few days of waiting. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685353: qemu-kvm 1.1.1 hangs using 100% CPU when using ES1370 emulation
On Fri, 24 Aug 2012, Mike Gerber wrote:
Hi, again,
(gdb) step
73 in /tmp/buildd/qemu-kvm-1.1.1+dfsg/audio/rate_template.h
(gdb)
75 in /tmp/buildd/qemu-kvm-1.1.1+dfsg/audio/rate_template.h
Btw, I started another gdb session today, before switching to ich6. qemu-kvm
is
apparently looping here in rate_template.h because of those values (different
gdb session):
(gdb)
71while (rate-ipos = (rate-opos 32)) {
(gdb)
72ilast = *ibuf++;
(gdb)
73rate-ipos++;
(gdb)
75if (ibuf = iend) {
(gdb)
73rate-ipos++;
(gdb)
75if (ibuf = iend) {
(gdb)
71while (rate-ipos = (rate-opos 32)) {
(gdb) print rate-ipos
$1 = 1127898092
(gdb) print rate-opos 32
$2 = 4294967295
What does p *rate yield? (i.e. other fields of rate are of
interest too)
--
mailto:av1...@comtv.ru
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
