[Qemu-devel] [Bug 1412098] [NEW] qemu crashes when ctrl-alt-u is pressed

[Qemu-devel] [Bug 1412098] [NEW] qemu crashes when ctrl-alt-u is pressed

[Legorol]

Public bug reported:

Qemu version: 2.2.0 release, compiled from source
Host OS: Windows 7 Ultimate x64
Guest OS: not applicable, crash occurs even without OS and occurs with all OSs
Executable: qemu-system-i386.exe or qemu-system-i386w.exe

To reproduce:
Start qemu-system-i386 or qemu-system-i386w without any options. Press CTRL-ALT-U, which is supposed to rescale the window. Instead, qemu just crashes.

Compilation:
Qemu 2.2.0 release compiled from sources under MinGW on the host.
Configure options used:
'../qemu-2.2.0/configure' '--python=C:/Python27/python' '--prefix=/mingw/build/qemu-2.2.0-bin' '--target-list=i386-softmmu'

** Affects: qemu
     Importance: Undecided
         Status: New

** Attachment added: "report of configure options used for compilation"
   https://bugs.launchpad.net/bugs/1412098/+attachment/4300920/+files/config.options

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1412098

Title:
  qemu crashes when ctrl-alt-u is pressed

Status in QEMU:
  New

Bug description:
  Qemu version: 2.2.0 release, compiled from source
  Host OS: Windows 7 Ultimate x64
  Guest OS: not applicable, crash occurs even without OS and occurs with all OSs
  Executable: qemu-system-i386.exe or qemu-system-i386w.exe

  To reproduce:
  Start qemu-system-i386 or qemu-system-i386w without any options. Press CTRL-ALT-U, which is supposed to rescale the window. Instead, qemu just crashes.

  Compilation:
  Qemu 2.2.0 release compiled from sources under MinGW on the host.
  Configure options used:
  '../qemu-2.2.0/configure' '--python=C:/Python27/python' '--prefix=/mingw/build/qemu-2.2.0-bin' '--target-list=i386-softmmu'

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1412098/+subscriptions

[Qemu-devel] Windows 2008 Guest BSODS with CLOCK_WATCHDOG_TIMEOUT on VM migration

[Mikhail Sennikovskii]

Hi all,

I'm running a slitely modified migration over tcp test in virt-test, 
which does a migration from one "smp=2" VM to another on the same host 
over TCP,
and exposes some dummy CPU load inside the GUEST while migration, and 
after a series of runs I'm alwais getting a CLOCK_WATCHDOG_TIMEOUT BSOD 
inside the guest,
which happens when
"
An expected clock interrupt was not received on a secondary processor in an
MP system within the allocated interval. This indicates that the specified
processor is hung and not processing interrupts.
"

This seems to happen with any qemu version I've tested (1.2 and above, 
including upstream),
and I was testing it with 3.13.0-44-generic kernel on my Ubuntu 14.04.1 
LTS with SMP4 host, as well as on 3.12.26-1 kernel with Debian 6 with 
SMP6 host.

One thing I noticed is that exposing a dummy CPU load on the HOST (like 
running multiple instances of the "while true; do false; done" script) 
in parallel with doing migration makes the issue to be quite easily 
reproducible.


Looking inside the windows crash dump, the second CPU is just running at 
IRQL 0, and it aparently not hung, as Windows is able to save its state 
in the crash dump correctly, which assumes running some code on it.
So this aparently seems to be some timing issue (like host scheduler 
does not schedule the thread executing secondary CPU's code in time).

Could you give me some insight on this, i.e. is there a way to customize 
QEMU/KVM to avoid such issue?

If you think this might be a qemu/kvm issue, I can provide you any info, 
like windows crash dumps, or the test-case to reproduce this.


qemu is started as:

from-VM:

qemu-system-x86_64 \
     -S  \
     -name 'virt-tests-vm1'  \
     -sandbox off  \
     -M pc-1.0  \
     -nodefaults  \
     -vga std  \
     -chardev 
socket,id=qmp_id_qmp1,path=/tmp/monitor-qmp1-20150123-112624-aFZmIkNT,server,nowait 
\
     -mon chardev=qmp_id_qmp1,mode=control  \
     -chardev 
socket,id=serial_id_serial0,path=/tmp/serial-serial0-20150123-112624-aFZmIkNT,server,nowait 
\
     -device isa-serial,chardev=serial_id_serial0  \
     -chardev 
socket,id=seabioslog_id_20150123-112624-aFZmIkNT,path=/tmp/seabios-20150123-112624-aFZmIkNT,server,nowait 
\
     -device 
isa-debugcon,chardev=seabioslog_id_20150123-112624-aFZmIkNT,iobase=0x402 \
     -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=03 \
     -drive id=drive_image1,if=none,file=/path/to/image.qcow2 \
     -device 
virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=04 \
     -device 
virtio-net-pci,mac=9a:74:75:76:77:78,id=idFdaC4M,vectors=4,netdev=idKFZNXH,bus=pci.0,addr=05 
\
     -netdev 
user,id=idKFZNXH,hostfwd=tcp::5000-:22,hostfwd=tcp::5001-:10023  \
     -m 2G  \
     -smp 2,maxcpus=2,cores=1,threads=1,sockets=2  \
     -cpu phenom \
     -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
     -vnc :0  \
     -rtc base=localtime,clock=host,driftfix=none  \
     -boot order=cdn,once=c,menu=off \
     -enable-kvm

to-VM:

qemu-system-x86_64 \
     -S  \
     -name 'virt-tests-vm1'  \
     -sandbox off  \
     -M pc-1.0  \
     -nodefaults  \
     -vga std  \
     -chardev 
socket,id=qmp_id_qmp1,path=/tmp/monitor-qmp1-20150123-112750-VehjvEqK,server,nowait 
\
     -mon chardev=qmp_id_qmp1,mode=control  \
     -chardev 
socket,id=serial_id_serial0,path=/tmp/serial-serial0-20150123-112750-VehjvEqK,server,nowait 
\
     -device isa-serial,chardev=serial_id_serial0  \
     -chardev 
socket,id=seabioslog_id_20150123-112750-VehjvEqK,path=/tmp/seabios-20150123-112750-VehjvEqK,server,nowait 
\
     -device 
isa-debugcon,chardev=seabioslog_id_20150123-112750-VehjvEqK,iobase=0x402 \
     -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=03 \
     -drive id=drive_image1,if=none,file=/path/to/image.qcow2 \
     -device 
virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=04 \
     -device 
virtio-net-pci,mac=9a:74:75:76:77:78,id=idI46M9C,vectors=4,netdev=idl9vRQt,bus=pci.0,addr=05 
\
     -netdev 
user,id=idl9vRQt,hostfwd=tcp::5002-:22,hostfwd=tcp::5003-:10023  \
     -m 2G  \
     -smp 2,maxcpus=2,cores=1,threads=1,sockets=2  \
     -cpu phenom \
     -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
     -vnc :1  \
     -rtc base=localtime,clock=host,driftfix=none  \
     -boot order=cdn,once=c,menu=off \
     -enable-kvm \
     -incoming tcp:0:5200


Thanks,
Mikhail

Windows 2008 Guest BSODS with CLOCK_WATCHDOG_TIMEOUT on VM migration

[Mikhail Sennikovskii]

Hi all,

I've posted the bolow mail to the qemu-dev mailing list, but I've got no 
response there.
That's why I decided to re-post it here as well, and besides that I 
think this could be a kvm-specific issue as well.

Some additional thing to note:
I can reproduce the issue on my Debian 7 with 3.16.0-0.bpo.4-amd64 
kernel as well.
I would typically use a max_downtime adjusted to 1 second instead of 
default 30 ms.
I also noticed that the issue happens much more rarelly if I increase 
the migration bandwidth, i.e. like

diff --git a/migration.c b/migration.c
index 26f4b65..d2e3b39 100644
--- a/migration.c
+++ b/migration.c
@@ -36,7 +36,7 @@ enum {
      MIG_STATE_COMPLETED,
  };

-#define MAX_THROTTLE  (32 << 20)      /* Migration speed throttling */
+#define MAX_THROTTLE  (90 << 20)      /* Migration speed throttling */

Like I said below, I would be glad to provide you with any additional 
information.

Thanks,
Mikhail

On 23.01.2015 15:03, Mikhail Sennikovskii wrote:
> Hi all,
>
> I'm running a slitely modified migration over tcp test in virt-test, 
> which does a migration from one "smp=2" VM to another on the same host 
> over TCP,
> and exposes some dummy CPU load inside the GUEST while migration, and 
> after a series of runs I'm alwais getting a CLOCK_WATCHDOG_TIMEOUT 
> BSOD inside the guest,
> which happens when
> "
> An expected clock interrupt was not received on a secondary processor 
> in an
> MP system within the allocated interval. This indicates that the 
> specified
> processor is hung and not processing interrupts.
> "
>
> This seems to happen with any qemu version I've tested (1.2 and above, 
> including upstream),
> and I was testing it with 3.13.0-44-generic kernel on my Ubuntu 
> 14.04.1 LTS with SMP4 host, as well as on 3.12.26-1 kernel with Debian 
> 6 with SMP6 host.
>
> One thing I noticed is that exposing a dummy CPU load on the HOST 
> (like running multiple instances of the "while true; do false; done" 
> script) in parallel with doing migration makes the issue to be quite 
> easily reproducible.
>
>
> Looking inside the windows crash dump, the second CPU is just running 
> at IRQL 0, and it aparently not hung, as Windows is able to save its 
> state in the crash dump correctly, which assumes running some code on it.
> So this aparently seems to be some timing issue (like host scheduler 
> does not schedule the thread executing secondary CPU's code in time).
>
> Could you give me some insight on this, i.e. is there a way to 
> customize QEMU/KVM to avoid such issue?
>
> If you think this might be a qemu/kvm issue, I can provide you any 
> info, like windows crash dumps, or the test-case to reproduce this.
>
>
> qemu is started as:
>
> from-VM:
>
> qemu-system-x86_64 \
>     -S  \
>     -name 'virt-tests-vm1'  \
>     -sandbox off  \
>     -M pc-1.0  \
>     -nodefaults  \
>     -vga std  \
>     -chardev 
> socket,id=qmp_id_qmp1,path=/tmp/monitor-qmp1-20150123-112624-aFZmIkNT,server,nowait 
> \
>     -mon chardev=qmp_id_qmp1,mode=control  \
>     -chardev 
> socket,id=serial_id_serial0,path=/tmp/serial-serial0-20150123-112624-aFZmIkNT,server,nowait 
> \
>     -device isa-serial,chardev=serial_id_serial0  \
>     -chardev 
> socket,id=seabioslog_id_20150123-112624-aFZmIkNT,path=/tmp/seabios-20150123-112624-aFZmIkNT,server,nowait 
> \
>     -device 
> isa-debugcon,chardev=seabioslog_id_20150123-112624-aFZmIkNT,iobase=0x402 
> \
>     -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=03 \
>     -drive id=drive_image1,if=none,file=/path/to/image.qcow2 \
>     -device 
> virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=04 
> \
>     -device 
> virtio-net-pci,mac=9a:74:75:76:77:78,id=idFdaC4M,vectors=4,netdev=idKFZNXH,bus=pci.0,addr=05 
> \
>     -netdev 
> user,id=idKFZNXH,hostfwd=tcp::5000-:22,hostfwd=tcp::5001-:10023  \
>     -m 2G  \
>     -smp 2,maxcpus=2,cores=1,threads=1,sockets=2  \
>     -cpu phenom \
>     -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
>     -vnc :0  \
>     -rtc base=localtime,clock=host,driftfix=none  \
>     -boot order=cdn,once=c,menu=off \
>     -enable-kvm
>
> to-VM:
>
> qemu-system-x86_64 \
>     -S  \
>     -name 'virt-tests-vm1'  \
>     -sandbox off  \
>     -M pc-1.0  \
>     -nodefaults  \
>     -vga std  \
>     -chardev 
> socket,id=qmp_id_qmp1,path=/tmp/monitor-qmp1-20150123-112750-VehjvEqK,server,nowait 
> \
>     -mon chardev=qmp_id_qmp1,mode=control  \
>     -chardev 
> socket,id=serial_id_serial0,path=/tmp/serial-serial0-20150123-112750-VehjvEqK,server,nowait 
> \
>     -device isa-serial,chardev=serial_id_serial0  \
>     -chardev 
> socket,id=seabioslog_id_20150123-112750-VehjvEqK,path=/tmp/seabios-20150123-112750-VehjvEqK,server,nowait 
> \
>     -device 
> isa-debugcon,chardev=seabioslog_id_20150123-112750-VehjvEqK,iobase=0x402 
> \
>     -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=03 \
>     -drive id=drive_image1,if=none,file=/path/to/image.qcow2 \
>     -device 
> virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=04 
> \
>     -device 
> virtio-net-pci,mac=9a:74:75:76:77:78,id=idI46M9C,vectors=4,netdev=idl9vRQt,bus=pci.0,addr=05 
> \
>     -netdev 
> user,id=idl9vRQt,hostfwd=tcp::5002-:22,hostfwd=tcp::5003-:10023  \
>     -m 2G  \
>     -smp 2,maxcpus=2,cores=1,threads=1,sockets=2  \
>     -cpu phenom \
>     -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
>     -vnc :1  \
>     -rtc base=localtime,clock=host,driftfix=none  \
>     -boot order=cdn,once=c,menu=off \
>     -enable-kvm \
>     -incoming tcp:0:5200
>
>
> Thanks,
> Mikhail

Re: Windows 2008 Guest BSODS with CLOCK_WATCHDOG_TIMEOUT on VM migration

[Jidong Xiao]

On Tue, Jan 27, 2015 at 5:55 AM, Mikhail Sennikovskii
<mikhail.sennikovskii@profitbricks.com> wrote:
> Hi all,
>
> I've posted the bolow mail to the qemu-dev mailing list, but I've got no
> response there.
> That's why I decided to re-post it here as well, and besides that I think
> this could be a kvm-specific issue as well.
>
> Some additional thing to note:
> I can reproduce the issue on my Debian 7 with 3.16.0-0.bpo.4-amd64 kernel as
> well.
> I would typically use a max_downtime adjusted to 1 second instead of default
> 30 ms.
> I also noticed that the issue happens much more rarelly if I increase the
> migration bandwidth, i.e. like
>
> diff --git a/migration.c b/migration.c
> index 26f4b65..d2e3b39 100644
> --- a/migration.c
> +++ b/migration.c
> @@ -36,7 +36,7 @@ enum {
>      MIG_STATE_COMPLETED,
>  };
>
> -#define MAX_THROTTLE  (32 << 20)      /* Migration speed throttling */
> +#define MAX_THROTTLE  (90 << 20)      /* Migration speed throttling */
>
> Like I said below, I would be glad to provide you with any additional
> information.
>
> Thanks,
> Mikhail
>
Hi, Mikhail,

So if you choose to use one vcpu, instead of smp, this issue would not
happen, right?

-Jidong

> On 23.01.2015 15:03, Mikhail Sennikovskii wrote:
>>
>> Hi all,
>>
>> I'm running a slitely modified migration over tcp test in virt-test, which
>> does a migration from one "smp=2" VM to another on the same host over TCP,
>> and exposes some dummy CPU load inside the GUEST while migration, and
>> after a series of runs I'm alwais getting a CLOCK_WATCHDOG_TIMEOUT BSOD
>> inside the guest,
>> which happens when
>> "
>> An expected clock interrupt was not received on a secondary processor in
>> an
>> MP system within the allocated interval. This indicates that the specified
>> processor is hung and not processing interrupts.
>> "
>>
>> This seems to happen with any qemu version I've tested (1.2 and above,
>> including upstream),
>> and I was testing it with 3.13.0-44-generic kernel on my Ubuntu 14.04.1
>> LTS with SMP4 host, as well as on 3.12.26-1 kernel with Debian 6 with SMP6
>> host.
>>
>> One thing I noticed is that exposing a dummy CPU load on the HOST (like
>> running multiple instances of the "while true; do false; done" script) in
>> parallel with doing migration makes the issue to be quite easily
>> reproducible.
>>
>>
>> Looking inside the windows crash dump, the second CPU is just running at
>> IRQL 0, and it aparently not hung, as Windows is able to save its state in
>> the crash dump correctly, which assumes running some code on it.
>> So this aparently seems to be some timing issue (like host scheduler does
>> not schedule the thread executing secondary CPU's code in time).
>>
>> Could you give me some insight on this, i.e. is there a way to customize
>> QEMU/KVM to avoid such issue?
>>
>> If you think this might be a qemu/kvm issue, I can provide you any info,
>> like windows crash dumps, or the test-case to reproduce this.
>>
>>
>> qemu is started as:
>>
>> from-VM:
>>
>> qemu-system-x86_64 \
>>     -S  \
>>     -name 'virt-tests-vm1'  \
>>     -sandbox off  \
>>     -M pc-1.0  \
>>     -nodefaults  \
>>     -vga std  \
>>     -chardev
>> socket,id=qmp_id_qmp1,path=/tmp/monitor-qmp1-20150123-112624-aFZmIkNT,server,nowait
>> \
>>     -mon chardev=qmp_id_qmp1,mode=control  \
>>     -chardev
>> socket,id=serial_id_serial0,path=/tmp/serial-serial0-20150123-112624-aFZmIkNT,server,nowait
>> \
>>     -device isa-serial,chardev=serial_id_serial0  \
>>     -chardev
>> socket,id=seabioslog_id_20150123-112624-aFZmIkNT,path=/tmp/seabios-20150123-112624-aFZmIkNT,server,nowait
>> \
>>     -device
>> isa-debugcon,chardev=seabioslog_id_20150123-112624-aFZmIkNT,iobase=0x402 \
>>     -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=03 \
>>     -drive id=drive_image1,if=none,file=/path/to/image.qcow2 \
>>     -device
>> virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=04 \
>>     -device
>> virtio-net-pci,mac=9a:74:75:76:77:78,id=idFdaC4M,vectors=4,netdev=idKFZNXH,bus=pci.0,addr=05
>> \
>>     -netdev
>> user,id=idKFZNXH,hostfwd=tcp::5000-:22,hostfwd=tcp::5001-:10023  \
>>     -m 2G  \
>>     -smp 2,maxcpus=2,cores=1,threads=1,sockets=2  \
>>     -cpu phenom \
>>     -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
>>     -vnc :0  \
>>     -rtc base=localtime,clock=host,driftfix=none  \
>>     -boot order=cdn,once=c,menu=off \
>>     -enable-kvm
>>
>> to-VM:
>>
>> qemu-system-x86_64 \
>>     -S  \
>>     -name 'virt-tests-vm1'  \
>>     -sandbox off  \
>>     -M pc-1.0  \
>>     -nodefaults  \
>>     -vga std  \
>>     -chardev
>> socket,id=qmp_id_qmp1,path=/tmp/monitor-qmp1-20150123-112750-VehjvEqK,server,nowait
>> \
>>     -mon chardev=qmp_id_qmp1,mode=control  \
>>     -chardev
>> socket,id=serial_id_serial0,path=/tmp/serial-serial0-20150123-112750-VehjvEqK,server,nowait
>> \
>>     -device isa-serial,chardev=serial_id_serial0  \
>>     -chardev
>> socket,id=seabioslog_id_20150123-112750-VehjvEqK,path=/tmp/seabios-20150123-112750-VehjvEqK,server,nowait
>> \
>>     -device
>> isa-debugcon,chardev=seabioslog_id_20150123-112750-VehjvEqK,iobase=0x402 \
>>     -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=03 \
>>     -drive id=drive_image1,if=none,file=/path/to/image.qcow2 \
>>     -device
>> virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=04 \
>>     -device
>> virtio-net-pci,mac=9a:74:75:76:77:78,id=idI46M9C,vectors=4,netdev=idl9vRQt,bus=pci.0,addr=05
>> \
>>     -netdev
>> user,id=idl9vRQt,hostfwd=tcp::5002-:22,hostfwd=tcp::5003-:10023  \
>>     -m 2G  \
>>     -smp 2,maxcpus=2,cores=1,threads=1,sockets=2  \
>>     -cpu phenom \
>>     -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
>>     -vnc :1  \
>>     -rtc base=localtime,clock=host,driftfix=none  \
>>     -boot order=cdn,once=c,menu=off \
>>     -enable-kvm \
>>     -incoming tcp:0:5200
>>
>>
>> Thanks,
>> Mikhail
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Windows 2008 Guest BSODS with CLOCK_WATCHDOG_TIMEOUT on VM migration

[Zhang Haoyu]

On 2015-01-28 03:10:23, Jidong Xiao wrote:
> On Tue, Jan 27, 2015 at 5:55 AM, Mikhail Sennikovskii
> <mikhail.sennikovskii@profitbricks.com> wrote:
> > Hi all,
>>
> > I've posted the bolow mail to the qemu-dev mailing list, but I've got no
> > response there.
> > That's why I decided to re-post it here as well, and besides that I think
> > this could be a kvm-specific issue as well.
> >
> > Some additional thing to note:
> > I can reproduce the issue on my Debian 7 with 3.16.0-0.bpo.4-amd64 kernel as
> > well.
> > I would typically use a max_downtime adjusted to 1 second instead of default
> > 30 ms.
> > I also noticed that the issue happens much more rarelly if I increase the
> > migration bandwidth, i.e. like
> >
> > diff --git a/migration.c b/migration.c
> > index 26f4b65..d2e3b39 100644
>> --- a/migration.c
> > +++ b/migration.c
> > @@ -36,7 +36,7 @@ enum {
> >      MIG_STATE_COMPLETED,
> >  };
> >
> > -#define MAX_THROTTLE  (32 << 20)      /* Migration speed throttling */
> > +#define MAX_THROTTLE  (90 << 20)      /* Migration speed throttling */
> >
> > Like I said below, I would be glad to provide you with any additional
> > information.
> >
> > Thanks,
> > Mikhail
> >
> Hi, Mikhail,
>
> So if you choose to use one vcpu, instead of smp, this issue would not
> happen, right?
> 
I think you can try cpu feature hv_relaxed, like
-cpu Haswell,hv_relaxed

> -Jidong
> 
> > On 23.01.2015 15:03, Mikhail Sennikovskii wrote:
> >>
> >> Hi all,
> >>
> >> I'm running a slitely modified migration over tcp test in virt-test, which
> >> does a migration from one "smp=2" VM to another on the same host over TCP,
> >> and exposes some dummy CPU load inside the GUEST while migration, and
> >> after a series of runs I'm alwais getting a CLOCK_WATCHDOG_TIMEOUT BSOD
> >> inside the guest,
> >> which happens when
>>> "
> >> An expected clock interrupt was not received on a secondary processor in
> >> an
> >> MP system within the allocated interval. This indicates that the specified
> >> processor is hung and not processing interrupts.
> >> "
> >>
> >> This seems to happen with any qemu version I've tested (1.2 and above,
> >> including upstream),
> >> and I was testing it with 3.13.0-44-generic kernel on my Ubuntu 14.04.1
> >> LTS with SMP4 host, as well as on 3.12.26-1 kernel with Debian 6 with SMP6
> >> host.
> >>
> >> One thing I noticed is that exposing a dummy CPU load on the HOST (like
> >> running multiple instances of the "while true; do false; done" script) in
> >> parallel with doing migration makes the issue to be quite easily
>>> reproducible.
> >>
> >>
> >> Looking inside the windows crash dump, the second CPU is just running at
> >> IRQL 0, and it aparently not hung, as Windows is able to save its state in
> >> the crash dump correctly, which assumes running some code on it.
> >> So this aparently seems to be some timing issue (like host scheduler does
> >> not schedule the thread executing secondary CPU's code in time).
> >>
> >> Could you give me some insight on this, i.e. is there a way to customize
> >> QEMU/KVM to avoid such issue?
> >>
> >> If you think this might be a qemu/kvm issue, I can provide you any info,
> >> like windows crash dumps, or the test-case to reproduce this.
> >>
> >>
>>> qemu is started as:
> >>
> >> from-VM:
> >>
> >> qemu-system-x86_64 \
> >>     -S  \
> >>     -name 'virt-tests-vm1'  \
> >>     -sandbox off  \
> >>     -M pc-1.0  \
> >>     -nodefaults  \
> >>     -vga std  \
> >>     -chardev
> >> socket,id=qmp_id_qmp1,path=/tmp/monitor-qmp1-20150123-112624-aFZmIkNT,server,nowait
> >> \
> >>     -mon chardev=qmp_id_qmp1,mode=control  \
> >>     -chardev
>>> socket,id=serial_id_serial0,path=/tmp/serial-serial0-20150123-112624-aFZmIkNT,server,nowait
> >> \
> >>     -device isa-serial,chardev=serial_id_serial0  \
> >>     -chardev
> >> socket,id=seabioslog_id_20150123-112624-aFZmIkNT,path=/tmp/seabios-20150123-112624-aFZmIkNT,server,nowait
> >> \
> >>     -device
> >> isa-debugcon,chardev=seabioslog_id_20150123-112624-aFZmIkNT,iobase=0x402 \
> >>     -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=03 \
> >>     -drive id=drive_image1,if=none,file=/path/to/image.qcow2 \
> >>     -device
> >> virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=04 \
> >>     -device
> >> virtio-net-pci,mac=9a:74:75:76:77:78,id=idFdaC4M,vectors=4,netdev=idKFZNXH,bus=pci.0,addr=05
> >> \
> >>     -netdev
>>> user,id=idKFZNXH,hostfwd=tcp::5000-:22,hostfwd=tcp::5001-:10023  \
> >>     -m 2G  \
> >>     -smp 2,maxcpus=2,cores=1,threads=1,sockets=2  \
> >>     -cpu phenom \
> >>     -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
> >>     -vnc :0  \
> >>     -rtc base=localtime,clock=host,driftfix=none  \
> >>     -boot order=cdn,once=c,menu=off \
> >>     -enable-kvm
> >>
> >> to-VM:
> >>
> >> qemu-system-x86_64 \
> >>     -S  \
> >>     -name 'virt-tests-vm1'  \
> >>     -sandbox off  \
>>>     -M pc-1.0  \
> >>     -nodefaults  \
> >>     -vga std  \
> >>     -chardev
> >> socket,id=qmp_id_qmp1,path=/tmp/monitor-qmp1-20150123-112750-VehjvEqK,server,nowait
> >> \
> >>     -mon chardev=qmp_id_qmp1,mode=control  \
> >>     -chardev
> >> socket,id=serial_id_serial0,path=/tmp/serial-serial0-20150123-112750-VehjvEqK,server,nowait
> >> \
> >>     -device isa-serial,chardev=serial_id_serial0  \
> >>     -chardev
> >> socket,id=seabioslog_id_20150123-112750-VehjvEqK,path=/tmp/seabios-20150123-112750-VehjvEqK,server,nowait
> >> \
> >>     -device
> >> isa-debugcon,chardev=seabioslog_id_20150123-112750-VehjvEqK,iobase=0x402 \
>>>     -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=03 \
> >>     -drive id=drive_image1,if=none,file=/path/to/image.qcow2 \
> >>     -device
> >> virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=04 \
> >>     -device
> >> virtio-net-pci,mac=9a:74:75:76:77:78,id=idI46M9C,vectors=4,netdev=idl9vRQt,bus=pci.0,addr=05
> >> \
> >>     -netdev
> >> user,id=idl9vRQt,hostfwd=tcp::5002-:22,hostfwd=tcp::5003-:10023  \
> >>     -m 2G  \
> >>     -smp 2,maxcpus=2,cores=1,threads=1,sockets=2  \
> >>     -cpu phenom \
> >>     -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
> >>     -vnc :1  \
> >>     -rtc base=localtime,clock=host,driftfix=none  \
> >>     -boot order=cdn,once=c,menu=off \
>>>     -enable-kvm \
> >>     -incoming tcp:0:5200
> >>
> >>
> >> Thanks,
> >> Mikhail

Re: Windows 2008 Guest BSODS with CLOCK_WATCHDOG_TIMEOUT on VM migration

[Mikhail Sennikovskii]

Hi Zhang,

Thanks a lot for the suggestion, it indeed worked for me!
I.e. after adding the hv_relaxed to the list of CPU properties I can no 
longer reproduce the BSOD on migration with any kernel version that I 
used so far.

Thanks for your help,
Mikhail

On 28.01.2015 07:42, Zhang Haoyu wrote:
> On 2015-01-28 03:10:23, Jidong Xiao wrote:
>> On Tue, Jan 27, 2015 at 5:55 AM, Mikhail Sennikovskii
>> <mikhail.sennikovskii@profitbricks.com> wrote:
>>> Hi all,
>>>
>>> I've posted the bolow mail to the qemu-dev mailing list, but I've got no
>>> response there.
>>> That's why I decided to re-post it here as well, and besides that I think
>>> this could be a kvm-specific issue as well.
>>>
>>> Some additional thing to note:
>>> I can reproduce the issue on my Debian 7 with 3.16.0-0.bpo.4-amd64 kernel as
>>> well.
>>> I would typically use a max_downtime adjusted to 1 second instead of default
>>> 30 ms.
>>> I also noticed that the issue happens much more rarelly if I increase the
>>> migration bandwidth, i.e. like
>>>
>>> diff --git a/migration.c b/migration.c
>>> index 26f4b65..d2e3b39 100644
>>> --- a/migration.c
>>> +++ b/migration.c
>>> @@ -36,7 +36,7 @@ enum {
>>>       MIG_STATE_COMPLETED,
>>>   };
>>>
>>> -#define MAX_THROTTLE  (32 << 20)      /* Migration speed throttling */
>>> +#define MAX_THROTTLE  (90 << 20)      /* Migration speed throttling */
>>>
>>> Like I said below, I would be glad to provide you with any additional
>>> information.
>>>
>>> Thanks,
>>> Mikhail
>>>
>> Hi, Mikhail,
>>
>> So if you choose to use one vcpu, instead of smp, this issue would not
>> happen, right?
>>
> I think you can try cpu feature hv_relaxed, like
> -cpu Haswell,hv_relaxed
>
>> -Jidong
>>
>>> On 23.01.2015 15:03, Mikhail Sennikovskii wrote:
>>>> Hi all,
>>>>
>>>> I'm running a slitely modified migration over tcp test in virt-test, which
>>>> does a migration from one "smp=2" VM to another on the same host over TCP,
>>>> and exposes some dummy CPU load inside the GUEST while migration, and
>>>> after a series of runs I'm alwais getting a CLOCK_WATCHDOG_TIMEOUT BSOD
>>>> inside the guest,
>>>> which happens when
>>>> "
>>>> An expected clock interrupt was not received on a secondary processor in
>>>> an
>>>> MP system within the allocated interval. This indicates that the specified
>>>> processor is hung and not processing interrupts.
>>>> "
>>>>
>>>> This seems to happen with any qemu version I've tested (1.2 and above,
>>>> including upstream),
>>>> and I was testing it with 3.13.0-44-generic kernel on my Ubuntu 14.04.1
>>>> LTS with SMP4 host, as well as on 3.12.26-1 kernel with Debian 6 with SMP6
>>>> host.
>>>>
>>>> One thing I noticed is that exposing a dummy CPU load on the HOST (like
>>>> running multiple instances of the "while true; do false; done" script) in
>>>> parallel with doing migration makes the issue to be quite easily
>>>> reproducible.
>>>>
>>>>
>>>> Looking inside the windows crash dump, the second CPU is just running at
>>>> IRQL 0, and it aparently not hung, as Windows is able to save its state in
>>>> the crash dump correctly, which assumes running some code on it.
>>>> So this aparently seems to be some timing issue (like host scheduler does
>>>> not schedule the thread executing secondary CPU's code in time).
>>>>
>>>> Could you give me some insight on this, i.e. is there a way to customize
>>>> QEMU/KVM to avoid such issue?
>>>>
>>>> If you think this might be a qemu/kvm issue, I can provide you any info,
>>>> like windows crash dumps, or the test-case to reproduce this.
>>>>
>>>>
>>>> qemu is started as:
>>>>
>>>> from-VM:
>>>>
>>>> qemu-system-x86_64 \
>>>>      -S  \
>>>>      -name 'virt-tests-vm1'  \
>>>>      -sandbox off  \
>>>>      -M pc-1.0  \
>>>>      -nodefaults  \
>>>>      -vga std  \
>>>>      -chardev
>>>> socket,id=qmp_id_qmp1,path=/tmp/monitor-qmp1-20150123-112624-aFZmIkNT,server,nowait
>>>> \
>>>>      -mon chardev=qmp_id_qmp1,mode=control  \
>>>>      -chardev
>>>> socket,id=serial_id_serial0,path=/tmp/serial-serial0-20150123-112624-aFZmIkNT,server,nowait
>>>> \
>>>>      -device isa-serial,chardev=serial_id_serial0  \
>>>>      -chardev
>>>> socket,id=seabioslog_id_20150123-112624-aFZmIkNT,path=/tmp/seabios-20150123-112624-aFZmIkNT,server,nowait
>>>> \
>>>>      -device
>>>> isa-debugcon,chardev=seabioslog_id_20150123-112624-aFZmIkNT,iobase=0x402 \
>>>>      -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=03 \
>>>>      -drive id=drive_image1,if=none,file=/path/to/image.qcow2 \
>>>>      -device
>>>> virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=04 \
>>>>      -device
>>>> virtio-net-pci,mac=9a:74:75:76:77:78,id=idFdaC4M,vectors=4,netdev=idKFZNXH,bus=pci.0,addr=05
>>>> \
>>>>      -netdev
>>>> user,id=idKFZNXH,hostfwd=tcp::5000-:22,hostfwd=tcp::5001-:10023  \
>>>>      -m 2G  \
>>>>      -smp 2,maxcpus=2,cores=1,threads=1,sockets=2  \
>>>>      -cpu phenom \
>>>>      -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
>>>>      -vnc :0  \
>>>>      -rtc base=localtime,clock=host,driftfix=none  \
>>>>      -boot order=cdn,once=c,menu=off \
>>>>      -enable-kvm
>>>>
>>>> to-VM:
>>>>
>>>> qemu-system-x86_64 \
>>>>      -S  \
>>>>      -name 'virt-tests-vm1'  \
>>>>      -sandbox off  \
>>>>      -M pc-1.0  \
>>>>      -nodefaults  \
>>>>      -vga std  \
>>>>      -chardev
>>>> socket,id=qmp_id_qmp1,path=/tmp/monitor-qmp1-20150123-112750-VehjvEqK,server,nowait
>>>> \
>>>>      -mon chardev=qmp_id_qmp1,mode=control  \
>>>>      -chardev
>>>> socket,id=serial_id_serial0,path=/tmp/serial-serial0-20150123-112750-VehjvEqK,server,nowait
>>>> \
>>>>      -device isa-serial,chardev=serial_id_serial0  \
>>>>      -chardev
>>>> socket,id=seabioslog_id_20150123-112750-VehjvEqK,path=/tmp/seabios-20150123-112750-VehjvEqK,server,nowait
>>>> \
>>>>      -device
>>>> isa-debugcon,chardev=seabioslog_id_20150123-112750-VehjvEqK,iobase=0x402 \
>>>>      -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=03 \
>>>>      -drive id=drive_image1,if=none,file=/path/to/image.qcow2 \
>>>>      -device
>>>> virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=04 \
>>>>      -device
>>>> virtio-net-pci,mac=9a:74:75:76:77:78,id=idI46M9C,vectors=4,netdev=idl9vRQt,bus=pci.0,addr=05
>>>> \
>>>>      -netdev
>>>> user,id=idl9vRQt,hostfwd=tcp::5002-:22,hostfwd=tcp::5003-:10023  \
>>>>      -m 2G  \
>>>>      -smp 2,maxcpus=2,cores=1,threads=1,sockets=2  \
>>>>      -cpu phenom \
>>>>      -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
>>>>      -vnc :1  \
>>>>      -rtc base=localtime,clock=host,driftfix=none  \
>>>>      -boot order=cdn,once=c,menu=off \
>>>>      -enable-kvm \
>>>>      -incoming tcp:0:5200
>>>>
>>>>
>>>> Thanks,
>>>> Mikhail

Re: Windows 2008 Guest BSODS with CLOCK_WATCHDOG_TIMEOUT on VM migration

[Mikhail Sennikovskii]

Hi Jidong,

right, this issue is SMP-specific.

Mikhail

On 27.01.2015 20:09, Jidong Xiao wrote:
> On Tue, Jan 27, 2015 at 5:55 AM, Mikhail Sennikovskii
> <mikhail.sennikovskii@profitbricks.com> wrote:
>> Hi all,
>>
>> I've posted the bolow mail to the qemu-dev mailing list, but I've got no
>> response there.
>> That's why I decided to re-post it here as well, and besides that I think
>> this could be a kvm-specific issue as well.
>>
>> Some additional thing to note:
>> I can reproduce the issue on my Debian 7 with 3.16.0-0.bpo.4-amd64 kernel as
>> well.
>> I would typically use a max_downtime adjusted to 1 second instead of default
>> 30 ms.
>> I also noticed that the issue happens much more rarelly if I increase the
>> migration bandwidth, i.e. like
>>
>> diff --git a/migration.c b/migration.c
>> index 26f4b65..d2e3b39 100644
>> --- a/migration.c
>> +++ b/migration.c
>> @@ -36,7 +36,7 @@ enum {
>>       MIG_STATE_COMPLETED,
>>   };
>>
>> -#define MAX_THROTTLE  (32 << 20)      /* Migration speed throttling */
>> +#define MAX_THROTTLE  (90 << 20)      /* Migration speed throttling */
>>
>> Like I said below, I would be glad to provide you with any additional
>> information.
>>
>> Thanks,
>> Mikhail
>>
> Hi, Mikhail,
>
> So if you choose to use one vcpu, instead of smp, this issue would not
> happen, right?
>
> -Jidong
>
>> On 23.01.2015 15:03, Mikhail Sennikovskii wrote:
>>> Hi all,
>>>
>>> I'm running a slitely modified migration over tcp test in virt-test, which
>>> does a migration from one "smp=2" VM to another on the same host over TCP,
>>> and exposes some dummy CPU load inside the GUEST while migration, and
>>> after a series of runs I'm alwais getting a CLOCK_WATCHDOG_TIMEOUT BSOD
>>> inside the guest,
>>> which happens when
>>> "
>>> An expected clock interrupt was not received on a secondary processor in
>>> an
>>> MP system within the allocated interval. This indicates that the specified
>>> processor is hung and not processing interrupts.
>>> "
>>>
>>> This seems to happen with any qemu version I've tested (1.2 and above,
>>> including upstream),
>>> and I was testing it with 3.13.0-44-generic kernel on my Ubuntu 14.04.1
>>> LTS with SMP4 host, as well as on 3.12.26-1 kernel with Debian 6 with SMP6
>>> host.
>>>
>>> One thing I noticed is that exposing a dummy CPU load on the HOST (like
>>> running multiple instances of the "while true; do false; done" script) in
>>> parallel with doing migration makes the issue to be quite easily
>>> reproducible.
>>>
>>>
>>> Looking inside the windows crash dump, the second CPU is just running at
>>> IRQL 0, and it aparently not hung, as Windows is able to save its state in
>>> the crash dump correctly, which assumes running some code on it.
>>> So this aparently seems to be some timing issue (like host scheduler does
>>> not schedule the thread executing secondary CPU's code in time).
>>>
>>> Could you give me some insight on this, i.e. is there a way to customize
>>> QEMU/KVM to avoid such issue?
>>>
>>> If you think this might be a qemu/kvm issue, I can provide you any info,
>>> like windows crash dumps, or the test-case to reproduce this.
>>>
>>>
>>> qemu is started as:
>>>
>>> from-VM:
>>>
>>> qemu-system-x86_64 \
>>>      -S  \
>>>      -name 'virt-tests-vm1'  \
>>>      -sandbox off  \
>>>      -M pc-1.0  \
>>>      -nodefaults  \
>>>      -vga std  \
>>>      -chardev
>>> socket,id=qmp_id_qmp1,path=/tmp/monitor-qmp1-20150123-112624-aFZmIkNT,server,nowait
>>> \
>>>      -mon chardev=qmp_id_qmp1,mode=control  \
>>>      -chardev
>>> socket,id=serial_id_serial0,path=/tmp/serial-serial0-20150123-112624-aFZmIkNT,server,nowait
>>> \
>>>      -device isa-serial,chardev=serial_id_serial0  \
>>>      -chardev
>>> socket,id=seabioslog_id_20150123-112624-aFZmIkNT,path=/tmp/seabios-20150123-112624-aFZmIkNT,server,nowait
>>> \
>>>      -device
>>> isa-debugcon,chardev=seabioslog_id_20150123-112624-aFZmIkNT,iobase=0x402 \
>>>      -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=03 \
>>>      -drive id=drive_image1,if=none,file=/path/to/image.qcow2 \
>>>      -device
>>> virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=04 \
>>>      -device
>>> virtio-net-pci,mac=9a:74:75:76:77:78,id=idFdaC4M,vectors=4,netdev=idKFZNXH,bus=pci.0,addr=05
>>> \
>>>      -netdev
>>> user,id=idKFZNXH,hostfwd=tcp::5000-:22,hostfwd=tcp::5001-:10023  \
>>>      -m 2G  \
>>>      -smp 2,maxcpus=2,cores=1,threads=1,sockets=2  \
>>>      -cpu phenom \
>>>      -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
>>>      -vnc :0  \
>>>      -rtc base=localtime,clock=host,driftfix=none  \
>>>      -boot order=cdn,once=c,menu=off \
>>>      -enable-kvm
>>>
>>> to-VM:
>>>
>>> qemu-system-x86_64 \
>>>      -S  \
>>>      -name 'virt-tests-vm1'  \
>>>      -sandbox off  \
>>>      -M pc-1.0  \
>>>      -nodefaults  \
>>>      -vga std  \
>>>      -chardev
>>> socket,id=qmp_id_qmp1,path=/tmp/monitor-qmp1-20150123-112750-VehjvEqK,server,nowait
>>> \
>>>      -mon chardev=qmp_id_qmp1,mode=control  \
>>>      -chardev
>>> socket,id=serial_id_serial0,path=/tmp/serial-serial0-20150123-112750-VehjvEqK,server,nowait
>>> \
>>>      -device isa-serial,chardev=serial_id_serial0  \
>>>      -chardev
>>> socket,id=seabioslog_id_20150123-112750-VehjvEqK,path=/tmp/seabios-20150123-112750-VehjvEqK,server,nowait
>>> \
>>>      -device
>>> isa-debugcon,chardev=seabioslog_id_20150123-112750-VehjvEqK,iobase=0x402 \
>>>      -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=03 \
>>>      -drive id=drive_image1,if=none,file=/path/to/image.qcow2 \
>>>      -device
>>> virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=04 \
>>>      -device
>>> virtio-net-pci,mac=9a:74:75:76:77:78,id=idI46M9C,vectors=4,netdev=idl9vRQt,bus=pci.0,addr=05
>>> \
>>>      -netdev
>>> user,id=idl9vRQt,hostfwd=tcp::5002-:22,hostfwd=tcp::5003-:10023  \
>>>      -m 2G  \
>>>      -smp 2,maxcpus=2,cores=1,threads=1,sockets=2  \
>>>      -cpu phenom \
>>>      -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
>>>      -vnc :1  \
>>>      -rtc base=localtime,clock=host,driftfix=none  \
>>>      -boot order=cdn,once=c,menu=off \
>>>      -enable-kvm \
>>>      -incoming tcp:0:5200
>>>
>>>
>>> Thanks,
>>> Mikhail
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Qemu-devel] [Bug 1412098] Re: qemu crashes when ctrl-alt-u is pressed

[Legorol]

I did a git bisect, and the offending commit appears to be this one:

author	Gerd Hoffmann <kraxel@redhat.com>	
Wed, 18 Jun 2014 09:03:15 +0000 (11:03 +0200)
committer	Gerd Hoffmann <kraxel@redhat.com>	
Fri, 5 Sep 2014 11:27:11 +0000 (13:27 +0200)
commit	30f1e661b640de58ba1e8178f7f2290179a7e01c
tree	dc373a0d374386bc793e67a9e185dbc5ecdfc8f1	tree | snapshot
parent	56bd9ea1a37395012adecca8b9c4762da15b01e7	commit | diff
console: stop using PixelFormat

With this patch the qemu console core stops using PixelFormat and pixman
format codes side-by-side, pixman format code is the primary way to
specify the DisplaySurface format:

 * DisplaySurface stops carrying a PixelFormat field.
 * qemu_create_displaysurface_from() expects a pixman format now.

Functions to convert PixelFormat to pixman_format_code_t (and back)
exist for those who still use PixelFormat.   As PixelFormat allows
easy access to masks and shifts it will probably continue to exist.

[ xenfb added by Benjamin Herrenschmidt ]

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1412098

Title:
  qemu crashes when ctrl-alt-u is pressed

Status in QEMU:
  New

Bug description:
  Qemu version: 2.2.0 release, compiled from source
  Host OS: Windows 7 Ultimate x64
  Guest OS: not applicable, crash occurs even without OS and occurs with all OSs
  Executable: qemu-system-i386.exe or qemu-system-i386w.exe

  To reproduce:
  Start qemu-system-i386 or qemu-system-i386w without any options. Press CTRL-ALT-U, which is supposed to rescale the window. Instead, qemu just crashes.

  Compilation:
  Qemu 2.2.0 release compiled from sources under MinGW on the host.
  Configure options used:
  '../qemu-2.2.0/configure' '--python=C:/Python27/python' '--prefix=/mingw/build/qemu-2.2.0-bin' '--target-list=i386-softmmu'

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1412098/+subscriptions

[Qemu-devel] [Bug 1412098] Re: qemu crashes when ctrl-alt-u is pressed

[Ingo Krabbe]

A build from the current master attached in gdb reveals

Program received signal SIGSEGV, Segmentation fault.
sdl_switch (dcl=0x7f4db26e4b20, new_surface=new_surface@entry=0x0) at ui/sdl.c:128
128         PixelFormat pf = qemu_pixelformat_from_pixman(new_surface->format);
(gdb) bt
#0  sdl_switch (dcl=0x7f4db26e4b20, new_surface=new_surface@entry=0x0) at ui/sdl.c:128
#1  0x00007f4dafdff9c4 in handle_keydown (ev=0x7fff1598ef60) at ui/sdl.c:552
#2  sdl_refresh (dcl=0x7f4db26e4b20) at ui/sdl.c:799
#3  0x00007f4dafdf33b2 in dpy_refresh (s=0x7f4db2792b40) at ui/console.c:1473
#4  gui_update (opaque=0x7f4db2792b40) at ui/console.c:196
#5  0x00007f4dafe30179 in timerlist_run_timers (timer_list=0x7f4db1dd4900) at qemu-timer.c:502
#6  0x00007f4dafe30414 in qemu_clock_run_timers (type=<optimized out>) at qemu-timer.c:513
#7  qemu_clock_run_all_timers () at qemu-timer.c:621
#8  0x00007f4dafe2ebac in main_loop_wait (nonblocking=<optimized out>) at main-loop.c:500
#9  0x00007f4dafb8fe66 in main_loop () at vl.c:1794
#10 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4353
(gdb) p new_surface
$1 = (DisplaySurface *) 0x0

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1412098

Title:
  qemu crashes when ctrl-alt-u is pressed

Status in QEMU:
  New

Bug description:
  Qemu version: 2.2.0 release, compiled from source
  Host OS: Windows 7 Ultimate x64
  Guest OS: not applicable, crash occurs even without OS and occurs with all OSs
  Executable: qemu-system-i386.exe or qemu-system-i386w.exe

  To reproduce:
  Start qemu-system-i386 or qemu-system-i386w without any options. Press CTRL-ALT-U, which is supposed to rescale the window. Instead, qemu just crashes.

  Compilation:
  Qemu 2.2.0 release compiled from sources under MinGW on the host.
  Configure options used:
  '../qemu-2.2.0/configure' '--python=C:/Python27/python' '--prefix=/mingw/build/qemu-2.2.0-bin' '--target-list=i386-softmmu'

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1412098/+subscriptions

[Qemu-devel] [Bug 1412098] Re: qemu crashes when ctrl-alt-u is pressed

[Ingo Krabbe]

Actually in any version this can never work, as you call

   sdl_switch(dcl,NULL);

in ui/sdl.c:552. So the dereferncing statement

   new_surface->format

must SEGFAULT.

The obvious patch is very simple, of course, as just the statement below
line 128 asks if(new_surface). So pf should be initialized after this
check:

diff --git a/ui/sdl.c b/ui/sdl.c
index 138ca73..c4fa1f6 100644
--- a/ui/sdl.c
+++ b/ui/sdl.c
@@ -125,12 +125,13 @@ static void do_sdl_resize(int width, int height, int bpp)
 static void sdl_switch(DisplayChangeListener *dcl,
                        DisplaySurface *new_surface)
 {
-    PixelFormat pf = qemu_pixelformat_from_pixman(new_surface->format);
+    PixelFormat pf;

     /* temporary hack: allows to call sdl_switch to handle scaling changes */
     if (new_surface) {
         surface = new_surface;
     }
+    pf = qemu_pixelformat_from_pixman(surface->format);

     if (!scaling_active) {
         do_sdl_resize(surface_width(surface), surface_height(surface), 0);

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1412098

Title:
  qemu crashes when ctrl-alt-u is pressed

Status in QEMU:
  New

Bug description:
  Qemu version: 2.2.0 release, compiled from source
  Host OS: Windows 7 Ultimate x64
  Guest OS: not applicable, crash occurs even without OS and occurs with all OSs
  Executable: qemu-system-i386.exe or qemu-system-i386w.exe

  To reproduce:
  Start qemu-system-i386 or qemu-system-i386w without any options. Press CTRL-ALT-U, which is supposed to rescale the window. Instead, qemu just crashes.

  Compilation:
  Qemu 2.2.0 release compiled from sources under MinGW on the host.
  Configure options used:
  '../qemu-2.2.0/configure' '--python=C:/Python27/python' '--prefix=/mingw/build/qemu-2.2.0-bin' '--target-list=i386-softmmu'

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1412098/+subscriptions

[Qemu-devel] [Bug 1412098] Re: qemu crashes when ctrl-alt-u is pressed

[Legorol]

Ingo Krabbe's suggested change fixes the issue for me.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1412098

Title:
  qemu crashes when ctrl-alt-u is pressed

Status in QEMU:
  New

Bug description:
  Qemu version: 2.2.0 release, compiled from source
  Host OS: Windows 7 Ultimate x64
  Guest OS: not applicable, crash occurs even without OS and occurs with all OSs
  Executable: qemu-system-i386.exe or qemu-system-i386w.exe

  To reproduce:
  Start qemu-system-i386 or qemu-system-i386w without any options. Press CTRL-ALT-U, which is supposed to rescale the window. Instead, qemu just crashes.

  Compilation:
  Qemu 2.2.0 release compiled from sources under MinGW on the host.
  Configure options used:
  '../qemu-2.2.0/configure' '--python=C:/Python27/python' '--prefix=/mingw/build/qemu-2.2.0-bin' '--target-list=i386-softmmu'

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1412098/+subscriptions

[Qemu-devel] [Bug 1412098] Re: qemu crashes when ctrl-alt-u is pressed

[pranith]

** Changed in: qemu
       Status: New => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1412098

Title:
  qemu crashes when ctrl-alt-u is pressed

Status in QEMU:
  Fix Released

Bug description:
  Qemu version: 2.2.0 release, compiled from source
  Host OS: Windows 7 Ultimate x64
  Guest OS: not applicable, crash occurs even without OS and occurs with all OSs
  Executable: qemu-system-i386.exe or qemu-system-i386w.exe

  To reproduce:
  Start qemu-system-i386 or qemu-system-i386w without any options. Press CTRL-ALT-U, which is supposed to rescale the window. Instead, qemu just crashes.

  Compilation:
  Qemu 2.2.0 release compiled from sources under MinGW on the host.
  Configure options used:
  '../qemu-2.2.0/configure' '--python=C:/Python27/python' '--prefix=/mingw/build/qemu-2.2.0-bin' '--target-list=i386-softmmu'

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1412098/+subscriptions