FYI... We have a user who''s 64-bit Windows 2k8 guest consistently cores qemu-dm with the latest qemu-3.4-testing.git bits. I haven''t been able to reproduce it with Linux (HVM), Solaris(HVM), or a 64-bit Windows 2k8 guest. Not sure what''s different about his guest. I was able to have him backout the recent changes pushed on 10/20 (with no other changes) and his guest no longer crashes... Anyone else seeing similar problems? MRJ pstack /var/cores/core.qemu-dm.8061 core ''/var/cores/core.qemu-dm.8061'' of 8061: /usr/lib/xen/bin/qemu-dm -d 7 -domain-name titan -videoram 4 -k de -vn ----------------- lwp# 1 / thread# 1 -------------------- 000000000094a640 ???????? () 000000000046d5a2 main_loop_wait () + 2e2 00000000004ceb6a main_loop () + ba 000000000046f3db main () + 1bdb 0000000000469f9c _start () + 6c ----------------- lwp# 2 / thread# 2 -------------------- 00007fffff23bd1a __read () + a 00007ffffe1b3306 read_all () + 26 00007ffffe1b35d8 read_message () + 48 00007ffffe1b45f8 read_thread () + 18 00007fffff232b34 _thrp_setup () + bc 00007fffff232df0 _lwp_start () ----------------- lwp# 3 / thread# 3 -------------------- 00007fffff232e37 __lwp_park () + 17 00007fffff22c1e0 cond_wait_queue () + 68 00007fffff22c649 cond_wait_common () + 1e1 00007fffff22c903 __cond_timedwait () + ab 00007fffff22c94f cond_timedwait () + 27 00007fffff22c981 pthread_cond_timedwait () + 9 00000000004782e8 aio_thread () + 178 00007fffff232b34 _thrp_setup () + bc 00007fffff232df0 _lwp_start ()> mdb /var/cores/core.qemu-dm.7331Loading modules: [ libc.so.1 ld.so.1 ]> > $c0x94a640() main_loop_wait+0x2e2() main_loop+0xba() main+0x1bdb() _start+0x6c()> > $q_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefano or IanJ may have some ideas. At least not *that* many patches have been applied to qemu. -- Keir On 22/10/2009 21:14, "Mark Johnson" <johnson.nh@gmail.com> wrote:> FYI... > > We have a user who''s 64-bit Windows 2k8 guest consistently > cores qemu-dm with the latest qemu-3.4-testing.git bits. > I haven''t been able to reproduce it with Linux (HVM), Solaris(HVM), or a > 64-bit Windows 2k8 guest. Not sure what''s different about his guest. > > I was able to have him backout the recent changes pushed on 10/20 > (with no other changes) and his guest no longer crashes... > > Anyone else seeing similar problems? > > > > MRJ > > > > pstack /var/cores/core.qemu-dm.8061 > core ''/var/cores/core.qemu-dm.8061'' of 8061: /usr/lib/xen/bin/qemu-dm > -d 7 -domain-name titan -videoram 4 -k de -vn > ----------------- lwp# 1 / thread# 1 -------------------- > 000000000094a640 ???????? () > 000000000046d5a2 main_loop_wait () + 2e2 > 00000000004ceb6a main_loop () + ba > 000000000046f3db main () + 1bdb > 0000000000469f9c _start () + 6c > ----------------- lwp# 2 / thread# 2 -------------------- > 00007fffff23bd1a __read () + a > 00007ffffe1b3306 read_all () + 26 > 00007ffffe1b35d8 read_message () + 48 > 00007ffffe1b45f8 read_thread () + 18 > 00007fffff232b34 _thrp_setup () + bc > 00007fffff232df0 _lwp_start () > ----------------- lwp# 3 / thread# 3 -------------------- > 00007fffff232e37 __lwp_park () + 17 > 00007fffff22c1e0 cond_wait_queue () + 68 > 00007fffff22c649 cond_wait_common () + 1e1 > 00007fffff22c903 __cond_timedwait () + ab > 00007fffff22c94f cond_timedwait () + 27 > 00007fffff22c981 pthread_cond_timedwait () + 9 > 00000000004782e8 aio_thread () + 178 > 00007fffff232b34 _thrp_setup () + bc > 00007fffff232df0 _lwp_start () > > >> mdb /var/cores/core.qemu-dm.7331 > > Loading modules: [ libc.so.1 ld.so.1 ] >>> $c > 0x94a640() > main_loop_wait+0x2e2() > main_loop+0xba() > main+0x1bdb() > _start+0x6c() >>> $q > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mark Johnson writes ("[Xen-devel] qemu-3.4-testing
problems..."):> We have a user who''s 64-bit Windows 2k8 guest consistently
> cores qemu-dm with the latest qemu-3.4-testing.git bits.
> I haven''t been able to reproduce it with Linux (HVM),
Solaris(HVM), or a
> 64-bit Windows 2k8 guest. Not sure what''s different about his
guest.
>
> I was able to have him backout the recent changes pushed on 10/20
> (with no other changes) and his guest no longer crashes...
`10/20'' presumably means 20th October. Those are mostly the backports
of block driver changes from upstream. They''re not really bisectable
but I think we should be able to debug it.
You''re using a Linux host I take it ? Could you please compile your
qemu-dm with -g and unstrupped and use gdb to print sensible stack
traces (with line numbers and so on) ? I think I should be able to
tell what''s going on if you can get me a good backtrace ?
If you''re not sure how to do that I''ll give detailed
instructions.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On Fri, Oct 23, 2009 at 10:35 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:> Mark Johnson writes ("[Xen-devel] qemu-3.4-testing problems..."): >> We have a user who''s 64-bit Windows 2k8 guest consistently >> cores qemu-dm with the latest qemu-3.4-testing.git bits. >> I haven''t been able to reproduce it with Linux (HVM), Solaris(HVM), or a >> 64-bit Windows 2k8 guest. Not sure what''s different about his guest. >> >> I was able to have him backout the recent changes pushed on 10/20 >> (with no other changes) and his guest no longer crashes... > > `10/20'' presumably means 20th October.Yes, sorry.> Those are mostly the backports > of block driver changes from upstream. They''re not really bisectable > but I think we should be able to debug it.Yes.. He''s seeing it on a block (SAN) device btw.> You''re using a Linux host I take it ? Could you please compile your > qemu-dm with -g and unstrupped and use gdb to print sensible stack > traces (with line numbers and so on) ? I think I should be able to > tell what''s going on if you can get me a good backtrace ? > > If you''re not sure how to do that I''ll give detailed instructions.Nope, Solaris. :-) I''ll be able to chase it down (on vacation today though). My e-mail was a FYI for other folks to keep an eye out for it.. We don''t (shouldn''t) have any changes in these code paths.. But it could something ifdef linux vs not specific? MRJ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mark Johnson writes ("Re: [Xen-devel] qemu-3.4-testing
problems..."):> On Fri, Oct 23, 2009 at 10:35 AM, Ian Jackson
<Ian.Jackson@eu.citrix.com> wrote:
> > You''re using a Linux host I take it ? Could you please
compile your
> > qemu-dm with -g and unstrupped and use gdb to print sensible stack
> > traces (with line numbers and so on) ? I think I should be able to
> > tell what''s going on if you can get me a good backtrace ?
> >
> > If you''re not sure how to do that I''ll give detailed
instructions.
>
> Nope, Solaris. :-) I''ll be able to chase it down (on vacation
today
> though).
Oh, good. I''m not sure what instructions to give for Solaris.
But a better stack trace would definitely help a lot.
> My e-mail was a FYI for other folks to keep an eye out for it..
> We don''t (shouldn''t) have any changes in these code
paths.. But
> it could something ifdef linux vs not specific?
This is quite possible.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel