Re: [Bug 1743191] Re: Interacting with NetBSD serial console boot blocks no longer works

[Andreas Gustafsson]

Ottavio Caruso wrote:
> I am currently using:
> 
> $ qemu-system-x86_64 --version
> QEMU emulator version 5.2.0
> 
> And I have no problem selecting from menu in serial console, so I
> assume this is fixed for me. This is my command line:
> 
> $ cat opt/bin/boot-netbsd-virtio
> #!/bin/sh
> qemu-system-x86_64 \
> -drive if=virtio,file=/home/oc/VM/img/netbsd.image,index=0,media=disk \
> -drive if=virtio,file=/home/oc/VM/img/netbsd.image.old,index=1,media=disk \
> -M q35,accel=kvm -m 250M -cpu host -smp $(nproc) \
> -nic user,hostfwd=tcp:127.0.0.1:-:22,model=virtio-net-pci,ipv6=off  \
> -daemonize -display none  -vga none \
> -serial mon:telnet:127.0.0.1:6665,server,nowait \
> -pidfile /home/oc/VM/pid/netbsd-pid -nodefaults
> 
> telnet 127.0.0.1 6665

Have you tried the test case in the original bug report?
-- 
Andreas Gustafsson, g...@gson.org

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

Title:
  Interacting with NetBSD serial console boot blocks no longer works

Status in QEMU:
  New

Bug description:
  The NetBSD boot blocks display a menu allowing the user to make a
  selection using the keyboard.  For example, when booting a NetBSD
  installation CD-ROM, the menu looks like this:

   1. Install NetBSD
   2. Install NetBSD (no ACPI)
   3. Install NetBSD (no ACPI, no SMP)
   4. Drop to boot prompt

  Choose an option; RETURN for default; SPACE to stop countdown.
  Option 1 will be chosen in 30 seconds.

  When booting NetBSD in a recent qemu using an emulated serial console,
  making this menu selection no longer works: when you type the selected
  number, the keyboard input is ignored, and the 30-second countdown
  continues.  In older versions of qemu, it works.

  To reproduce the problem, run:

 wget 
http://ftp.netbsd.org/pub/NetBSD/NetBSD-7.1.1/amd64/installation/cdrom/boot-com.iso
 qemu-system-x86_64 -nographic -cdrom boot-com.iso

  During the 30-second countdown, press 4

  Expected behavior: The countdown stops and you get a ">" prompt

  Incorrect behavior: The countdown continues

  There may also be some corruption of the terminal output; for example,
  "Option 1 will be chosen in 30 seconds" may be displayed as "Option 1
  will be chosen in p0 seconds".

  Using bisection, I have determined that the problem appeared with qemu
  commit 083fab0290f2c40d3d04f7f22eed9c8f2d5b6787, in which seabios was
  updated to 1.11 prerelease, and the problem is still there as of
  commit 7398166ddf7c6dbbc9cae6ac69bb2feda14b40ac.  The host operating
  system used for the tests was Debian 9 x86_64.

  Credit for discovering this bug goes to Paul Goyette.

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

Re: [Bug 1743191] Re: Interacting with NetBSD serial console boot blocks no longer works

[Andreas Gustafsson]

Paul Goyette wrote:
> This bug was fixed long ago, so long ago that I have no idea when!

No, it is not fixed, and I did actually check before I switched the
bug state back to "new".

Perhaps you are specifying "-machine graphics=on" as suggested in one
of the comments?  If so, that's a work-around, and an ugly and
nonintuitive one at that, not a fix.
-- 
Andreas Gustafsson, g...@gson.org

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

Title:
  Interacting with NetBSD serial console boot blocks no longer works

Status in QEMU:
  New

Bug description:
  The NetBSD boot blocks display a menu allowing the user to make a
  selection using the keyboard.  For example, when booting a NetBSD
  installation CD-ROM, the menu looks like this:

   1. Install NetBSD
   2. Install NetBSD (no ACPI)
   3. Install NetBSD (no ACPI, no SMP)
   4. Drop to boot prompt

  Choose an option; RETURN for default; SPACE to stop countdown.
  Option 1 will be chosen in 30 seconds.

  When booting NetBSD in a recent qemu using an emulated serial console,
  making this menu selection no longer works: when you type the selected
  number, the keyboard input is ignored, and the 30-second countdown
  continues.  In older versions of qemu, it works.

  To reproduce the problem, run:

 wget 
http://ftp.netbsd.org/pub/NetBSD/NetBSD-7.1.1/amd64/installation/cdrom/boot-com.iso
 qemu-system-x86_64 -nographic -cdrom boot-com.iso

  During the 30-second countdown, press 4

  Expected behavior: The countdown stops and you get a ">" prompt

  Incorrect behavior: The countdown continues

  There may also be some corruption of the terminal output; for example,
  "Option 1 will be chosen in 30 seconds" may be displayed as "Option 1
  will be chosen in p0 seconds".

  Using bisection, I have determined that the problem appeared with qemu
  commit 083fab0290f2c40d3d04f7f22eed9c8f2d5b6787, in which seabios was
  updated to 1.11 prerelease, and the problem is still there as of
  commit 7398166ddf7c6dbbc9cae6ac69bb2feda14b40ac.  The host operating
  system used for the tests was Debian 9 x86_64.

  Credit for discovering this bug goes to Paul Goyette.

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

[Bug 1743191] Re: Interacting with NetBSD serial console boot blocks no longer works

[Andreas Gustafsson]

** Changed in: qemu
   Status: Incomplete => New

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

Title:
  Interacting with NetBSD serial console boot blocks no longer works

Status in QEMU:
  New

Bug description:
  The NetBSD boot blocks display a menu allowing the user to make a
  selection using the keyboard.  For example, when booting a NetBSD
  installation CD-ROM, the menu looks like this:

   1. Install NetBSD
   2. Install NetBSD (no ACPI)
   3. Install NetBSD (no ACPI, no SMP)
   4. Drop to boot prompt

  Choose an option; RETURN for default; SPACE to stop countdown.
  Option 1 will be chosen in 30 seconds.

  When booting NetBSD in a recent qemu using an emulated serial console,
  making this menu selection no longer works: when you type the selected
  number, the keyboard input is ignored, and the 30-second countdown
  continues.  In older versions of qemu, it works.

  To reproduce the problem, run:

 wget 
http://ftp.netbsd.org/pub/NetBSD/NetBSD-7.1.1/amd64/installation/cdrom/boot-com.iso
 qemu-system-x86_64 -nographic -cdrom boot-com.iso

  During the 30-second countdown, press 4

  Expected behavior: The countdown stops and you get a ">" prompt

  Incorrect behavior: The countdown continues

  There may also be some corruption of the terminal output; for example,
  "Option 1 will be chosen in 30 seconds" may be displayed as "Option 1
  will be chosen in p0 seconds".

  Using bisection, I have determined that the problem appeared with qemu
  commit 083fab0290f2c40d3d04f7f22eed9c8f2d5b6787, in which seabios was
  updated to 1.11 prerelease, and the problem is still there as of
  commit 7398166ddf7c6dbbc9cae6ac69bb2feda14b40ac.  The host operating
  system used for the tests was Debian 9 x86_64.

  Credit for discovering this bug goes to Paul Goyette.

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

Re: [RFC PATCH v2] hw/display/tcx: Allow 64-bit accesses to framebuffer stippler and blitter

[Andreas Gustafsson]

Philippe Mathieu-Daudé wrote:
> Thanks, can I add "Tested-by: Andreas Gustafsson "
> to the patch?

Fine by me.
-- 
Andreas Gustafsson, g...@gson.org

Re: [RFC PATCH v2] hw/display/tcx: Allow 64-bit accesses to framebuffer stippler and blitter

[Andreas Gustafsson]

Philippe Mathieu-Daudé wrote:
> diff --git a/hw/display/tcx.c b/hw/display/tcx.c
> index 1fb45b1aab8..96c6898b149 100644

With this patch, the kernel boots successfully for me.
-- 
Andreas Gustafsson, g...@gson.org

[Bug 1892540] [NEW] qemu can no longer boot NetBSD/sparc

[Andreas Gustafsson]

Public bug reported:

Booting NetBSD/sparc in qemu no longer works.  It broke between qemu
version 5.0.0 and 5.1.0, and a bisection identified the following as the
offending commit:

  [5d971f9e672507210e77d020d89e0e89165c8fc9] memory: Revert "memory:
accept mismatching sizes in memory_region_access_valid"

It's still broken as of 7fd51e68c34fcefdb4d6fd646ed3346f780f89f4.

To reproduce, run

  wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-9.0/images/NetBSD-9.0-sparc.iso
  qemu-system-sparc -nographic -cdrom NetBSD-9.0-sparc.iso -boot d

The expected behavior is that the guest boots to the prompt

  Installation medium to load the additional utilities from:

The observed behavior is a panic:

  [   1.050] system[0]: trap 0x29: pc=0xf0046b14 sfsr=0xb6 sfva=0x5400
  [   1.050] cpu0: data fault: pc=0xf0046b14 addr=0x5400 
sfsr=0xb6
  [   1.050] panic: kernel fault
  [   1.050] halted

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  qemu can no longer boot NetBSD/sparc

Status in QEMU:
  New

Bug description:
  Booting NetBSD/sparc in qemu no longer works.  It broke between qemu
  version 5.0.0 and 5.1.0, and a bisection identified the following as
  the offending commit:

[5d971f9e672507210e77d020d89e0e89165c8fc9] memory: Revert "memory:
  accept mismatching sizes in memory_region_access_valid"

  It's still broken as of 7fd51e68c34fcefdb4d6fd646ed3346f780f89f4.

  To reproduce, run

wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-9.0/images/NetBSD-9.0-sparc.iso
qemu-system-sparc -nographic -cdrom NetBSD-9.0-sparc.iso -boot d

  The expected behavior is that the guest boots to the prompt

Installation medium to load the additional utilities from:

  The observed behavior is a panic:

[   1.050] system[0]: trap 0x29: pc=0xf0046b14 sfsr=0xb6 sfva=0x5400
[   1.050] cpu0: data fault: pc=0xf0046b14 addr=0x5400 
sfsr=0xb6
[   1.050] panic: kernel fault
[   1.050] halted

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

[Bug 1743191] Re: Interacting with NetBSD serial console boot blocks no longer works

[Andreas Gustafsson]

Gerd Hommann wrote:
> Workaround: add "-vga none" to the qemu command line.

This supposed workaround does not work 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/1743191

Title:
  Interacting with NetBSD serial console boot blocks no longer works

Status in QEMU:
  New

Bug description:
  The NetBSD boot blocks display a menu allowing the user to make a
  selection using the keyboard.  For example, when booting a NetBSD
  installation CD-ROM, the menu looks like this:

   1. Install NetBSD
   2. Install NetBSD (no ACPI)
   3. Install NetBSD (no ACPI, no SMP)
   4. Drop to boot prompt

  Choose an option; RETURN for default; SPACE to stop countdown.
  Option 1 will be chosen in 30 seconds.

  When booting NetBSD in a recent qemu using an emulated serial console,
  making this menu selection no longer works: when you type the selected
  number, the keyboard input is ignored, and the 30-second countdown
  continues.  In older versions of qemu, it works.

  To reproduce the problem, run:

 wget 
http://ftp.netbsd.org/pub/NetBSD/NetBSD-7.1.1/amd64/installation/cdrom/boot-com.iso
 qemu-system-x86_64 -nographic -cdrom boot-com.iso

  During the 30-second countdown, press 4

  Expected behavior: The countdown stops and you get a ">" prompt

  Incorrect behavior: The countdown continues

  There may also be some corruption of the terminal output; for example,
  "Option 1 will be chosen in 30 seconds" may be displayed as "Option 1
  will be chosen in p0 seconds".

  Using bisection, I have determined that the problem appeared with qemu
  commit 083fab0290f2c40d3d04f7f22eed9c8f2d5b6787, in which seabios was
  updated to 1.11 prerelease, and the problem is still there as of
  commit 7398166ddf7c6dbbc9cae6ac69bb2feda14b40ac.  The host operating
  system used for the tests was Debian 9 x86_64.

  Credit for discovering this bug goes to Paul Goyette.

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

[Qemu-devel] [Bug 1838658] Re: qemu 4.0.0 broken by glib update

[Andreas Gustafsson]

> So looks like there's some further variable involved beyond just the 
> glib update - perhaps something about the host OS is combining with
> the glib update to trigger it.

Agreed - I just retested using a Fedora 30 instance on EC2, with
glib2-2.60.1-2.fc30.x86_64, and was also unable to reproduce the
issue there.

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

Title:
  qemu 4.0.0 broken by glib update

Status in QEMU:
  New

Bug description:
  In brief, an install CD will successfully boot with qemu 4.0.0 built with 
glib 2.58.3, but freeze during boot with qemu 4.0.0 built with glib 2.60.0. I 
tracked it down to glib's GHashTable improvements. qemu is happy with a glib 
built from
  ```
   git checkout -f 2.60.4
   git revert --no-edit 86c6f7e2b..3bed8a13b
   git revert --no-edit 75f8ec1df9b48b0c3a13a9125f2c7d7c5adf5159
   git revert --no-edit 603fb5958..d3074a748
   git revert --no-edit 0b45ddc55..0600dd322
  ```
  When the GHashTable improvements were committed, there was already a 
preemptive note about any breakage being due to using private implementation 
details, hence mentioning it here rather than with glib.

  For the full saga, see: http://gnats.netbsd.org/54310

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

[Qemu-devel] [Bug 1838658] Re: qemu 4.0.0 broken by glib update

[Andreas Gustafsson]

> The test image that the netbsd bug points to no longer exists.

Please try this one instead:

  https://www.gson.org/bugs/qemu/NetBSD-8.99.47-sparc64.iso

I just verified that this image works for reproducing the bug.

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

Title:
  qemu 4.0.0 broken by glib update

Status in QEMU:
  New

Bug description:
  In brief, an install CD will successfully boot with qemu 4.0.0 built with 
glib 2.58.3, but freeze during boot with qemu 4.0.0 built with glib 2.60.0. I 
tracked it down to glib's GHashTable improvements. qemu is happy with a glib 
built from
  ```
   git checkout -f 2.60.4
   git revert --no-edit 86c6f7e2b..3bed8a13b
   git revert --no-edit 75f8ec1df9b48b0c3a13a9125f2c7d7c5adf5159
   git revert --no-edit 603fb5958..d3074a748
   git revert --no-edit 0b45ddc55..0600dd322
  ```
  When the GHashTable improvements were committed, there was already a 
preemptive note about any breakage being due to using private implementation 
details, hence mentioning it here rather than with glib.

  For the full saga, see: http://gnats.netbsd.org/54310

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

[Qemu-devel] [Bug 1838658] Re: qemu 4.0.0 broken by glib update

[Andreas Gustafsson]

> From the netbsd bug report it looks like the reproducer was demoed
> using the sparc emulator - is that the only QEMU arch that is affected ?

Only one arch is affected, but it's sparc64, not sparc.

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

Title:
  qemu 4.0.0 broken by glib update

Status in QEMU:
  New

Bug description:
  In brief, an install CD will successfully boot with qemu 4.0.0 built with 
glib 2.58.3, but freeze during boot with qemu 4.0.0 built with glib 2.60.0. I 
tracked it down to glib's GHashTable improvements. qemu is happy with a glib 
built from
  ```
   git checkout -f 2.60.4
   git revert --no-edit 86c6f7e2b..3bed8a13b
   git revert --no-edit 75f8ec1df9b48b0c3a13a9125f2c7d7c5adf5159
   git revert --no-edit 603fb5958..d3074a748
   git revert --no-edit 0b45ddc55..0600dd322
  ```
  When the GHashTable improvements were committed, there was already a 
preemptive note about any breakage being due to using private implementation 
details, hence mentioning it here rather than with glib.

  For the full saga, see: http://gnats.netbsd.org/54310

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

[Qemu-devel] [Bug 1810590] [NEW] Record/replay example does not work

[Andreas Gustafsson]

Public bug reported:

Trying the record part of the record/replay example at
https://github.com/qemu/qemu/blob/master/docs/replay.txt qemu
immediately hangs with no guest output displayed.  This is with qemu
from today's git (e59dbbac0364344a3ad84c3497a98c56003d3fb8).

To reproduce:

  wget
https://people.debian.org/~aurel32/qemu/i386/debian_squeeze_i386_standard.qcow2

  mv debian_squeeze_i386_standard.qcow2 disk.qcow2

  qemu-system-i386 \
   -icount shift=7,rr=record,rrfile=replay.bin \
   -drive file=disk.qcow2,if=none,id=img-direct \
   -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay \
   -device ide-hd,drive=img-blkreplay \
   -netdev user,id=net1 -device rtl8139,netdev=net1 \
   -object filter-replay,id=replay,netdev=net1

The above qemu command line is exactly the same as in the example.

Tested on a Debian 9 x86_64 host.

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  Record/replay example does not work

Status in QEMU:
  New

Bug description:
  Trying the record part of the record/replay example at
  https://github.com/qemu/qemu/blob/master/docs/replay.txt qemu
  immediately hangs with no guest output displayed.  This is with qemu
  from today's git (e59dbbac0364344a3ad84c3497a98c56003d3fb8).

  To reproduce:

wget
  
https://people.debian.org/~aurel32/qemu/i386/debian_squeeze_i386_standard.qcow2

mv debian_squeeze_i386_standard.qcow2 disk.qcow2

qemu-system-i386 \
 -icount shift=7,rr=record,rrfile=replay.bin \
 -drive file=disk.qcow2,if=none,id=img-direct \
 -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay \
 -device ide-hd,drive=img-blkreplay \
 -netdev user,id=net1 -device rtl8139,netdev=net1 \
 -object filter-replay,id=replay,netdev=net1

  The above qemu command line is exactly the same as in the example.

  Tested on a Debian 9 x86_64 host.

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

[Qemu-devel] [Bug 1774677] Re: -icount increases boot time by >10x

[Andreas Gustafsson]

Looks like the bug was fixed by this commit:

commit 013aabdc665e4256b38d8875a1a7b5e030ba98f1
Author: Clement Deschamps 
Date:   Sun Oct 21 16:21:03 2018 +0200

icount: fix deadlock when all cpus are sleeping

When all cpus are sleeping (e.g in WFI), to avoid a deadlock
in the main_loop, wake it up in order to start the warp timer.

Signed-off-by: Clement Deschamps 
Message-Id: <20181021142103.19014-1-clement.descha...@greensocs.com>
Signed-off-by: Paolo Bonzini 


** Changed in: qemu
   Status: Confirmed => Fix Committed

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

Title:
  -icount increases boot time by >10x

Status in QEMU:
  Fix Committed

Bug description:
  When I specify the -icount option, some guest operations such as
  booting a Linux kernel take more than 10 times longer than otherwise.
  For example, the following will boot Aboriginal Linux to the login
  prompt about 6 seconds on my system (using TCG, not KVM):

  wget 
http://landley.net/aboriginal/downloads/old/binaries/1.4.5/system-image-i686.tar.gz
  gunzip https://bugs.launchpad.net/qemu/+bug/1774677/+subscriptions

[Qemu-devel] [Bug 1774677] Re: -icount increases boot time by >10x

[Andreas Gustafsson]

I tested Pavel's patch, applying it to master
(c447afd5783b9237fa51b7a85777007d8d568bfc), but I'm afraid it only made
things worse - qemu has now been booting the test kernel for 30 minutes
but the boot has still not completed.  The last console messages printed
were:

piix :00:01.1: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xc100-0xc107
ide1: BM-DMA at 0xc108-0xc10f

Running strace -p on the qemu process shows it calling ppoll once per
second:

ppoll([{fd=0, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, 
{fd=10, events=POLLIN}, {fd=11, events=POLLIN}], 5, {tv_sec=1, tv_nsec=0}, 
NULL, 8) = 0 (Timeout)
ppoll([{fd=0, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, 
{fd=10, events=POLLIN}, {fd=11, events=POLLIN}], 5, {tv_sec=1, tv_nsec=0}, 
NULL, 8) = 0 (Timeout)
ppoll([{fd=0, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, 
{fd=10, events=POLLIN}, {fd=11, events=POLLIN}], 5, {tv_sec=1, tv_nsec=0}, 
NULL, 8) = 0 (Timeout)
ppoll([{fd=0, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, 
{fd=10, events=POLLIN}, {fd=11, events=POLLIN}], 5, {tv_sec=1, tv_nsec=0}, 
NULL, 8) = 0 (Timeout)
ppoll([{fd=0, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, 
{fd=10, events=POLLIN}, {fd=11, events=POLLIN}], 5, {tv_sec=1, tv_nsec=0}, 
NULL, 8) = 0 (Timeout)
ppoll([{fd=0, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, 
{fd=10, events=POLLIN}, {fd=11, events=POLLIN}], 5, {tv_sec=1, tv_nsec=0}, 
NULL, 8) = 0 (Timeout)

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

Title:
  -icount increases boot time by >10x

Status in QEMU:
  Confirmed

Bug description:
  When I specify the -icount option, some guest operations such as
  booting a Linux kernel take more than 10 times longer than otherwise.
  For example, the following will boot Aboriginal Linux to the login
  prompt about 6 seconds on my system (using TCG, not KVM):

  wget 
http://landley.net/aboriginal/downloads/old/binaries/1.4.5/system-image-i686.tar.gz
  gunzip https://bugs.launchpad.net/qemu/+bug/1774677/+subscriptions

[Qemu-devel] [Bug 1774677] Re: -icount increases boot time by >10x

[Andreas Gustafsson]

I bisected this using the following test case (after the setup shown in
the original bug report, and replacing "e1000" by "ne2k_pci" in the run-
emulator.sh script to avoid a panic in the e1000 driver with some qemu
versions):

QEMU_EXTRA="-icount shift=3,sleep=off" sh run-emulator.sh

The bisection identified the following commit:

281b2201e4e18d5b9a26e1e8d81b62b5581a13be is the first bad commit
commit 281b2201e4e18d5b9a26e1e8d81b62b5581a13be
Author: Pavel Dovgalyuk 
Date:   Thu Mar 10 14:56:03 2016 +0300

icount: remove obsolete warp call

qemu_clock_warp call in qemu_tcg_wait_io_event function is not needed
anymore, because it is called in every iteration of main_loop_wait.

Reviewed-by: Paolo Bonzini 

Signed-off-by: Pavel Dovgalyuk 
Message-Id: <20160310115603.4812.67559.stgit@PASHA-ISP>
Signed-off-by: Paolo Bonzini 

With revision 281b2201e4e18d5b9a26e1e8d81b62b5581a13be, the test case
takes 141 seconds to boot.  With the previous revision,
33577b47c64435fcc2a1bc01c7e82534256f1fc3, it takes 1.7 seconds.

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

Title:
  -icount increases boot time by >10x

Status in QEMU:
  Confirmed

Bug description:
  When I specify the -icount option, some guest operations such as
  booting a Linux kernel take more than 10 times longer than otherwise.
  For example, the following will boot Aboriginal Linux to the login
  prompt about 6 seconds on my system (using TCG, not KVM):

  wget 
http://landley.net/aboriginal/downloads/old/binaries/1.4.5/system-image-i686.tar.gz
  gunzip https://bugs.launchpad.net/qemu/+bug/1774677/+subscriptions

[Qemu-devel] [Bug 1774677] Re: -icount increases boot time by >10x

[Andreas Gustafsson]

A couple of comments...  First, the problem is not limited to Linux
guests.  In fact, I originally ran across it with a NetBSD guest, but
then reproduced it with a Linux guest for the bug report, because in my
experience, qemu bug reports involving non-Linux guests tend to be
ignored.

Second, the qemu man page says that "With sleep=on|off, the virtual time
will jump to the next timer deadline instantly whenever the virtual cpu
goes to sleep mode".  Although the text is confusing (see bug 1774412),
to me it suggests that when the mode in case is selected, qemu should
execute the guest as fast as possible and only provide it with an
illusion of the passage of time, and there should be no reason for qemu
itself to ever sleep.  Yet, regardless of whether I specify "sleep=on"
or "sleep=off", qemu sleeps.

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

Title:
  -icount increases boot time by >10x

Status in QEMU:
  Confirmed

Bug description:
  When I specify the -icount option, some guest operations such as
  booting a Linux kernel take more than 10 times longer than otherwise.
  For example, the following will boot Aboriginal Linux to the login
  prompt about 6 seconds on my system (using TCG, not KVM):

  wget 
http://landley.net/aboriginal/downloads/old/binaries/1.4.5/system-image-i686.tar.gz
  gunzip https://bugs.launchpad.net/qemu/+bug/1774677/+subscriptions

[Qemu-devel] [Bug 1774677] [NEW] -icount increases boot time by >10x

[Andreas Gustafsson]

Public bug reported:

When I specify the -icount option, some guest operations such as booting
a Linux kernel take more than 10 times longer than otherwise.  For
example, the following will boot Aboriginal Linux to the login prompt
about 6 seconds on my system (using TCG, not KVM):

wget 
http://landley.net/aboriginal/downloads/old/binaries/1.4.5/system-image-i686.tar.gz
gunzip https://bugs.launchpad.net/bugs/1774677

Title:
  -icount increases boot time by >10x

Status in QEMU:
  New

Bug description:
  When I specify the -icount option, some guest operations such as
  booting a Linux kernel take more than 10 times longer than otherwise.
  For example, the following will boot Aboriginal Linux to the login
  prompt about 6 seconds on my system (using TCG, not KVM):

  wget 
http://landley.net/aboriginal/downloads/old/binaries/1.4.5/system-image-i686.tar.gz
  gunzip https://bugs.launchpad.net/qemu/+bug/1774677/+subscriptions

[Qemu-devel] [Bug 1774412] [NEW] -icount sleep=on|off documentation is confusing

[Andreas Gustafsson]

Public bug reported:

The documentation for the -icount option in the qemu man page says:

"When the virtual cpu is sleeping, the virtual time will advance at
default speed unless sleep=on|off is specified. With sleep=on|off, the
virtual time will jump to the next timer deadline instantly whenever the
virtual cpu goes to sleep mode and will not advance if no timer is
enabled."

Taking this literally and specifying "sleep=on|off" on the command line does 
not work, so presumably the two instances of "sleep=on|off" should be either 
"sleep=on" or "sleep=off",
whichever is correct :)

Also, the synopsis line "-icount
[shift=N|auto][,rr=record|replay,rrfile=filename,rrsnapshot=snapshot"
fails to mention the sleep keyword at all.

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  -icount sleep=on|off documentation is confusing

Status in QEMU:
  New

Bug description:
  The documentation for the -icount option in the qemu man page says:

  "When the virtual cpu is sleeping, the virtual time will advance at
  default speed unless sleep=on|off is specified. With sleep=on|off, the
  virtual time will jump to the next timer deadline instantly whenever
  the virtual cpu goes to sleep mode and will not advance if no timer is
  enabled."

  Taking this literally and specifying "sleep=on|off" on the command line does 
not work, so presumably the two instances of "sleep=on|off" should be either 
"sleep=on" or "sleep=off",
  whichever is correct :)

  Also, the synopsis line "-icount
  [shift=N|auto][,rr=record|replay,rrfile=filename,rrsnapshot=snapshot"
  fails to mention the sleep keyword at all.

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

[Qemu-devel] [Bug 1767126] [NEW] Man page documents qemu -drive if=scsi but it no longer works

[Andreas Gustafsson]

Public bug reported:

The qemu man page section documenting the -drive option contains

   if=interface
   This option defines on which type on interface the drive is
   connected.  Available types are: ide, scsi, sd, mtd, floppy,
   pflash, virtio, none.

but if=scsi no longer works as of version 2.12.0.

If you really have to make backwards incompatible changes, it would be
helpful if you could at least document them.

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  Man page documents qemu -drive if=scsi but it no longer works

Status in QEMU:
  New

Bug description:
  The qemu man page section documenting the -drive option contains

 if=interface
 This option defines on which type on interface the drive is
 connected.  Available types are: ide, scsi, sd, mtd, floppy,
 pflash, virtio, none.

  but if=scsi no longer works as of version 2.12.0.

  If you really have to make backwards incompatible changes, it would be
  helpful if you could at least document them.

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

[Qemu-devel] [Bug 1654137] Re: Ctrl-A b not working in 2.8.0

[Andreas Gustafsson]

Fixed on qemu mainline in 1b2503fcf7b5932c5a3779ca2ceb92bd403c4ee7 -
thanks.  I have backported the fix to pkgsrc as qemu-2.11.1nb3.


** Changed in: qemu
   Status: Confirmed => Fix Committed

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

Title:
  Ctrl-A b not working in 2.8.0

Status in QEMU:
  Fix Committed

Bug description:
  With a recent update from 2.7.0 to 2.8.0 I have discovered that I can
  no longer send a "break" to the VM.  Ctrl-A b is simply ignored.
  Other Ctrl-A sequences seem to work correctly.

  This is on a NetBSD amd64 system, version 7.99.53, and qemu was
  installed on this system from source.

  Reverting to the previous install restores "break" capability.

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

[Qemu-devel] [Bug 1654137] Re: Ctrl-A b not working in 2.8.0

[Andreas Gustafsson]

This regression is still unfixed three months after being reported, and
it's rendering qemu 2.11.1 unusable for my present use case, so I just
reverted my system to the ever reliable qemu 0.15.1.

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

Title:
  Ctrl-A b not working in 2.8.0

Status in QEMU:
  Confirmed

Bug description:
  With a recent update from 2.7.0 to 2.8.0 I have discovered that I can
  no longer send a "break" to the VM.  Ctrl-A b is simply ignored.
  Other Ctrl-A sequences seem to work correctly.

  This is on a NetBSD amd64 system, version 7.99.53, and qemu was
  installed on this system from source.

  Reverting to the previous install restores "break" capability.

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

[Qemu-devel] [Bug 1481272] Re: main-loop: WARNING: I/O thread spun for 1000 iterations

[Andreas Gustafsson]

I no longer see the "WARNING: I/O thread spun for 1000 iterations"
message.  A bisection showed that it disappeared with the following
commit:

commit e330c118f2a5a5365409b123cd0dd2c7d575bf05
Author: Paolo Bonzini 
Date:   Fri Mar 3 11:51:07 2017 +0100

main-loop: remove now unnecessary optimization

This optimization is not necessary anymore, because the vCPU now drops
the I/O thread lock even with TCG.  Drop it to simplify the code and
avoid the "I/O thread spun for 1000 iterations" warning.

Reviewed-by: Alex Bennée 
Reviewed-by: Edgar E. Iglesias 
Signed-off-by: Paolo Bonzini 

The amount of system time consumed by the qemu process, which had
incrased 300-fold with commit 05e514b1d4d5bd4209e2c8bbc76ff05c85a235f3,
is also back to normal.

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

Title:
  main-loop: WARNING: I/O thread spun for 1000 iterations

Status in QEMU:
  New

Bug description:
  I compile the latest qemu to launch a VM but the monitor output the
  "main-loop: WARNING: I/O thread spun for 1000 iterations".

  # /usr/local/bin/qemu-system-x86_64 -name rhel6 -S -no-kvm -m 1024M -realtime 
mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 
c9dd2a5c-40f2-fd3d-3c54-9cd84f8b9174 -rtc base=utc  -drive 
file=/home/samba-share/ubuntu.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=none
 -device 
virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=disk,serial=425618d4-871f-4021-bc5d-bcd7f1b5ca9c,bootindex=0
 -vnc :1 -boot menu=on -monitor stdio
  QEMU 2.3.93 monitor - type 'help' for more information
  (qemu) c
  (qemu) main-loop: WARNING: I/O thread spun for 1000 iterations   
<---

  qemu]# git branch -v
  * master   e95edef Merge remote-tracking branch 
'remotes/sstabellini/tags/xen-migration-2.4-tag' into staging

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

[Qemu-devel] [Bug 1654137] Re: Ctrl-A b not working in 2.8.0

[Andreas Gustafsson]

This is broken again as of revision
7398166ddf7c6dbbc9cae6ac69bb2feda14b40ac.

Bisection shows it was broken by commit 
df85a78bf83d85627de27f492e78e73bbbd3df4a,
"char: move mux to its own file".  Somewhat confusingly, this commit predates 
the fix
(fb5e19d2e1472e96d72d5e4d89c20033f8ab345c), but it is part of a branch that was 
merged
after the fix, in merge commit 2d6752d38d8acda6aae674a72b72be05482a58eb.  
Apparently
this caused a reversion to an old version of the mux code that still has the 
bug.

Credit for discovering the regression goes to Paul Goyette.

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

Title:
  Ctrl-A b not working in 2.8.0

Status in QEMU:
  Fix Released

Bug description:
  With a recent update from 2.7.0 to 2.8.0 I have discovered that I can
  no longer send a "break" to the VM.  Ctrl-A b is simply ignored.
  Other Ctrl-A sequences seem to work correctly.

  This is on a NetBSD amd64 system, version 7.99.53, and qemu was
  installed on this system from source.

  Reverting to the previous install restores "break" capability.

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

[Qemu-devel] [Bug 1743191] [NEW] Interacting with NetBSD serial console boot blocks no longer works

[Andreas Gustafsson]

Public bug reported:

The NetBSD boot blocks display a menu allowing the user to make a
selection using the keyboard.  For example, when booting a NetBSD
installation CD-ROM, the menu looks like this:

 1. Install NetBSD
 2. Install NetBSD (no ACPI)
 3. Install NetBSD (no ACPI, no SMP)
 4. Drop to boot prompt

Choose an option; RETURN for default; SPACE to stop countdown.
Option 1 will be chosen in 30 seconds.

When booting NetBSD in a recent qemu using an emulated serial console,
making this menu selection no longer works: when you type the selected
number, the keyboard input is ignored, and the 30-second countdown
continues.  In older versions of qemu, it works.

To reproduce the problem, run:

   wget 
http://ftp.netbsd.org/pub/NetBSD/NetBSD-7.1.1/amd64/installation/cdrom/boot-com.iso
   qemu-system-x86_64 -nographic -cdrom boot-com.iso

During the 30-second countdown, press 4

Expected behavior: The countdown stops and you get a ">" prompt

Incorrect behavior: The countdown continues

There may also be some corruption of the terminal output; for example,
"Option 1 will be chosen in 30 seconds" may be displayed as "Option 1
will be chosen in p0 seconds".

Using bisection, I have determined that the problem appeared with qemu
commit 083fab0290f2c40d3d04f7f22eed9c8f2d5b6787, in which seabios was
updated to 1.11 prerelease, and the problem is still there as of
commit 7398166ddf7c6dbbc9cae6ac69bb2feda14b40ac.  The host operating
system used for the tests was Debian 9 x86_64.

Credit for discovering this bug goes to Paul Goyette.

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: regression

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

Title:
  Interacting with NetBSD serial console boot blocks no longer works

Status in QEMU:
  New

Bug description:
  The NetBSD boot blocks display a menu allowing the user to make a
  selection using the keyboard.  For example, when booting a NetBSD
  installation CD-ROM, the menu looks like this:

   1. Install NetBSD
   2. Install NetBSD (no ACPI)
   3. Install NetBSD (no ACPI, no SMP)
   4. Drop to boot prompt

  Choose an option; RETURN for default; SPACE to stop countdown.
  Option 1 will be chosen in 30 seconds.

  When booting NetBSD in a recent qemu using an emulated serial console,
  making this menu selection no longer works: when you type the selected
  number, the keyboard input is ignored, and the 30-second countdown
  continues.  In older versions of qemu, it works.

  To reproduce the problem, run:

 wget 
http://ftp.netbsd.org/pub/NetBSD/NetBSD-7.1.1/amd64/installation/cdrom/boot-com.iso
 qemu-system-x86_64 -nographic -cdrom boot-com.iso

  During the 30-second countdown, press 4

  Expected behavior: The countdown stops and you get a ">" prompt

  Incorrect behavior: The countdown continues

  There may also be some corruption of the terminal output; for example,
  "Option 1 will be chosen in 30 seconds" may be displayed as "Option 1
  will be chosen in p0 seconds".

  Using bisection, I have determined that the problem appeared with qemu
  commit 083fab0290f2c40d3d04f7f22eed9c8f2d5b6787, in which seabios was
  updated to 1.11 prerelease, and the problem is still there as of
  commit 7398166ddf7c6dbbc9cae6ac69bb2feda14b40ac.  The host operating
  system used for the tests was Debian 9 x86_64.

  Credit for discovering this bug goes to Paul Goyette.

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

Re: [Qemu-devel] [PATCH] oslib-posix: check for posix_memalign in configure script

[Andreas Gustafsson]

Peter Maydell wrote:
> Can we put this through the -trivial tree? (cc'd)

I'm not sufficiently familiar with the intenal workflows of the qemu
project to give a meaningful answer to that question.
-- 
Andreas Gustafsson, g...@gson.org

[Qemu-devel] [PATCH] slirp: disable Nagle in outgoing connections

[Andreas Gustafsson]

slirp: disable Nagle in outgoing connections

When setting up an outgoing user mode networking TCP connection,
disable the Nagle algorithm in the host-side connection.  Either the
guest is already doing Nagle, in which case there is no point in doing
it twice, or it has chosen to disable it, in which case we should
respect that choice.

This change speeds up GDB remote debugging over TCP over user mode
networking (with GDB runing on the guest) by multiple orders of
magnitude, and has been part of the local patches applied by pkgsrc
since 2012 with no reported ill effects.

Signed-off-by: Andreas Gustafsson <g...@gson.org>
---
 slirp/tcp_subr.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/slirp/tcp_subr.c b/slirp/tcp_subr.c
index da0d53743f..8d0f94b75f 100644
--- a/slirp/tcp_subr.c
+++ b/slirp/tcp_subr.c
@@ -416,6 +416,8 @@ int tcp_fconnect(struct socket *so, unsigned short af)
 socket_set_fast_reuse(s);
 opt = 1;
 qemu_setsockopt(s, SOL_SOCKET, SO_OOBINLINE, , sizeof(opt));
+opt = 1;
+qemu_setsockopt(s, IPPROTO_TCP, TCP_NODELAY, , sizeof(opt));
 
 addr = so->fhost.ss;
 DEBUG_CALL(" connect()ing")
-- 
2.15.1

[Qemu-devel] [PATCH] oslib-posix: check for posix_memalign in configure script

[Andreas Gustafsson]

Check for the presence of posix_memalign() in the configure script,
not using "defined(_POSIX_C_SOURCE) && !defined(__sun__)".  This
lets qemu use posix_memalign() on NetBSD versions that have it,
instead of falling back to valloc() which is wasteful when the
required alignment is smaller than a page.

Signed-off-by: Andreas Gustafsson <g...@gson.org>
---
 configure  | 19 +++
 util/oslib-posix.c |  2 +-
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 100309c33f..9f8580332a 100755
--- a/configure
+++ b/configure
@@ -4573,6 +4573,21 @@ if compile_prog "" "" ; then
 posix_madvise=yes
 fi
 
+##
+# check if we have posix_memalign()
+
+posix_memalign=no
+cat > $TMPC << EOF
+#include 
+int main(void) {
+void *p;
+return posix_memalign(, 8, 8);
+}
+EOF
+if compile_prog "" "" ; then
+posix_memalign=yes
+fi
+
 ##
 # check if we have posix_syslog
 
@@ -5542,6 +5557,7 @@ echo "preadv support$preadv"
 echo "fdatasync $fdatasync"
 echo "madvise   $madvise"
 echo "posix_madvise $posix_madvise"
+echo "posix_memalign$posix_memalign"
 echo "libcap-ng support $cap_ng"
 echo "vhost-net support $vhost_net"
 echo "vhost-scsi support $vhost_scsi"
@@ -6015,6 +6031,9 @@ fi
 if test "$posix_madvise" = "yes" ; then
   echo "CONFIG_POSIX_MADVISE=y" >> $config_host_mak
 fi
+if test "$posix_memalign" = "yes" ; then
+  echo "CONFIG_POSIX_MEMALIGN=y" >> $config_host_mak
+fi
 
 if test "$spice" = "yes" ; then
   echo "CONFIG_SPICE=y" >> $config_host_mak
diff --git a/util/oslib-posix.c b/util/oslib-posix.c
index 77369c92ce..4655bc1f89 100644
--- a/util/oslib-posix.c
+++ b/util/oslib-posix.c
@@ -105,7 +105,7 @@ void *qemu_try_memalign(size_t alignment, size_t size)
 alignment = sizeof(void*);
 }
 
-#if defined(_POSIX_C_SOURCE) && !defined(__sun__)
+#if defined(CONFIG_POSIX_MEMALIGN)
 int ret;
 ret = posix_memalign(, alignment, size);
 if (ret != 0) {
-- 
2.15.1

[Qemu-devel] [Bug 1481272] Re: main-loop: WARNING: I/O thread spun for 1000 iterations

[Andreas Gustafsson]

http://gnats.netbsd.org/52184 looks like it may be related.

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

Title:
  main-loop: WARNING: I/O thread spun for 1000 iterations

Status in QEMU:
  New

Bug description:
  I compile the latest qemu to launch a VM but the monitor output the
  "main-loop: WARNING: I/O thread spun for 1000 iterations".

  # /usr/local/bin/qemu-system-x86_64 -name rhel6 -S -no-kvm -m 1024M -realtime 
mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 
c9dd2a5c-40f2-fd3d-3c54-9cd84f8b9174 -rtc base=utc  -drive 
file=/home/samba-share/ubuntu.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=none
 -device 
virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=disk,serial=425618d4-871f-4021-bc5d-bcd7f1b5ca9c,bootindex=0
 -vnc :1 -boot menu=on -monitor stdio
  QEMU 2.3.93 monitor - type 'help' for more information
  (qemu) c
  (qemu) main-loop: WARNING: I/O thread spun for 1000 iterations   
<---

  qemu]# git branch -v
  * master   e95edef Merge remote-tracking branch 
'remotes/sstabellini/tags/xen-migration-2.4-tag' into staging

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

[Qemu-devel] [Bug 1645355] Re: x86: singlestepping through SYSCALL instruction causes exception in kernelspace

[Andreas Gustafsson]

I believe this is fixed in the qemu git mainline (but not yet in any release)
by the following commits:

 commit c52ab08aee6f7d4717fc6b517174043126bd302f
 Author: Doug Evans 
 Date:   Tue Dec 6 23:06:30 2016 +

 target-i386: Fix eflags.TF/#DB handling of syscall/sysret insns

 The syscall and sysret instructions behave a bit differently:
 TF is checked after the instruction completes.
 This allows the o/s to disable #DB at a syscall by adding TF to FMASK.
 And then when the sysret is executed the #DB is taken "as if" the
 syscall insn just completed.

 commit 410e98146ffde201ab4c778823ac8beaa74c4c3f
 Author: Doug Evans 
 Date:   Sat Dec 24 20:29:33 2016 +

 target/i386: Fix bad patch application to translate.c

 In commit c52ab08aee6f7d4717fc6b517174043126bd302f,
 the patch snippet for the "syscall" insn got applied to "iret".

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

Title:
  x86: singlestepping through SYSCALL instruction causes exception in
  kernelspace

Status in QEMU:
  New

Bug description:
  Hi,

  The bug was originally reported [1] and [2] here. There is a problem
  inside QEMU with singlestepping from userspace until SYSCALL
  instruction is reached. The OS has in FMASK TF bit set, therefore
  there should be no singlestepping exception when transitioning to
  kernelmode. But, inside QEMU there is (TF is clear seems FMASK is
  applied). See below for further details.

  The reproducer is available at [2].

  Here is the original text with some minor clarifications:

  It seems that there is something wrong with QEMU with respect to
  handle the singlestepping and AMD64 syscall instruction.

  The AMD "syscall" instruction will clear defined flag in the FMASK
  MSR. Normally the TF flag is set there, so the first instruction when
  kernel is entered after syscall won't cause single step exception in
  the kernel.

  The observed scenario is a unhandled singlestep fault in the kernel or
  host reboot or QEMU crash.

  The possible way how to reproduce it is to single step through any
  function (in userspace) which does "syscall" instruction. After
  syscall is entered QEMU will trigger singlestepping exception in the
  kernel despite that the TF is set in FMASK MSR. Real HW behaves
  correctly and does not trigger this exception.

  
  What is interesting is that I was not able to trigger it if I just enabled TF 
and did the syscall instruction, perhaps for this bug is somewhat important to 
have TF set for previous few instruction.

  
  I have stumbled to this problem while working with our custom OS. However 
after some googling I found out that the NetBSD guys (CCed) are having very 
similar problem and I asked them to prepare a ISO image where the problem ends 
with QEMU SIGSEGV or host reboot. 

  Thanks
  Rudolf

  [1] https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg02289.html
  [2] http://gnats.netbsd.org/49603

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

[Qemu-devel] [Bug 1654137] Re: Ctrl-A b not working in 2.8.0

[Andreas Gustafsson]

I am also seeing this problem.  In case it was not clear from Paul's
original report, it affects guests using a serial console.

Also, it is not specific to NetBSD.  I can reproduce it using a Linux
guest on a Linux host, by running the following on a Debian 8 system:

  wget 
http://landley.net/aboriginal/downloads/old/binaries/1.4.5/system-image-i686.tar.gz
  tar xfz system-image-i686.tar.gz 
  cd system-image-i686
  sh run-emulator.sh 

and typing Control-A b m once the guest has started.

Using qemu 2.1.2, this successfully causes the guest to print a memory
usage summary.  Using current qemu sources from git
(dbe2b65566e76d3c3a0c3358285c0336ac61e757), nothing happens.

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

Title:
  Ctrl-A b not working in 2.8.0

Status in QEMU:
  New

Bug description:
  With a recent update from 2.7.0 to 2.8.0 I have discovered that I can
  no longer send a "break" to the VM.  Ctrl-A b is simply ignored.
  Other Ctrl-A sequences seem to work correctly.

  This is on a NetBSD amd64 system, version 7.99.53, and qemu was
  installed on this system from source.

  Reverting to the previous install restores "break" capability.

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

[Qemu-devel] [Bug 1399943] Re: qemu-system-sparc loses serial console data on EAGAIN

[Andreas Gustafsson]

Hi Mark,

I have now upgraded to qemu 2.8 and successfully run more than 20
scripted installs of NetBSD/sparc over a serial console without
failures, so it does indeed look like the bug is now fixed, and the bug
report can be closed.

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

Title:
  qemu-system-sparc loses serial console data on EAGAIN

Status in QEMU:
  New

Bug description:
  When running a guest OS with a serial console under 
  "qemu-system-sparc -nographic", parts of the serial console output
  are sometimes lost.

  This happens when a write() to standard output by qemu returns EAGAIN,
  as may be the case when the guest is generating console output faster
  than the tty (or pty/pipe/socket, etc.) connected to qemu's standard
  output accepts it. The bug affects all releases of qemu since 1.5,
  which was the first version to set stdout to O_NONBLOCK mode. Version
  1.4.2 and earlier work correctly.

  To reproduce the bug, you will need a guest OS configured with a
  serial console, and a host with a slow tty.  The attached shell script
  "sparc-test.sh" does this by using Aboriginal Linux as the serial
  console guest, and a pty controlled by a Python script and the
  "pexpect" Python module as the slow tty. A "seq" command is sent
  to the guest to generate 100,000 lines of output containing sequential
  integers, and the output is checked for gaps. The script limits the
  tty output rate by occasionally sleeping for 1/10 of a second.

  This bug was originally reported against qemu-system-i386 as 
  bug #1335444, and has since been fixed in qemu-system-i386,
  but remains in qemu-system-sparc as of today's git sources 
  (d00e6cddc220de993573dfb5fd160ac72ccd49ab).  I am opening
  this separate bug for the sparc case because I was asked
  to do so by Paolo Bonzini in #1335444.

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

[Qemu-devel] [Bug 1399943] Re: qemu-system-sparc loses serial console data on EAGAIN

[Andreas Gustafsson]

I have now run some more tests, and I'm still seeing occasional failures
in the scripted NetBSD installs that look like console data loss when
using qemu 2.7.0, with maybe one in ten installs failing.  I have seen
no failures so far using the git master.  So it looks like the bug is
fixed in git, but not yet in 2.7.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/1399943

Title:
  qemu-system-sparc loses serial console data on EAGAIN

Status in QEMU:
  New

Bug description:
  When running a guest OS with a serial console under 
  "qemu-system-sparc -nographic", parts of the serial console output
  are sometimes lost.

  This happens when a write() to standard output by qemu returns EAGAIN,
  as may be the case when the guest is generating console output faster
  than the tty (or pty/pipe/socket, etc.) connected to qemu's standard
  output accepts it. The bug affects all releases of qemu since 1.5,
  which was the first version to set stdout to O_NONBLOCK mode. Version
  1.4.2 and earlier work correctly.

  To reproduce the bug, you will need a guest OS configured with a
  serial console, and a host with a slow tty.  The attached shell script
  "sparc-test.sh" does this by using Aboriginal Linux as the serial
  console guest, and a pty controlled by a Python script and the
  "pexpect" Python module as the slow tty. A "seq" command is sent
  to the guest to generate 100,000 lines of output containing sequential
  integers, and the output is checked for gaps. The script limits the
  tty output rate by occasionally sleeping for 1/10 of a second.

  This bug was originally reported against qemu-system-i386 as 
  bug #1335444, and has since been fixed in qemu-system-i386,
  but remains in qemu-system-sparc as of today's git sources 
  (d00e6cddc220de993573dfb5fd160ac72ccd49ab).  I am opening
  this separate bug for the sparc case because I was asked
  to do so by Paolo Bonzini in #1335444.

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

[Qemu-devel] [Bug 1399943] Re: qemu-system-sparc loses serial console data on EAGAIN

[Andreas Gustafsson]

Hi Mark,

I tested the git master and the 2.7.0 release, and both successfully
executed the scripted NetBSD/sparc install that had been failing since
1.5.

So it does indeed look like the bug has been fixed.  I will still run a
few more tests to be sure, and if those also pass, this bug report can
be closed.  Thank you.

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

Title:
  qemu-system-sparc loses serial console data on EAGAIN

Status in QEMU:
  New

Bug description:
  When running a guest OS with a serial console under 
  "qemu-system-sparc -nographic", parts of the serial console output
  are sometimes lost.

  This happens when a write() to standard output by qemu returns EAGAIN,
  as may be the case when the guest is generating console output faster
  than the tty (or pty/pipe/socket, etc.) connected to qemu's standard
  output accepts it. The bug affects all releases of qemu since 1.5,
  which was the first version to set stdout to O_NONBLOCK mode. Version
  1.4.2 and earlier work correctly.

  To reproduce the bug, you will need a guest OS configured with a
  serial console, and a host with a slow tty.  The attached shell script
  "sparc-test.sh" does this by using Aboriginal Linux as the serial
  console guest, and a pty controlled by a Python script and the
  "pexpect" Python module as the slow tty. A "seq" command is sent
  to the guest to generate 100,000 lines of output containing sequential
  integers, and the output is checked for gaps. The script limits the
  tty output rate by occasionally sleeping for 1/10 of a second.

  This bug was originally reported against qemu-system-i386 as 
  bug #1335444, and has since been fixed in qemu-system-i386,
  but remains in qemu-system-sparc as of today's git sources 
  (d00e6cddc220de993573dfb5fd160ac72ccd49ab).  I am opening
  this separate bug for the sparc case because I was asked
  to do so by Paolo Bonzini in #1335444.

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

[Qemu-devel] [Bug 1399943] Re: qemu-system-sparc loses serial console data on EAGAIN

[Andreas Gustafsson]

The automated test infrastructure of the NetBSD project is based on
qemu, and runs some 100 CPU-hours per day of full system tests of
NetBSD-current on emulated i386, amd64, and sparc systems.

This is all still running on qemu 0.15 (!).  The main obstacle to
upgrading to a current version of qemu is this three-year-old regression
which breaks the sparc tests by losing some of the serial console output.

It would be really nice if this could be fixed.

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

Title:
  qemu-system-sparc loses serial console data on EAGAIN

Status in QEMU:
  New

Bug description:
  When running a guest OS with a serial console under 
  "qemu-system-sparc -nographic", parts of the serial console output
  are sometimes lost.

  This happens when a write() to standard output by qemu returns EAGAIN,
  as may be the case when the guest is generating console output faster
  than the tty (or pty/pipe/socket, etc.) connected to qemu's standard
  output accepts it. The bug affects all releases of qemu since 1.5,
  which was the first version to set stdout to O_NONBLOCK mode. Version
  1.4.2 and earlier work correctly.

  To reproduce the bug, you will need a guest OS configured with a
  serial console, and a host with a slow tty.  The attached shell script
  "sparc-test.sh" does this by using Aboriginal Linux as the serial
  console guest, and a pty controlled by a Python script and the
  "pexpect" Python module as the slow tty. A "seq" command is sent
  to the guest to generate 100,000 lines of output containing sequential
  integers, and the output is checked for gaps. The script limits the
  tty output rate by occasionally sleeping for 1/10 of a second.

  This bug was originally reported against qemu-system-i386 as 
  bug #1335444, and has since been fixed in qemu-system-i386,
  but remains in qemu-system-sparc as of today's git sources 
  (d00e6cddc220de993573dfb5fd160ac72ccd49ab).  I am opening
  this separate bug for the sparc case because I was asked
  to do so by Paolo Bonzini in #1335444.

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

[Qemu-devel] [Bug 1426472] [NEW] Recent regression: segfault on startup with -snapshot

[Andreas Gustafsson]

Public bug reported:

As of git revision 041ccc922ee474693a2869d4e3b59e920c739bc0, qemu
segfaults on startup when I try to boot a hard disk image with the
-snapshot option.

To reproduce:

  wget http://wiki.qemu.org/download/linux-0.2.img.bz2
  bunzip2 linux-0.2.img.bz2 
  qemu-system-i386 -hda linux-0.2.img -snapshot

When I run this, qemu-system-i386 crashes with a segmentation fault.
This is on a Debian 7 amd64 host.

git bisect implicates the following commit:

commit a464982499b2f637f6699e3d03e0a9d2e0b5288b
Author: Paolo Bonzini pbonz...@redhat.com
Date:   Wed Feb 11 17:15:18 2015 +0100

rcu: run RCU callbacks under the BQL

This needs to go away sooner or later, but one complication is the
complex VFIO data structures that are modified in instance_finalize.
Take a shortcut for now.

Reviewed-by: Michael Roth mdr...@linux.vnet.ibm.com
Tested-by: Michael Roth mdr...@linux.vnet.ibm.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  Recent regression: segfault on startup with -snapshot

Status in QEMU:
  New

Bug description:
  As of git revision 041ccc922ee474693a2869d4e3b59e920c739bc0, qemu
  segfaults on startup when I try to boot a hard disk image with the
  -snapshot option.

  To reproduce:

wget http://wiki.qemu.org/download/linux-0.2.img.bz2
bunzip2 linux-0.2.img.bz2 
qemu-system-i386 -hda linux-0.2.img -snapshot

  When I run this, qemu-system-i386 crashes with a segmentation fault.
  This is on a Debian 7 amd64 host.

  git bisect implicates the following commit:

  commit a464982499b2f637f6699e3d03e0a9d2e0b5288b
  Author: Paolo Bonzini pbonz...@redhat.com
  Date:   Wed Feb 11 17:15:18 2015 +0100

  rcu: run RCU callbacks under the BQL

  This needs to go away sooner or later, but one complication is the
  complex VFIO data structures that are modified in instance_finalize.
  Take a shortcut for now.

  Reviewed-by: Michael Roth mdr...@linux.vnet.ibm.com
  Tested-by: Michael Roth mdr...@linux.vnet.ibm.com
  Signed-off-by: Paolo Bonzini pbonz...@redhat.com

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

[Qemu-devel] [Bug 1335444] Re: qemu loses serial console data on EAGAIN

[Andreas Gustafsson]

A separate bug report has now been filed for the sparc case as
requested: bug #1399943.

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

Title:
  qemu loses serial console data on EAGAIN

Status in QEMU:
  Fix Released

Bug description:
  When running a guest OS with a serial console under qemu-system-i386
  -nographic, parts of the serial console output are sometimes lost.

  This happens when a write() to standard output by qemu returns EAGAIN,
  as may be the case when the guest is generating console output faster
  than the tty (or pty/pipe/socket, etc.) connected to qemu's standard
  output accepts it.  The bug affects all releases of qemu since 1.5,
  which was the first version to set stdout to O_NONBLOCK mode.  Version
  1.4.2 and earlier work correctly.

  To reproduce the bug, you will need a guest OS configured with a
  serial console, and a host with a slow tty.  Two different methods
  of setting this up are outlined below.

  
  Method 1

  This fully automated test uses the pexpect Python module to run qemu
  under a pty, with an Aboriginal Linux guest.  A seq command is sent
  to the guest to generate 100,000 lines of output containing sequential
  integers, and the output is checked for gaps.  The script limits the
  tty output rate by occasionally sleeping for 1/10 of a second.

  Run the following commands in a Bourne shell:

  wget 
http://landley.net/aboriginal/downloads/binaries/system-image-i686.tar.bz2
  bunzip2 system-image-i686.tar.bz2 | tar xf -
  cd system-image-i686
  cat \END test.py
  #!/usr/bin/python
  import sys
  import time
  import pexpect
  n = 10
  child = pexpect.spawn('./run-emulator.sh', logfile = sys.stderr)
  child.expect(/home #)
  child.send(seq -f '%%08.0f' 0 %d\r % (n - 1))
  for i in range(n):
  child.expect(([0-9]+), timeout = 5)
  got = int(child.match.group(1))
  if got != i:
  print sys.stderr, \nFAIL: expected %d, got %d % (i, got)
  sys.exit(1)
  if i % 100 == 0:
  time.sleep(0.1)
  child.send(exit)
  print sys.stderr, \nPASS
  sys.exit(0)
  END
  python test.py

  This will output PASS if the console output contains the 100,000
  sequential integers as expected, or FAIL if parts of the output
  are missing due to the bug.

  
  Method 2

  This method does not require Python or pexpect.  Instead, the qemu source
  is modified to simulate a simulate a slow tty by forcing an EAGAIN return
  from every other write().  If qemu were working correctly, this
  change would not cause any data loss, because the writes would be
  retried, but in actuality, they are not retried, and the end result is
  that every other character in the guest output will be missing.

  Apply the following patch to the qemu source (this is against 2.0.0):

  --- ../qemu-2.0.0.orig/qemu-char.c  2014-04-17 16:44:45.0 +0300
  +++ ./qemu-char.c   2014-06-20 16:47:18.0 +0300
  @@ -779,6 +779,17 @@
   size_t offset = 0;
   GIOStatus status = G_IO_STATUS_NORMAL;

  +/*
  + * Simulate a tty with a limited output buffer by returning
  + * EAGAIN on every second call.
  + */
  +static unsigned int toggle = 0;
  +toggle++;
  +if (toggle  1) {
  +   errno = EAGAIN;
  +   return -1;
  +}
  +
   while (offset  len  status == G_IO_STATUS_NORMAL) {
   gsize bytes_written = 0;

  Build and install qemu.

  Run any serial console guest.  You could use the same Aboriginal Linux image
  as in Method 1, or for example the PLD RescueCD:

wget http://rescuecd.pld-linux.org/download/2011-02-12/x86/RCDx86_11_02.iso
qemu-system-i386 -nographic -cdrom RCDx86_11_02.iso

  If this command is run with an unmodified qemu, a set of boot messages
  will appear, starting with:

ISOLINUX 4.03 2010-10-22  Copyright (C) 1994-2010 H. Peter Anvin et
  al

  When qemu has been patched to simulate EAGAIN returns, every other
  character in the boot messages will be missing, so that the first line
  of output will instead read:

SLNX40 001-2 oyih C 9421 .PtrAvne l

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

[Qemu-devel] [Bug 1399943] [NEW] qemu-system-sparc loses serial console data on EAGAIN

[Andreas Gustafsson]

Public bug reported:

When running a guest OS with a serial console under 
qemu-system-sparc -nographic, parts of the serial console output
are sometimes lost.

This happens when a write() to standard output by qemu returns EAGAIN,
as may be the case when the guest is generating console output faster
than the tty (or pty/pipe/socket, etc.) connected to qemu's standard
output accepts it. The bug affects all releases of qemu since 1.5,
which was the first version to set stdout to O_NONBLOCK mode. Version
1.4.2 and earlier work correctly.

To reproduce the bug, you will need a guest OS configured with a
serial console, and a host with a slow tty.  The attached shell script
sparc-test.sh does this by using Aboriginal Linux as the serial
console guest, and a pty controlled by a Python script and the
pexpect Python module as the slow tty. A seq command is sent
to the guest to generate 100,000 lines of output containing sequential
integers, and the output is checked for gaps. The script limits the
tty output rate by occasionally sleeping for 1/10 of a second.

This bug was originally reported against qemu-system-i386 as 
bug #1335444, and has since been fixed in qemu-system-i386,
but remains in qemu-system-sparc as of today's git sources 
(d00e6cddc220de993573dfb5fd160ac72ccd49ab).  I am opening
this separate bug for the sparc case because I was asked
to do so by Paolo Bonzini in #1335444.

** Affects: qemu
 Importance: Undecided
 Status: New

** Attachment added: Shell script for reproducing the bug
   
https://bugs.launchpad.net/bugs/1399943/+attachment/4275291/+files/sparc-test.sh

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

Title:
  qemu-system-sparc loses serial console data on EAGAIN

Status in QEMU:
  New

Bug description:
  When running a guest OS with a serial console under 
  qemu-system-sparc -nographic, parts of the serial console output
  are sometimes lost.

  This happens when a write() to standard output by qemu returns EAGAIN,
  as may be the case when the guest is generating console output faster
  than the tty (or pty/pipe/socket, etc.) connected to qemu's standard
  output accepts it. The bug affects all releases of qemu since 1.5,
  which was the first version to set stdout to O_NONBLOCK mode. Version
  1.4.2 and earlier work correctly.

  To reproduce the bug, you will need a guest OS configured with a
  serial console, and a host with a slow tty.  The attached shell script
  sparc-test.sh does this by using Aboriginal Linux as the serial
  console guest, and a pty controlled by a Python script and the
  pexpect Python module as the slow tty. A seq command is sent
  to the guest to generate 100,000 lines of output containing sequential
  integers, and the output is checked for gaps. The script limits the
  tty output rate by occasionally sleeping for 1/10 of a second.

  This bug was originally reported against qemu-system-i386 as 
  bug #1335444, and has since been fixed in qemu-system-i386,
  but remains in qemu-system-sparc as of today's git sources 
  (d00e6cddc220de993573dfb5fd160ac72ccd49ab).  I am opening
  this separate bug for the sparc case because I was asked
  to do so by Paolo Bonzini in #1335444.

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

[Qemu-devel] [Bug 1368791] [NEW] qemu build fails on Ubuntu 10.04 LTS since recent pixman changes

[Andreas Gustafsson]

Public bug reported:

Since commit 0dfa7e30126364c434a48cb37a1a41119e536c2a, the qemu git
mainline no longer builds on Ubuntu 10.04 LTS.  The build fails with:

  CCui/input.o
ui/qemu-pixman.c: In function 'qemu_pixelformat_from_pixman':
ui/qemu-pixman.c:42: error: 'PIXMAN_TYPE_RGBA' undeclared (first use in this 
function)
ui/qemu-pixman.c:42: error: (Each undeclared identifier is reported only once
ui/qemu-pixman.c:42: error: for each function it appears in.)
make: *** [ui/qemu-pixman.o] Error 1

Andreas Gustafsson, g...@gson.org

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  qemu build fails on Ubuntu 10.04 LTS since recent pixman changes

Status in QEMU:
  New

Bug description:
  Since commit 0dfa7e30126364c434a48cb37a1a41119e536c2a, the qemu git
  mainline no longer builds on Ubuntu 10.04 LTS.  The build fails with:

CCui/input.o
  ui/qemu-pixman.c: In function 'qemu_pixelformat_from_pixman':
  ui/qemu-pixman.c:42: error: 'PIXMAN_TYPE_RGBA' undeclared (first use in this 
function)
  ui/qemu-pixman.c:42: error: (Each undeclared identifier is reported only once
  ui/qemu-pixman.c:42: error: for each function it appears in.)
  make: *** [ui/qemu-pixman.o] Error 1

  Andreas Gustafsson, g...@gson.org

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

[Qemu-devel] [Bug 1335444] Re: qemu loses serial console data on EAGAIN

[Andreas Gustafsson]

Although the bug has been fixed in qemu-system-i386 and qemu-system-
x86_64, it is still present in qemu-system-sparc. I'm attaching an
updated version of the Method 1 shell script which reproduces the
problem with qemu 2.1.0.

When I run it, the last output is:

0919
0920
092964
0965
0966
0967
FAIL: expected 921, got 92964


** Attachment added: sparc-test.sh
   
https://bugs.launchpad.net/qemu/+bug/1335444/+attachment/4179267/+files/sparc-test.sh

** Changed in: qemu
   Status: Fix Committed = New

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

Title:
  qemu loses serial console data on EAGAIN

Status in QEMU:
  New

Bug description:
  When running a guest OS with a serial console under qemu-system-i386
  -nographic, parts of the serial console output are sometimes lost.

  This happens when a write() to standard output by qemu returns EAGAIN,
  as may be the case when the guest is generating console output faster
  than the tty (or pty/pipe/socket, etc.) connected to qemu's standard
  output accepts it.  The bug affects all releases of qemu since 1.5,
  which was the first version to set stdout to O_NONBLOCK mode.  Version
  1.4.2 and earlier work correctly.

  To reproduce the bug, you will need a guest OS configured with a
  serial console, and a host with a slow tty.  Two different methods
  of setting this up are outlined below.

  
  Method 1

  This fully automated test uses the pexpect Python module to run qemu
  under a pty, with an Aboriginal Linux guest.  A seq command is sent
  to the guest to generate 100,000 lines of output containing sequential
  integers, and the output is checked for gaps.  The script limits the
  tty output rate by occasionally sleeping for 1/10 of a second.

  Run the following commands in a Bourne shell:

  wget 
http://landley.net/aboriginal/downloads/binaries/system-image-i686.tar.bz2
  bunzip2 system-image-i686.tar.bz2 | tar xf -
  cd system-image-i686
  cat \END test.py
  #!/usr/bin/python
  import sys
  import time
  import pexpect
  n = 10
  child = pexpect.spawn('./run-emulator.sh', logfile = sys.stderr)
  child.expect(/home #)
  child.send(seq -f '%%08.0f' 0 %d\r % (n - 1))
  for i in range(n):
  child.expect(([0-9]+), timeout = 5)
  got = int(child.match.group(1))
  if got != i:
  print sys.stderr, \nFAIL: expected %d, got %d % (i, got)
  sys.exit(1)
  if i % 100 == 0:
  time.sleep(0.1)
  child.send(exit)
  print sys.stderr, \nPASS
  sys.exit(0)
  END
  python test.py

  This will output PASS if the console output contains the 100,000
  sequential integers as expected, or FAIL if parts of the output
  are missing due to the bug.

  
  Method 2

  This method does not require Python or pexpect.  Instead, the qemu source
  is modified to simulate a simulate a slow tty by forcing an EAGAIN return
  from every other write().  If qemu were working correctly, this
  change would not cause any data loss, because the writes would be
  retried, but in actuality, they are not retried, and the end result is
  that every other character in the guest output will be missing.

  Apply the following patch to the qemu source (this is against 2.0.0):

  --- ../qemu-2.0.0.orig/qemu-char.c  2014-04-17 16:44:45.0 +0300
  +++ ./qemu-char.c   2014-06-20 16:47:18.0 +0300
  @@ -779,6 +779,17 @@
   size_t offset = 0;
   GIOStatus status = G_IO_STATUS_NORMAL;

  +/*
  + * Simulate a tty with a limited output buffer by returning
  + * EAGAIN on every second call.
  + */
  +static unsigned int toggle = 0;
  +toggle++;
  +if (toggle  1) {
  +   errno = EAGAIN;
  +   return -1;
  +}
  +
   while (offset  len  status == G_IO_STATUS_NORMAL) {
   gsize bytes_written = 0;

  Build and install qemu.

  Run any serial console guest.  You could use the same Aboriginal Linux image
  as in Method 1, or for example the PLD RescueCD:

wget http://rescuecd.pld-linux.org/download/2011-02-12/x86/RCDx86_11_02.iso
qemu-system-i386 -nographic -cdrom RCDx86_11_02.iso

  If this command is run with an unmodified qemu, a set of boot messages
  will appear, starting with:

ISOLINUX 4.03 2010-10-22  Copyright (C) 1994-2010 H. Peter Anvin et
  al

  When qemu has been patched to simulate EAGAIN returns, every other
  character in the boot messages will be missing, so that the first line
  of output will instead read:

SLNX40 001-2 oyih C 9421 .PtrAvne l

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

[Qemu-devel] [Bug 1335444] Re: qemu loses serial console data on EAGAIN

[Andreas Gustafsson]

With both patches applied, qemu works as expected. Thank you!

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

Title:
  qemu loses serial console data on EAGAIN

Status in QEMU:
  New

Bug description:
  When running a guest OS with a serial console under qemu-system-i386
  -nographic, parts of the serial console output are sometimes lost.

  This happens when a write() to standard output by qemu returns EAGAIN,
  as may be the case when the guest is generating console output faster
  than the tty (or pty/pipe/socket, etc.) connected to qemu's standard
  output accepts it.  The bug affects all releases of qemu since 1.5,
  which was the first version to set stdout to O_NONBLOCK mode.  Version
  1.4.2 and earlier work correctly.

  To reproduce the bug, you will need a guest OS configured with a
  serial console, and a host with a slow tty.  Two different methods
  of setting this up are outlined below.

  
  Method 1

  This fully automated test uses the pexpect Python module to run qemu
  under a pty, with an Aboriginal Linux guest.  A seq command is sent
  to the guest to generate 100,000 lines of output containing sequential
  integers, and the output is checked for gaps.  The script limits the
  tty output rate by occasionally sleeping for 1/10 of a second.

  Run the following commands in a Bourne shell:

  wget 
http://landley.net/aboriginal/downloads/binaries/system-image-i686.tar.bz2
  bunzip2 system-image-i686.tar.bz2 | tar xf -
  cd system-image-i686
  cat \END test.py
  #!/usr/bin/python
  import sys
  import time
  import pexpect
  n = 10
  child = pexpect.spawn('./run-emulator.sh', logfile = sys.stderr)
  child.expect(/home #)
  child.send(seq -f '%%08.0f' 0 %d\r % (n - 1))
  for i in range(n):
  child.expect(([0-9]+), timeout = 5)
  got = int(child.match.group(1))
  if got != i:
  print sys.stderr, \nFAIL: expected %d, got %d % (i, got)
  sys.exit(1)
  if i % 100 == 0:
  time.sleep(0.1)
  child.send(exit)
  print sys.stderr, \nPASS
  sys.exit(0)
  END
  python test.py

  This will output PASS if the console output contains the 100,000
  sequential integers as expected, or FAIL if parts of the output
  are missing due to the bug.

  
  Method 2

  This method does not require Python or pexpect.  Instead, the qemu source
  is modified to simulate a simulate a slow tty by forcing an EAGAIN return
  from every other write().  If qemu were working correctly, this
  change would not cause any data loss, because the writes would be
  retried, but in actuality, they are not retried, and the end result is
  that every other character in the guest output will be missing.

  Apply the following patch to the qemu source (this is against 2.0.0):

  --- ../qemu-2.0.0.orig/qemu-char.c  2014-04-17 16:44:45.0 +0300
  +++ ./qemu-char.c   2014-06-20 16:47:18.0 +0300
  @@ -779,6 +779,17 @@
   size_t offset = 0;
   GIOStatus status = G_IO_STATUS_NORMAL;

  +/*
  + * Simulate a tty with a limited output buffer by returning
  + * EAGAIN on every second call.
  + */
  +static unsigned int toggle = 0;
  +toggle++;
  +if (toggle  1) {
  +   errno = EAGAIN;
  +   return -1;
  +}
  +
   while (offset  len  status == G_IO_STATUS_NORMAL) {
   gsize bytes_written = 0;

  Build and install qemu.

  Run any serial console guest.  You could use the same Aboriginal Linux image
  as in Method 1, or for example the PLD RescueCD:

wget http://rescuecd.pld-linux.org/download/2011-02-12/x86/RCDx86_11_02.iso
qemu-system-i386 -nographic -cdrom RCDx86_11_02.iso

  If this command is run with an unmodified qemu, a set of boot messages
  will appear, starting with:

ISOLINUX 4.03 2010-10-22  Copyright (C) 1994-2010 H. Peter Anvin et
  al

  When qemu has been patched to simulate EAGAIN returns, every other
  character in the boot messages will be missing, so that the first line
  of output will instead read:

SLNX40 001-2 oyih C 9421 .PtrAvne l

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

[Qemu-devel] [Bug 1335444] Re: qemu loses serial console data on EAGAIN

[Andreas Gustafsson]

Kirill - thank you for looking into the problem.  I reran the test of Method 1
with your patch, and it is still failing, but the blocks of missing data
seem to be smaller than before.

Here is an extract from the output of the Method 1 test without your patch.
In this case, the test failed because360 consecutive lines of output were 
missing:

1071
1072
1433
1434

With your patch, it still failed, but only a single character was
missing:

1073
0001074
1075

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

Title:
  qemu loses serial console data on EAGAIN

Status in QEMU:
  New

Bug description:
  When running a guest OS with a serial console under qemu-system-i386
  -nographic, parts of the serial console output are sometimes lost.

  This happens when a write() to standard output by qemu returns EAGAIN,
  as may be the case when the guest is generating console output faster
  than the tty (or pty/pipe/socket, etc.) connected to qemu's standard
  output accepts it.  The bug affects all releases of qemu since 1.5,
  which was the first version to set stdout to O_NONBLOCK mode.  Version
  1.4.2 and earlier work correctly.

  To reproduce the bug, you will need a guest OS configured with a
  serial console, and a host with a slow tty.  Two different methods
  of setting this up are outlined below.

  
  Method 1

  This fully automated test uses the pexpect Python module to run qemu
  under a pty, with an Aboriginal Linux guest.  A seq command is sent
  to the guest to generate 100,000 lines of output containing sequential
  integers, and the output is checked for gaps.  The script limits the
  tty output rate by occasionally sleeping for 1/10 of a second.

  Run the following commands in a Bourne shell:

  wget 
http://landley.net/aboriginal/downloads/binaries/system-image-i686.tar.bz2
  bunzip2 system-image-i686.tar.bz2 | tar xf -
  cd system-image-i686
  cat \END test.py
  #!/usr/bin/python
  import sys
  import time
  import pexpect
  n = 10
  child = pexpect.spawn('./run-emulator.sh', logfile = sys.stderr)
  child.expect(/home #)
  child.send(seq -f '%%08.0f' 0 %d\r % (n - 1))
  for i in range(n):
  child.expect(([0-9]+), timeout = 5)
  got = int(child.match.group(1))
  if got != i:
  print sys.stderr, \nFAIL: expected %d, got %d % (i, got)
  sys.exit(1)
  if i % 100 == 0:
  time.sleep(0.1)
  child.send(exit)
  print sys.stderr, \nPASS
  sys.exit(0)
  END
  python test.py

  This will output PASS if the console output contains the 100,000
  sequential integers as expected, or FAIL if parts of the output
  are missing due to the bug.

  
  Method 2

  This method does not require Python or pexpect.  Instead, the qemu source
  is modified to simulate a simulate a slow tty by forcing an EAGAIN return
  from every other write().  If qemu were working correctly, this
  change would not cause any data loss, because the writes would be
  retried, but in actuality, they are not retried, and the end result is
  that every other character in the guest output will be missing.

  Apply the following patch to the qemu source (this is against 2.0.0):

  --- ../qemu-2.0.0.orig/qemu-char.c  2014-04-17 16:44:45.0 +0300
  +++ ./qemu-char.c   2014-06-20 16:47:18.0 +0300
  @@ -779,6 +779,17 @@
   size_t offset = 0;
   GIOStatus status = G_IO_STATUS_NORMAL;

  +/*
  + * Simulate a tty with a limited output buffer by returning
  + * EAGAIN on every second call.
  + */
  +static unsigned int toggle = 0;
  +toggle++;
  +if (toggle  1) {
  +   errno = EAGAIN;
  +   return -1;
  +}
  +
   while (offset  len  status == G_IO_STATUS_NORMAL) {
   gsize bytes_written = 0;

  Build and install qemu.

  Run any serial console guest.  You could use the same Aboriginal Linux image
  as in Method 1, or for example the PLD RescueCD:

wget http://rescuecd.pld-linux.org/download/2011-02-12/x86/RCDx86_11_02.iso
qemu-system-i386 -nographic -cdrom RCDx86_11_02.iso

  If this command is run with an unmodified qemu, a set of boot messages
  will appear, starting with:

ISOLINUX 4.03 2010-10-22  Copyright (C) 1994-2010 H. Peter Anvin et
  al

  When qemu has been patched to simulate EAGAIN returns, every other
  character in the boot messages will be missing, so that the first line
  of output will instead read:

SLNX40 001-2 oyih C 9421 .PtrAvne l

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

[Qemu-devel] [Bug 1335444] [NEW] qemu loses serial console data on EAGAIN

[Andreas Gustafsson]

Public bug reported:

When running a guest OS with a serial console under qemu-system-i386
-nographic, parts of the serial console output are sometimes lost.

This happens when a write() to standard output by qemu returns EAGAIN,
as may be the case when the guest is generating console output faster
than the tty (or pty/pipe/socket, etc.) connected to qemu's standard
output accepts it.  The bug affects all releases of qemu since 1.5,
which was the first version to set stdout to O_NONBLOCK mode.  Version
1.4.2 and earlier work correctly.

To reproduce the bug, you will need a guest OS configured with a
serial console, and a host with a slow tty.  Two different methods
of setting this up are outlined below.


Method 1

This fully automated test uses the pexpect Python module to run qemu
under a pty, with an Aboriginal Linux guest.  A seq command is sent
to the guest to generate 100,000 lines of output containing sequential
integers, and the output is checked for gaps.  The script limits the
tty output rate by occasionally sleeping for 1/10 of a second.

Run the following commands in a Bourne shell:

wget http://landley.net/aboriginal/downloads/binaries/system-image-i686.tar.bz2
bunzip2 system-image-i686.tar.bz2 | tar xf -
cd system-image-i686
cat \END test.py
#!/usr/bin/python
import sys
import time
import pexpect
n = 10
child = pexpect.spawn('./run-emulator.sh', logfile = sys.stderr)
child.expect(/home #)
child.send(seq -f '%%08.0f' 0 %d\r % (n - 1))
for i in range(n):
child.expect(([0-9]+), timeout = 5)
got = int(child.match.group(1))
if got != i:
print sys.stderr, \nFAIL: expected %d, got %d % (i, got)
sys.exit(1)
if i % 100 == 0:
time.sleep(0.1)
child.send(exit)
print sys.stderr, \nPASS
sys.exit(0)
END
python test.py

This will output PASS if the console output contains the 100,000
sequential integers as expected, or FAIL if parts of the output
are missing due to the bug.


Method 2

This method does not require Python or pexpect.  Instead, the qemu source
is modified to simulate a simulate a slow tty by forcing an EAGAIN return
from every other write().  If qemu were working correctly, this
change would not cause any data loss, because the writes would be
retried, but in actuality, they are not retried, and the end result is
that every other character in the guest output will be missing.

Apply the following patch to the qemu source (this is against 2.0.0):

--- ../qemu-2.0.0.orig/qemu-char.c  2014-04-17 16:44:45.0 +0300
+++ ./qemu-char.c   2014-06-20 16:47:18.0 +0300
@@ -779,6 +779,17 @@
 size_t offset = 0;
 GIOStatus status = G_IO_STATUS_NORMAL;

+/*
+ * Simulate a tty with a limited output buffer by returning
+ * EAGAIN on every second call.
+ */
+static unsigned int toggle = 0;
+toggle++;
+if (toggle  1) {
+   errno = EAGAIN;
+   return -1;
+}
+
 while (offset  len  status == G_IO_STATUS_NORMAL) {
 gsize bytes_written = 0;

Build and install qemu.

Run any serial console guest.  You could use the same Aboriginal Linux image
as in Method 1, or for example the PLD RescueCD:

  wget http://rescuecd.pld-linux.org/download/2011-02-12/x86/RCDx86_11_02.iso
  qemu-system-i386 -nographic -cdrom RCDx86_11_02.iso

If this command is run with an unmodified qemu, a set of boot messages
will appear, starting with:

  ISOLINUX 4.03 2010-10-22  Copyright (C) 1994-2010 H. Peter Anvin et al

When qemu has been patched to simulate EAGAIN returns, every other
character in the boot messages will be missing, so that the first line
of output will instead read:

  SLNX40 001-2 oyih C 9421 .PtrAvne l

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  qemu loses serial console data on EAGAIN

Status in QEMU:
  New

Bug description:
  When running a guest OS with a serial console under qemu-system-i386
  -nographic, parts of the serial console output are sometimes lost.

  This happens when a write() to standard output by qemu returns EAGAIN,
  as may be the case when the guest is generating console output faster
  than the tty (or pty/pipe/socket, etc.) connected to qemu's standard
  output accepts it.  The bug affects all releases of qemu since 1.5,
  which was the first version to set stdout to O_NONBLOCK mode.  Version
  1.4.2 and earlier work correctly.

  To reproduce the bug, you will need a guest OS configured with a
  serial console, and a host with a slow tty.  Two different methods
  of setting this up are outlined below.

  
  Method 1

  This fully automated test uses the pexpect Python module to run qemu
  under a pty, with an Aboriginal Linux guest.  A seq command is sent
  to the guest to generate 100,000 lines of output containing sequential
  integers, and the output is checked for gaps.  The script limits 

[Qemu-devel] Gatewaying of bug reports from launchpad

[Andreas Gustafsson]

Hi all,

It looks to me like at least some updates to existing qemu bug reports
on launchpad are gatewayed to the qemu-devel list, but the initial bug
reports are not.  This makes no sense to me - is it intentional?
-- 
Andreas Gustafsson, g...@gson.org

[Qemu-devel] [Bug 1127369] Re: i386 emulation unreliable since commit b76f0d8c2e3eac94bc7fd90a510cb7426b2a2699

[Andreas Gustafsson]

My tests are now working again.  The point in time when they started
working is consistent with this having been fixed by commit
38ebb396c955ceb2ef7e246248ceb7f8bfe1b774, target-i386: ROR r8/r16 imm
instruction fix.  Many thanks to everyone involved in fixing it.

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

Title:
  i386 emulation unreliable since commit
  b76f0d8c2e3eac94bc7fd90a510cb7426b2a2699

Status in QEMU:
  Fix Committed

Bug description:
  I am running daily automated tests of the qemu git mainline that
  involve building qemu on a Linux host (32-bit), booting a NetBSD guest
  in qemu-system-i386, and running the NetBSD operating system test
  suite on the guest.

  Since commit b76f0d8c2e3eac94bc7fd90a510cb7426b2a2699, there has been
  a marked increase in the number of failing test cases.  Before that
  commit, the number of failing test cases was typically in the range 3
  to 6, but since that commit, test runs often show 10 or more failed
  tests, or they end prematurely due to a segmentation fault in the test
  framework itself.

  To aid in reproducing the problem, I have prepared a disk image
  containing a NetBSD 6.0.1 system configured to automatically run
  the test suite on boot.

  To reproduce the problem, run the following shell commands:

wget http://www.gson.org/bugs/qemu/NetBSD-6.0.1-i386-test.img.gz
gunzip NetBSD-6.0.1-i386-test.img.gz
qemu-system-i386 -m 32 -nographic -snapshot -hda NetBSD-6.0.1-i386-test.img

  The disk image is about 144 MB in size and uncompresses to 2 GB.  The
  test run typically takes a couple of hours, printing progress messages
  to the terminal as it goes.  When it finishes, the virtual machine
  will be automatically powered down, causing qemu to exit.

  Near the end of the output, before the shutdown messages, there should
  be a summary of the test results.  The expected output looks like this:

Summary for 500 test programs:
2958 passed test cases.
5 failed test cases.
45 expected failed test cases.
70 skipped test cases.

  A number of failed test cases in the range 3 to 6 should be
  considered normal.  Please ignore the expected failed test cases.
  Using a version of qemu affected by the bug, the summary will look
  more like this:

Summary for 500 test programs:
2951 passed test cases.
12 failed test cases.
45 expected failed test cases.
69 skipped test cases.

  Or it may end with a segmentation fault like this:

 p2k_ffs_race: atf-report: ERROR: 10912: Unexpected token `EOF'; 
expected end of test case or test case's stdout/stderr line
  [1]   Segmentation fault (core dumped) atf-run |
Done(1) atf-report

  The problem goes away if the -m 32 is omitted from the qemu command line,
  which leads me to suspect that the problem may be related to paging or
  swapping activity in the guest.

  The revision listed in the subject, b76f0d8c2e3eac94bc7fd90a510cb7426b2a2699,
  is the first one exhibiting the excessive test failures, but the bug may 
already
  have been introduced in the previous commit, 
fdbb84d1332ae0827d60f1a2ca03c7d5678c6edd.
  If I attempt to run the test on fdbb84d1332ae0827d60f1a2ca03c7d5678c6edd, the
  guest fails to boot.  The revision before that, 
32761257c0b9fa7ee04d2871a6e48a41f119c469,
  works as expected.
  --
  Andreas Gustafsson, g...@gson.org

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

[Qemu-devel] [Bug 1154328] Re: qemu locks up on typing 41 characters at once into serial console

[Andreas Gustafsson]

** Changed in: qemu
   Status: New = Fix Committed

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

Title:
  qemu locks up on typing 41 characters at once into serial console

Status in QEMU:
  Fix Committed

Bug description:
  I am running daily automated tests that involve booting a NetBSD 6.0.1
  guest in qemu freshly built from git.  The tests are scripted using
  pexpect, which interacts with the NetBSD guest over the emulated
  serial console.  Recently, the tests stopped working; the guest boots
  and pexpect is able to log in, but when it sends a long shell command
  (more than 40 characters) to the guest, the command is neither echoed
  nor executed, and no further output is seen from the guest.

  The problem can be reproduced manually (without pexpect) as follows.

  Run the following commands in a terminal window on a host of
  your choice (Linux will do fine):

wget 
http://www.gson.org/bugs/qemu/NetBSD-6.0.1-i386-live-wd0root-com0.img.gz
gunzip NetBSD-6.0.1-i386-live-wd0root-com0.img.gz
qemu-system-i386 -m 32 -nographic -snapshot -hda 
NetBSD-6.0.1-i386-live-wd0root-com0.img

  This will download a disk image (some 144 MB compressed, 2 GB
  uncompressed) containing a NetBSD system configured to use a serial
  console, and boot it in qemu.  Make sure the qemu-system-i386
  in your PATH is one recently built from git, or adjust the command
  as needed.

  Once the VM has booted, log in as root (there is no password).  You
  will now be in a functional NetBSD root shell.

  Now cut-and-paste a string containing at least 41 characters into the
  terminal window.  I used a string containing 41 copies of the letter
  X.  You can use other strings, but beware of pasting strings
  containing valid shell commands, as they may end up being executed on
  the host (see below).

  If your copy of qemu is suffering from the bug, it will lock up.  Not
  only will the virtual machine no longer respond to keystrokes, but
  qemu itself will no longer respond to commands such as control-a c.
  You will have to kill it from a different terminal window.  When the
  qemu process is killed, any pasted characters after the first 40 will
  be read and executed by the host shell, suggesting that they were never
  even read by the qemu process.  As I had typed a return after pasting
  the 41 X:es, the host shell executed the command X, thereby
  accidentally attempting (unsuccessfully) to start an X server.

  git bisect implicates the following commit:

commit a29753f8aa79a34a324afebe340182a51a5aef11
Author: Anthony Liguori aligu...@us.ibm.com
Date:   Tue Mar 5 23:21:19 2013 +0530

qemu-char: convert fd_chr to use a GIOChannel

   This uses the newly introduced IOWatchPoll source.

Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Amit Shah amit.s...@redhat.com
Message-id: 
0cb5d14510ee835a0ebc23676d10a2cce9280da5.1362505276.git.amit.s...@redhat.com
Signed-off-by: Anthony Liguori aligu...@us.ibm.com

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

[Qemu-devel] [Bug 1089996] Re: Recent floppy boot regression in qemu-system-i386

[Andreas Gustafsson]

** Changed in: qemu
   Status: New = Fix Committed

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

Title:
   Recent floppy boot regression in qemu-system-i386

Status in QEMU:
  Fix Committed

Bug description:
  In recent versions of qemu-system-i386, booting from an
  emulated floppy no longer works.

  Using bisection, I have determined that the problem appeared
  with the following commit:

commit 582299336879504353e60c7937fbc70fea93f3da
Author: Julien Grall julien.gr...@citrix.com
Date:   Wed Sep 19 12:50:09 2012 +0100

hw/dma.c: Replace register_ioport_*

Replace all register_ioport_*() with the new Memory API functions.
This permits to use the new Memory stuff like listeners.

Signed-off-by: Julien Grall julien.gr...@citrix.com
Acked-by: Avi Kivity a...@redhat.com
[AF: Rebased onto hwaddr]
Signed-off-by: Andreas Färber afaer...@suse.de

  One way to reproduce the problem is using the FreeDOS floppy image
  listed on http://wiki.qemu.org/Testing, by running

wget http://odin.fdos.org/odin2005/odin1440.img
qemu-system-i386 -fda odin1440.img

  This successfully boots FreeDOS in qemu version
  258711c6448c44b60b0fecef1d3b09c71e23e304, but not
  in version 582299336879504353e60c7937fbc70fea93f3da
  or newer.

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

[Qemu-devel] [Bug 1127369] Re: i386 emulation unreliable since commit b76f0d8c2e3eac94bc7fd90a510cb7426b2a2699

[Andreas Gustafsson]

Now that bug 1154328 has been fixed,  the NetBSD OS test suite
successfully starts, but it still does not work as expected; actually
things have gone from bad to worse.  Every test run since the 1154328
fix has either timed out after running only a fraction of the tests, or
has ended in a guest kernel panic.  For example, here is part of the
console output from a recent test run using qemu git revision
93b48c201eb6c0404d15550a0eaa3c0f7937e35e:

msdosfs_symlink_zerolen: [1.172395s] Skipped: symlinks not supported by file 
system
nfs_access_simple: [9.423184s] Failed: child died
nfs_attrs: fatal double fault in user mode
trap type 269 code 8000 eip c010cca2 cs 8 eflags ed1fe cr2 b83fd834 ilevel 0
panic: trap
cpu0: Begin traceback...
printf_nolog(c0ba9e6b,c34adf7c,c34adf7c,c010cca2,8,ed1fe,b83fd834,0,0,0) at 
netbsd:printf_nolog
trap_tss() at netbsd:trap_tss
--- trap via task gate ---
b83ff74c:
cpu0: End traceback...

So either the supposed fix actually made things worse, or some unrelated
regression has been introduced while the tests were inoperable due to
bug 1154328.

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

Title:
  i386 emulation unreliable since commit
  b76f0d8c2e3eac94bc7fd90a510cb7426b2a2699

Status in QEMU:
  Fix Committed

Bug description:
  I am running daily automated tests of the qemu git mainline that
  involve building qemu on a Linux host (32-bit), booting a NetBSD guest
  in qemu-system-i386, and running the NetBSD operating system test
  suite on the guest.

  Since commit b76f0d8c2e3eac94bc7fd90a510cb7426b2a2699, there has been
  a marked increase in the number of failing test cases.  Before that
  commit, the number of failing test cases was typically in the range 3
  to 6, but since that commit, test runs often show 10 or more failed
  tests, or they end prematurely due to a segmentation fault in the test
  framework itself.

  To aid in reproducing the problem, I have prepared a disk image
  containing a NetBSD 6.0.1 system configured to automatically run
  the test suite on boot.

  To reproduce the problem, run the following shell commands:

wget http://www.gson.org/bugs/qemu/NetBSD-6.0.1-i386-test.img.gz
gunzip NetBSD-6.0.1-i386-test.img.gz
qemu-system-i386 -m 32 -nographic -snapshot -hda NetBSD-6.0.1-i386-test.img

  The disk image is about 144 MB in size and uncompresses to 2 GB.  The
  test run typically takes a couple of hours, printing progress messages
  to the terminal as it goes.  When it finishes, the virtual machine
  will be automatically powered down, causing qemu to exit.

  Near the end of the output, before the shutdown messages, there should
  be a summary of the test results.  The expected output looks like this:

Summary for 500 test programs:
2958 passed test cases.
5 failed test cases.
45 expected failed test cases.
70 skipped test cases.

  A number of failed test cases in the range 3 to 6 should be
  considered normal.  Please ignore the expected failed test cases.
  Using a version of qemu affected by the bug, the summary will look
  more like this:

Summary for 500 test programs:
2951 passed test cases.
12 failed test cases.
45 expected failed test cases.
69 skipped test cases.

  Or it may end with a segmentation fault like this:

 p2k_ffs_race: atf-report: ERROR: 10912: Unexpected token `EOF'; 
expected end of test case or test case's stdout/stderr line
  [1]   Segmentation fault (core dumped) atf-run |
Done(1) atf-report

  The problem goes away if the -m 32 is omitted from the qemu command line,
  which leads me to suspect that the problem may be related to paging or
  swapping activity in the guest.

  The revision listed in the subject, b76f0d8c2e3eac94bc7fd90a510cb7426b2a2699,
  is the first one exhibiting the excessive test failures, but the bug may 
already
  have been introduced in the previous commit, 
fdbb84d1332ae0827d60f1a2ca03c7d5678c6edd.
  If I attempt to run the test on fdbb84d1332ae0827d60f1a2ca03c7d5678c6edd, the
  guest fails to boot.  The revision before that, 
32761257c0b9fa7ee04d2871a6e48a41f119c469,
  works as expected.
  --
  Andreas Gustafsson, g...@gson.org

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

[Qemu-devel] [Bug 1154328] Re: qemu locks up on typing 41 characters at once into serial console

[Andreas Gustafsson]

Testing git revision  47b5264eb3e1cd2825e48d28fd0d1b239ed53974, the
assertion failure messages are gone.  Presumably they were fixed by
commit 1e885b25275fb6763eb947b1e53b2d6911b967a8.

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

Title:
  qemu locks up on typing 41 characters at once into serial console

Status in QEMU:
  New

Bug description:
  I am running daily automated tests that involve booting a NetBSD 6.0.1
  guest in qemu freshly built from git.  The tests are scripted using
  pexpect, which interacts with the NetBSD guest over the emulated
  serial console.  Recently, the tests stopped working; the guest boots
  and pexpect is able to log in, but when it sends a long shell command
  (more than 40 characters) to the guest, the command is neither echoed
  nor executed, and no further output is seen from the guest.

  The problem can be reproduced manually (without pexpect) as follows.

  Run the following commands in a terminal window on a host of
  your choice (Linux will do fine):

wget 
http://www.gson.org/bugs/qemu/NetBSD-6.0.1-i386-live-wd0root-com0.img.gz
gunzip NetBSD-6.0.1-i386-live-wd0root-com0.img.gz
qemu-system-i386 -m 32 -nographic -snapshot -hda 
NetBSD-6.0.1-i386-live-wd0root-com0.img

  This will download a disk image (some 144 MB compressed, 2 GB
  uncompressed) containing a NetBSD system configured to use a serial
  console, and boot it in qemu.  Make sure the qemu-system-i386
  in your PATH is one recently built from git, or adjust the command
  as needed.

  Once the VM has booted, log in as root (there is no password).  You
  will now be in a functional NetBSD root shell.

  Now cut-and-paste a string containing at least 41 characters into the
  terminal window.  I used a string containing 41 copies of the letter
  X.  You can use other strings, but beware of pasting strings
  containing valid shell commands, as they may end up being executed on
  the host (see below).

  If your copy of qemu is suffering from the bug, it will lock up.  Not
  only will the virtual machine no longer respond to keystrokes, but
  qemu itself will no longer respond to commands such as control-a c.
  You will have to kill it from a different terminal window.  When the
  qemu process is killed, any pasted characters after the first 40 will
  be read and executed by the host shell, suggesting that they were never
  even read by the qemu process.  As I had typed a return after pasting
  the 41 X:es, the host shell executed the command X, thereby
  accidentally attempting (unsuccessfully) to start an X server.

  git bisect implicates the following commit:

commit a29753f8aa79a34a324afebe340182a51a5aef11
Author: Anthony Liguori aligu...@us.ibm.com
Date:   Tue Mar 5 23:21:19 2013 +0530

qemu-char: convert fd_chr to use a GIOChannel

   This uses the newly introduced IOWatchPoll source.

Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Amit Shah amit.s...@redhat.com
Message-id: 
0cb5d14510ee835a0ebc23676d10a2cce9280da5.1362505276.git.amit.s...@redhat.com
Signed-off-by: Anthony Liguori aligu...@us.ibm.com

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

[Qemu-devel] [Bug 1154328] Re: qemu locks up on typing 41 characters at once into serial console

[Andreas Gustafsson]

My automated test is still hanging, but since commit 
893986fe94eb229f2317f50fac0e35e068eb66ba, 
it no longer hangs silently, but instead outputs a seemingly endless stream of 
assertion failure messages:

(process:5928): GLib-CRITICAL **: g_source_get_context: assertion
`!SOURCE_DESTROYED (source)' failed

(process:5928): GLib-CRITICAL **: g_source_get_context: assertion
`!SOURCE_DESTROYED (source)' failed

(process:5928): GLib-CRITICAL **: g_source_get_context: assertion
`!SOURCE_DESTROYED (source)' failed

(process:5928): GLib-CRITICAL **: g_source_attach: assertion
`source-context == NULL' failed

(process:5928): GLib-CRITICAL **: g_source_get_context: assertion
`!SOURCE_DESTROYED (source)' failed

(process:5928): GLib-CRITICAL **: g_source_attach: assertion
`source-context == NULL' failed

(process:5928): GLib-CRITICAL **: g_source_get_context: assertion
`!SOURCE_DESTROYED (source)' failed

(process:5928): GLib-CRITICAL **: g_source_attach: assertion
`source-context == NULL' failed

(process:5928): GLib-CRITICAL **: g_source_get_context: assertion
`!SOURCE_DESTROYED (source)' failed

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

Title:
  qemu locks up on typing 41 characters at once into serial console

Status in QEMU:
  New

Bug description:
  I am running daily automated tests that involve booting a NetBSD 6.0.1
  guest in qemu freshly built from git.  The tests are scripted using
  pexpect, which interacts with the NetBSD guest over the emulated
  serial console.  Recently, the tests stopped working; the guest boots
  and pexpect is able to log in, but when it sends a long shell command
  (more than 40 characters) to the guest, the command is neither echoed
  nor executed, and no further output is seen from the guest.

  The problem can be reproduced manually (without pexpect) as follows.

  Run the following commands in a terminal window on a host of
  your choice (Linux will do fine):

wget 
http://www.gson.org/bugs/qemu/NetBSD-6.0.1-i386-live-wd0root-com0.img.gz
gunzip NetBSD-6.0.1-i386-live-wd0root-com0.img.gz
qemu-system-i386 -m 32 -nographic -snapshot -hda 
NetBSD-6.0.1-i386-live-wd0root-com0.img

  This will download a disk image (some 144 MB compressed, 2 GB
  uncompressed) containing a NetBSD system configured to use a serial
  console, and boot it in qemu.  Make sure the qemu-system-i386
  in your PATH is one recently built from git, or adjust the command
  as needed.

  Once the VM has booted, log in as root (there is no password).  You
  will now be in a functional NetBSD root shell.

  Now cut-and-paste a string containing at least 41 characters into the
  terminal window.  I used a string containing 41 copies of the letter
  X.  You can use other strings, but beware of pasting strings
  containing valid shell commands, as they may end up being executed on
  the host (see below).

  If your copy of qemu is suffering from the bug, it will lock up.  Not
  only will the virtual machine no longer respond to keystrokes, but
  qemu itself will no longer respond to commands such as control-a c.
  You will have to kill it from a different terminal window.  When the
  qemu process is killed, any pasted characters after the first 40 will
  be read and executed by the host shell, suggesting that they were never
  even read by the qemu process.  As I had typed a return after pasting
  the 41 X:es, the host shell executed the command X, thereby
  accidentally attempting (unsuccessfully) to start an X server.

  git bisect implicates the following commit:

commit a29753f8aa79a34a324afebe340182a51a5aef11
Author: Anthony Liguori aligu...@us.ibm.com
Date:   Tue Mar 5 23:21:19 2013 +0530

qemu-char: convert fd_chr to use a GIOChannel

   This uses the newly introduced IOWatchPoll source.

Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Amit Shah amit.s...@redhat.com
Message-id: 
0cb5d14510ee835a0ebc23676d10a2cce9280da5.1362505276.git.amit.s...@redhat.com
Signed-off-by: Anthony Liguori aligu...@us.ibm.com

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

[Qemu-devel] [Bug 1127369] Re: i386 emulation unreliable since commit b76f0d8c2e3eac94bc7fd90a510cb7426b2a2699

[Andreas Gustafsson]

Thank you.  Now if someone could also fix bug 1154328 , my automated
tests might run again...

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

Title:
  i386 emulation unreliable since commit
  b76f0d8c2e3eac94bc7fd90a510cb7426b2a2699

Status in QEMU:
  Fix Committed

Bug description:
  I am running daily automated tests of the qemu git mainline that
  involve building qemu on a Linux host (32-bit), booting a NetBSD guest
  in qemu-system-i386, and running the NetBSD operating system test
  suite on the guest.

  Since commit b76f0d8c2e3eac94bc7fd90a510cb7426b2a2699, there has been
  a marked increase in the number of failing test cases.  Before that
  commit, the number of failing test cases was typically in the range 3
  to 6, but since that commit, test runs often show 10 or more failed
  tests, or they end prematurely due to a segmentation fault in the test
  framework itself.

  To aid in reproducing the problem, I have prepared a disk image
  containing a NetBSD 6.0.1 system configured to automatically run
  the test suite on boot.

  To reproduce the problem, run the following shell commands:

wget http://www.gson.org/bugs/qemu/NetBSD-6.0.1-i386-test.img.gz
gunzip NetBSD-6.0.1-i386-test.img.gz
qemu-system-i386 -m 32 -nographic -snapshot -hda NetBSD-6.0.1-i386-test.img

  The disk image is about 144 MB in size and uncompresses to 2 GB.  The
  test run typically takes a couple of hours, printing progress messages
  to the terminal as it goes.  When it finishes, the virtual machine
  will be automatically powered down, causing qemu to exit.

  Near the end of the output, before the shutdown messages, there should
  be a summary of the test results.  The expected output looks like this:

Summary for 500 test programs:
2958 passed test cases.
5 failed test cases.
45 expected failed test cases.
70 skipped test cases.

  A number of failed test cases in the range 3 to 6 should be
  considered normal.  Please ignore the expected failed test cases.
  Using a version of qemu affected by the bug, the summary will look
  more like this:

Summary for 500 test programs:
2951 passed test cases.
12 failed test cases.
45 expected failed test cases.
69 skipped test cases.

  Or it may end with a segmentation fault like this:

 p2k_ffs_race: atf-report: ERROR: 10912: Unexpected token `EOF'; 
expected end of test case or test case's stdout/stderr line
  [1]   Segmentation fault (core dumped) atf-run |
Done(1) atf-report

  The problem goes away if the -m 32 is omitted from the qemu command line,
  which leads me to suspect that the problem may be related to paging or
  swapping activity in the guest.

  The revision listed in the subject, b76f0d8c2e3eac94bc7fd90a510cb7426b2a2699,
  is the first one exhibiting the excessive test failures, but the bug may 
already
  have been introduced in the previous commit, 
fdbb84d1332ae0827d60f1a2ca03c7d5678c6edd.
  If I attempt to run the test on fdbb84d1332ae0827d60f1a2ca03c7d5678c6edd, the
  guest fails to boot.  The revision before that, 
32761257c0b9fa7ee04d2871a6e48a41f119c469,
  works as expected.
  --
  Andreas Gustafsson, g...@gson.org

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

[Qemu-devel] [Bug 1154328] [NEW] qemu locks up on typing 41 characters at once into serial console

[Andreas Gustafsson]

Public bug reported:

I am running daily automated tests that involve booting a NetBSD 6.0.1
guest in qemu freshly built from git.  The tests are scripted using
pexpect, which interacts with the NetBSD guest over the emulated
serial console.  Recently, the tests stopped working; the guest boots
and pexpect is able to log in, but when it sends a long shell command
(more than 40 characters) to the guest, the command is neither echoed
nor executed, and no further output is seen from the guest.

The problem can be reproduced manually (without pexpect) as follows.

Run the following commands in a terminal window on a host of
your choice (Linux will do fine):

  wget http://www.gson.org/bugs/qemu/NetBSD-6.0.1-i386-live-wd0root-com0.img.gz
  gunzip NetBSD-6.0.1-i386-live-wd0root-com0.img.gz
  qemu-system-i386 -m 32 -nographic -snapshot -hda 
NetBSD-6.0.1-i386-live-wd0root-com0.img

This will download a disk image (some 144 MB compressed, 2 GB
uncompressed) containing a NetBSD system configured to use a serial
console, and boot it in qemu.  Make sure the qemu-system-i386
in your PATH is one recently built from git, or adjust the command
as needed.

Once the VM has booted, log in as root (there is no password).  You
will now be in a functional NetBSD root shell.

Now cut-and-paste a string containing at least 41 characters into the
terminal window.  I used a string containing 41 copies of the letter
X.  You can use other strings, but beware of pasting strings
containing valid shell commands, as they may end up being executed on
the host (see below).

If your copy of qemu is suffering from the bug, it will lock up.  Not
only will the virtual machine no longer respond to keystrokes, but
qemu itself will no longer respond to commands such as control-a c.
You will have to kill it from a different terminal window.  When the
qemu process is killed, any pasted characters after the first 40 will
be read and executed by the host shell, suggesting that they were never
even read by the qemu process.  As I had typed a return after pasting
the 41 X:es, the host shell executed the command X, thereby
accidentally attempting (unsuccessfully) to start an X server.

git bisect implicates the following commit:

  commit a29753f8aa79a34a324afebe340182a51a5aef11
  Author: Anthony Liguori aligu...@us.ibm.com
  Date:   Tue Mar 5 23:21:19 2013 +0530

  qemu-char: convert fd_chr to use a GIOChannel

 This uses the newly introduced IOWatchPoll source.

  Signed-off-by: Anthony Liguori aligu...@us.ibm.com
  Signed-off-by: Amit Shah amit.s...@redhat.com
  Message-id: 
0cb5d14510ee835a0ebc23676d10a2cce9280da5.1362505276.git.amit.s...@redhat.com
  Signed-off-by: Anthony Liguori aligu...@us.ibm.com

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  qemu locks up on typing 41 characters at once into serial console

Status in QEMU:
  New

Bug description:
  I am running daily automated tests that involve booting a NetBSD 6.0.1
  guest in qemu freshly built from git.  The tests are scripted using
  pexpect, which interacts with the NetBSD guest over the emulated
  serial console.  Recently, the tests stopped working; the guest boots
  and pexpect is able to log in, but when it sends a long shell command
  (more than 40 characters) to the guest, the command is neither echoed
  nor executed, and no further output is seen from the guest.

  The problem can be reproduced manually (without pexpect) as follows.

  Run the following commands in a terminal window on a host of
  your choice (Linux will do fine):

wget 
http://www.gson.org/bugs/qemu/NetBSD-6.0.1-i386-live-wd0root-com0.img.gz
gunzip NetBSD-6.0.1-i386-live-wd0root-com0.img.gz
qemu-system-i386 -m 32 -nographic -snapshot -hda 
NetBSD-6.0.1-i386-live-wd0root-com0.img

  This will download a disk image (some 144 MB compressed, 2 GB
  uncompressed) containing a NetBSD system configured to use a serial
  console, and boot it in qemu.  Make sure the qemu-system-i386
  in your PATH is one recently built from git, or adjust the command
  as needed.

  Once the VM has booted, log in as root (there is no password).  You
  will now be in a functional NetBSD root shell.

  Now cut-and-paste a string containing at least 41 characters into the
  terminal window.  I used a string containing 41 copies of the letter
  X.  You can use other strings, but beware of pasting strings
  containing valid shell commands, as they may end up being executed on
  the host (see below).

  If your copy of qemu is suffering from the bug, it will lock up.  Not
  only will the virtual machine no longer respond to keystrokes, but
  qemu itself will no longer respond to commands such as control-a c.
  You will have to kill it from a different terminal window.  When the
  qemu process is killed, any pasted characters 

[Qemu-devel] [Bug 1127369] [NEW] i386 emulation unreliable since commit b76f0d8c2e3eac94bc7fd90a510cb7426b2a2699

[Andreas Gustafsson]

Public bug reported:

I am running daily automated tests of the qemu git mainline that
involve building qemu on a Linux host (32-bit), booting a NetBSD guest
in qemu-system-i386, and running the NetBSD operating system test
suite on the guest.

Since commit b76f0d8c2e3eac94bc7fd90a510cb7426b2a2699, there has been
a marked increase in the number of failing test cases.  Before that
commit, the number of failing test cases was typically in the range 3
to 6, but since that commit, test runs often show 10 or more failed
tests, or they end prematurely due to a segmentation fault in the test
framework itself.

To aid in reproducing the problem, I have prepared a disk image
containing a NetBSD 6.0.1 system configured to automatically run
the test suite on boot.

To reproduce the problem, run the following shell commands:

  wget http://www.gson.org/bugs/qemu/NetBSD-6.0.1-i386-test.img.gz
  gunzip NetBSD-6.0.1-i386-test.img.gz
  qemu-system-i386 -m 32 -nographic -snapshot -hda NetBSD-6.0.1-i386-test.img

The disk image is about 144 MB in size and uncompresses to 2 GB.  The
test run typically takes a couple of hours, printing progress messages
to the terminal as it goes.  When it finishes, the virtual machine
will be automatically powered down, causing qemu to exit.

Near the end of the output, before the shutdown messages, there should
be a summary of the test results.  The expected output looks like this:

  Summary for 500 test programs:
  2958 passed test cases.
  5 failed test cases.
  45 expected failed test cases.
  70 skipped test cases.

A number of failed test cases in the range 3 to 6 should be
considered normal.  Please ignore the expected failed test cases.
Using a version of qemu affected by the bug, the summary will look
more like this:

  Summary for 500 test programs:
  2951 passed test cases.
  12 failed test cases.
  45 expected failed test cases.
  69 skipped test cases.

Or it may end with a segmentation fault like this:

   p2k_ffs_race: atf-report: ERROR: 10912: Unexpected token `EOF'; expected 
end of test case or test case's stdout/stderr line
[1]   Segmentation fault (core dumped) atf-run |
  Done(1) atf-report

The problem goes away if the -m 32 is omitted from the qemu command line,
which leads me to suspect that the problem may be related to paging or
swapping activity in the guest.

The revision listed in the subject, b76f0d8c2e3eac94bc7fd90a510cb7426b2a2699,
is the first one exhibiting the excessive test failures, but the bug may already
have been introduced in the previous commit, 
fdbb84d1332ae0827d60f1a2ca03c7d5678c6edd.
If I attempt to run the test on fdbb84d1332ae0827d60f1a2ca03c7d5678c6edd, the
guest fails to boot.  The revision before that, 
32761257c0b9fa7ee04d2871a6e48a41f119c469,
works as expected.
--
Andreas Gustafsson, g...@gson.org

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  i386 emulation unreliable since commit
  b76f0d8c2e3eac94bc7fd90a510cb7426b2a2699

Status in QEMU:
  New

Bug description:
  I am running daily automated tests of the qemu git mainline that
  involve building qemu on a Linux host (32-bit), booting a NetBSD guest
  in qemu-system-i386, and running the NetBSD operating system test
  suite on the guest.

  Since commit b76f0d8c2e3eac94bc7fd90a510cb7426b2a2699, there has been
  a marked increase in the number of failing test cases.  Before that
  commit, the number of failing test cases was typically in the range 3
  to 6, but since that commit, test runs often show 10 or more failed
  tests, or they end prematurely due to a segmentation fault in the test
  framework itself.

  To aid in reproducing the problem, I have prepared a disk image
  containing a NetBSD 6.0.1 system configured to automatically run
  the test suite on boot.

  To reproduce the problem, run the following shell commands:

wget http://www.gson.org/bugs/qemu/NetBSD-6.0.1-i386-test.img.gz
gunzip NetBSD-6.0.1-i386-test.img.gz
qemu-system-i386 -m 32 -nographic -snapshot -hda NetBSD-6.0.1-i386-test.img

  The disk image is about 144 MB in size and uncompresses to 2 GB.  The
  test run typically takes a couple of hours, printing progress messages
  to the terminal as it goes.  When it finishes, the virtual machine
  will be automatically powered down, causing qemu to exit.

  Near the end of the output, before the shutdown messages, there should
  be a summary of the test results.  The expected output looks like this:

Summary for 500 test programs:
2958 passed test cases.
5 failed test cases.
45 expected failed test cases.
70 skipped test cases.

  A number of failed test cases in the range 3 to 6 should be
  considered normal.  Please ignore the expected failed test cases.
  Using a version of qemu affected

[Qemu-devel] [Bug 1091241] Re: NetBSD/i386 6.0 guest suffers interrupt storm since qemu BIOS update

[Andreas Gustafsson]

The bug has been fixed; revisoion
5928023cef87847a295035487397b9ec701fdd6b is still broken, but
dbd99ae302be8f51b547fb6283c91d0c9859b7d5 works.  I haven't determined
which of the commits inbetween fixed it, but the BIOS update of
15faf946f7a17a5fab0d05a2312d43249d81af3 seems like a likely candidate.


** Changed in: qemu
   Status: New = Fix Committed

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

Title:
  NetBSD/i386 6.0 guest suffers interrupt storm since qemu BIOS update

Status in QEMU:
  Fix Committed

Bug description:
  Since the pc-bios update of qemu commit
  d7a51dbbaa70677846453f8c961590913052dd86, booting a NetBSD/i386 guest
  takes a very long time, apparently due to interrupt load.

  For example, booting the NetBSD/i386 6.0 serial console install CD
  with

wget 
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-6.0/i386/installation/cdrom/boot-com.iso
qemu-system-i386 -nographic -cdrom boot-com.iso

  used to take less than a minute, but now takes more like ten minutes
  to enter the sysinst installer; it's so slow that at first I thought
  it had hung.  If I then exit the installer and type vmstat -i, it
  shows a high interrupt rate on ioapic0 pin 9:

  # vmstat -i
  interrupt total rate
  cpu0 timer   336942  102
  ioapic0 pin 9 25679123278052
  ioapic0 pin 1 10
  ioapic0 pin 15  3450
  ioapic0 pin 4   1020
  ioapic0 pin 6 10
  Total 25712862378154

  According to dmesg, this is the piixpm0 device:

  # dmesg
  [...]
  piixpm0 at pci0 dev 1 function 3: vendor 0x8086 product 0x7113 (rev. 0x03)
  timecounter: Timecounter piixpm0 frequency 3579545 Hz quality 1000
  piixpm0: 24-bit timer
  piixpm0: interrupting at ioapic0 pin 9
  [...]

  Versions of qemu lacking commit
  d7a51dbbaa70677846453f8c961590913052dd86 do not have this problem.

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

[Qemu-devel] [Bug 1091241] [NEW] NetBSD/i386 6.0 guest suffers interrupt storm since qemu BIOS update

[Andreas Gustafsson]

Public bug reported:

Since the pc-bios update of qemu commit
d7a51dbbaa70677846453f8c961590913052dd86, booting a NetBSD/i386 guest
takes a very long time, apparently due to interrupt load.

For example, booting the NetBSD/i386 6.0 serial console install CD with

  wget 
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-6.0/i386/installation/cdrom/boot-com.iso
  qemu-system-i386 -nographic -cdrom boot-com.iso

used to take less than a minute, but now takes more like ten minutes to
enter the sysinst installer; it's so slow that at first I thought it
had hung.  If I then exit the installer and type vmstat -i, it shows a
high interrupt rate on ioapic0 pin 9:

# vmstat -i
interrupt total rate
cpu0 timer   336942  102
ioapic0 pin 9 25679123278052
ioapic0 pin 1 10
ioapic0 pin 15  3450
ioapic0 pin 4   1020
ioapic0 pin 6 10
Total 25712862378154

According to dmesg, this is the piixpm0 device:

# dmesg
[...]
piixpm0 at pci0 dev 1 function 3: vendor 0x8086 product 0x7113 (rev. 0x03)
timecounter: Timecounter piixpm0 frequency 3579545 Hz quality 1000
piixpm0: 24-bit timer
piixpm0: interrupting at ioapic0 pin 9
[...]

Versions of qemu lacking commit d7a51dbbaa70677846453f8c961590913052dd86
do not have this problem.

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  NetBSD/i386 6.0 guest suffers interrupt storm since qemu BIOS update

Status in QEMU:
  New

Bug description:
  Since the pc-bios update of qemu commit
  d7a51dbbaa70677846453f8c961590913052dd86, booting a NetBSD/i386 guest
  takes a very long time, apparently due to interrupt load.

  For example, booting the NetBSD/i386 6.0 serial console install CD
  with

wget 
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-6.0/i386/installation/cdrom/boot-com.iso
qemu-system-i386 -nographic -cdrom boot-com.iso

  used to take less than a minute, but now takes more like ten minutes
  to enter the sysinst installer; it's so slow that at first I thought
  it had hung.  If I then exit the installer and type vmstat -i, it
  shows a high interrupt rate on ioapic0 pin 9:

  # vmstat -i
  interrupt total rate
  cpu0 timer   336942  102
  ioapic0 pin 9 25679123278052
  ioapic0 pin 1 10
  ioapic0 pin 15  3450
  ioapic0 pin 4   1020
  ioapic0 pin 6 10
  Total 25712862378154

  According to dmesg, this is the piixpm0 device:

  # dmesg
  [...]
  piixpm0 at pci0 dev 1 function 3: vendor 0x8086 product 0x7113 (rev. 0x03)
  timecounter: Timecounter piixpm0 frequency 3579545 Hz quality 1000
  piixpm0: 24-bit timer
  piixpm0: interrupting at ioapic0 pin 9
  [...]

  Versions of qemu lacking commit
  d7a51dbbaa70677846453f8c961590913052dd86 do not have this problem.

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

[Qemu-devel] [Bug 1089996] [NEW] Recent floppy boot regression in qemu-system-i386

[Andreas Gustafsson]

Public bug reported:

In recent versions of qemu-system-i386, booting from an
emulated floppy no longer works.

Using bisection, I have determined that the problem appeared
with the following commit:

  commit 582299336879504353e60c7937fbc70fea93f3da
  Author: Julien Grall julien.gr...@citrix.com
  Date:   Wed Sep 19 12:50:09 2012 +0100

  hw/dma.c: Replace register_ioport_*

  Replace all register_ioport_*() with the new Memory API functions.
  This permits to use the new Memory stuff like listeners.

  Signed-off-by: Julien Grall julien.gr...@citrix.com
  Acked-by: Avi Kivity a...@redhat.com
  [AF: Rebased onto hwaddr]
  Signed-off-by: Andreas Färber afaer...@suse.de

One way to reproduce the problem is using the FreeDOS floppy image
listed on http://wiki.qemu.org/Testing, by running

  wget http://odin.fdos.org/odin2005/odin1440.img
  qemu-system-i386 -fda odin1440.img

This successfully boots FreeDOS in qemu version
258711c6448c44b60b0fecef1d3b09c71e23e304, but not
in version 582299336879504353e60c7937fbc70fea93f3da
or newer.

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
   Recent floppy boot regression in qemu-system-i386

Status in QEMU:
  New

Bug description:
  In recent versions of qemu-system-i386, booting from an
  emulated floppy no longer works.

  Using bisection, I have determined that the problem appeared
  with the following commit:

commit 582299336879504353e60c7937fbc70fea93f3da
Author: Julien Grall julien.gr...@citrix.com
Date:   Wed Sep 19 12:50:09 2012 +0100

hw/dma.c: Replace register_ioport_*

Replace all register_ioport_*() with the new Memory API functions.
This permits to use the new Memory stuff like listeners.

Signed-off-by: Julien Grall julien.gr...@citrix.com
Acked-by: Avi Kivity a...@redhat.com
[AF: Rebased onto hwaddr]
Signed-off-by: Andreas Färber afaer...@suse.de

  One way to reproduce the problem is using the FreeDOS floppy image
  listed on http://wiki.qemu.org/Testing, by running

wget http://odin.fdos.org/odin2005/odin1440.img
qemu-system-i386 -fda odin1440.img

  This successfully boots FreeDOS in qemu version
  258711c6448c44b60b0fecef1d3b09c71e23e304, but not
  in version 582299336879504353e60c7937fbc70fea93f3da
  or newer.

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

[Qemu-devel] [Bug 897771] Re: qemu 1.0-rc4 no longer able to boot NetBSD-current/i386

[Andreas Gustafsson]

Fixed in cdde6ffc27517bdf069734fbc5693ce2b14edc75.



** Changed in: qemu
   Status: Confirmed = 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/897771

Title:
  qemu 1.0-rc4 no longer able to boot NetBSD-current/i386

Status in QEMU:
  Fix Released

Bug description:
  Booting a NetBSD-current/i386 install CD using qemu 1.0-rc4 fails. The
  same CD does boot in earlier versions of qemu, for example, 0.11.0.

  To reproduce, download the

http://www.gson.org/netbsd/bugs/qemu/boot-com-20270050Z.iso

  and attempt to boot it with:

qemu -nographic -cdrom boot-com-20270050Z.iso

  This fails with a guest kernel panic:

NetBSD 5.99.57 (GENERIC) #0: Sun Nov 27 07:41:56 UTC 2011

bui...@b8.netbsd.org:/home/builds/ab/HEAD/i386/20270050Z-obj/home/builds/ab/HEAD/src/sys/arch/i386/compile/GENERIC
total memory = 127 MB
avail memory = 112 MB
cprng kernel: WARNING insufficient entropy at creation.
mainbus0 (root)
cpu0 at mainbus0 apid 0: QEMU Virtual CPU version 0.15.93, id 0x633
ioapic0 at mainbus0 apid 1
acpi0 at mainbus0: Intel ACPICA 20110623
panic: pci_make_tag: bad request
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip c0269b04 cs 8 eflags 282 cr2 0 ilevel 8
Stopped in pid 0.1 (system) at  netbsd:breakpoint+0x4:  popl%ebp
db{0}  t

breakpoint(c0c04c75,c0cc2f80,c0bc91a4,c0e358e4,2,c11b70d6,c0e35908,c053999d,c0cdef20,0)
 at netbsd:breakpoint+0x4

vpanic(c0bc91a4,c0e358e4,c117d068,f,c11e6fcc,0,c0e35918,c0665969,c0bc91a4,c0b1bf4c)
 at netbsd:vpanic+0x1e2
printf_nolog(c0bc91a4,c0b1bf4c,c0e35908,c010d957,8,c0c1f2c0,0,0,c0d08e20,0) 
at netbsd:printf_nolog
pci_decompose_tag(c0e3599c,0,0,10,0,ca675898,c0e35988,c0d08e20,c11b9200,0) 
at netbsd:pci_decompose_tag
acpi_pci_link_add_reference(c12011c0,0,0,10,0,ca41eb90,0,3,0,4) at 
netbsd:acpi_pci_link_add_reference+0xb2

mpacpi_find_interrupts(ca41eb90,c0116a4a,c0116a5e,0,ca41eb90,c0e35b50,c0e35aa8,c01180c7,c,c0116a4a)
 at netbsd:mpacpi_find_interrupts+0x5ea

acpi_md_callback(c,c0116a4a,c0116a5e,0,1,ca3fd7cc,1,c078e2e4,c0cb6ce0,ca435ea0) 
at netbsd:acpi_md_callback+0x1c

acpi_attach(ca660500,ca660d00,c0e35b50,0,c0e35b50,80,f,10,c0b5dcd9,c0e35b42) at 
netbsd:acpi_attach+0x14a

config_attach_loc(ca660500,c0c1d7a0,0,c0e35b50,0,0,2589,58421301,4350,53445842) 
at netbsd:config_attach_loc+0x176

config_found_ia(ca660500,c0b59f3c,c0e35b50,0,4f424101,20534843,80,f,c0c2bbe0,c0c2bc00)
 at netbsd:config_found_ia+0x36

mainbus_rescan(ca660500,c0b59f3c,0,ca660500,c0cb6ce0,c0bd71ce,c0e35bd8,c093575c,ca437f28,c0b8e0a1)
 at netbsd:mainbus_rescan+0x1c2

mainbus_attach(0,ca660500,0,c078f4b7,c0b59187,c0b59187,636f4200,7368,3001403,101)
 at netbsd:mainbus_attach+0xb4
config_attach_loc(0,c0c1bbb0,0,0,0,7368,f10,0,c0b59187,e3b000) at 
netbsd:config_attach_loc+0x176
config_attach(0,c0c1bbb0,0,0,1984,c0cc5680,c0e35cd8,c01f224e,c0b59187,0) at 
netbsd:config_attach+0x2e
config_rootfound(c0b59187,0,0,8,1984,1984,c0e35d40,c04b78d8,c0ba59a1,6) at 
netbsd:config_rootfound+0x42
cpu_configure(c0ba59a1,6,3,0,,f9b00,,f9300,0,0) at 
netbsd:cpu_configure+0x2a
main(0,0,0,0,0,0,0,0,0,0) at netbsd:main+0x2ba
db{0}

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

[Qemu-devel] [Bug 897771] Re: qemu 1.0-rc4 no longer able to boot NetBSD-current/i386

[Andreas Gustafsson]

 note that the provided command-line is not sufficent, since the image
directs all its output to the serial port (serial console), so you have
to configure a serial port to see the messages

That command line works as-is for me, and it's what I was told to use
back when -serial stdio -nographic stopped working some time around
qemu version 0.12.

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

Title:
  qemu 1.0-rc4 no longer able to boot NetBSD-current/i386

Status in QEMU:
  Confirmed

Bug description:
  Booting a NetBSD-current/i386 install CD using qemu 1.0-rc4 fails. The
  same CD does boot in earlier versions of qemu, for example, 0.11.0.

  To reproduce, download the

http://www.gson.org/netbsd/bugs/qemu/boot-com-20270050Z.iso

  and attempt to boot it with:

qemu -nographic -cdrom boot-com-20270050Z.iso

  This fails with a guest kernel panic:

NetBSD 5.99.57 (GENERIC) #0: Sun Nov 27 07:41:56 UTC 2011

bui...@b8.netbsd.org:/home/builds/ab/HEAD/i386/20270050Z-obj/home/builds/ab/HEAD/src/sys/arch/i386/compile/GENERIC
total memory = 127 MB
avail memory = 112 MB
cprng kernel: WARNING insufficient entropy at creation.
mainbus0 (root)
cpu0 at mainbus0 apid 0: QEMU Virtual CPU version 0.15.93, id 0x633
ioapic0 at mainbus0 apid 1
acpi0 at mainbus0: Intel ACPICA 20110623
panic: pci_make_tag: bad request
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip c0269b04 cs 8 eflags 282 cr2 0 ilevel 8
Stopped in pid 0.1 (system) at  netbsd:breakpoint+0x4:  popl%ebp
db{0}  t

breakpoint(c0c04c75,c0cc2f80,c0bc91a4,c0e358e4,2,c11b70d6,c0e35908,c053999d,c0cdef20,0)
 at netbsd:breakpoint+0x4

vpanic(c0bc91a4,c0e358e4,c117d068,f,c11e6fcc,0,c0e35918,c0665969,c0bc91a4,c0b1bf4c)
 at netbsd:vpanic+0x1e2
printf_nolog(c0bc91a4,c0b1bf4c,c0e35908,c010d957,8,c0c1f2c0,0,0,c0d08e20,0) 
at netbsd:printf_nolog
pci_decompose_tag(c0e3599c,0,0,10,0,ca675898,c0e35988,c0d08e20,c11b9200,0) 
at netbsd:pci_decompose_tag
acpi_pci_link_add_reference(c12011c0,0,0,10,0,ca41eb90,0,3,0,4) at 
netbsd:acpi_pci_link_add_reference+0xb2

mpacpi_find_interrupts(ca41eb90,c0116a4a,c0116a5e,0,ca41eb90,c0e35b50,c0e35aa8,c01180c7,c,c0116a4a)
 at netbsd:mpacpi_find_interrupts+0x5ea

acpi_md_callback(c,c0116a4a,c0116a5e,0,1,ca3fd7cc,1,c078e2e4,c0cb6ce0,ca435ea0) 
at netbsd:acpi_md_callback+0x1c

acpi_attach(ca660500,ca660d00,c0e35b50,0,c0e35b50,80,f,10,c0b5dcd9,c0e35b42) at 
netbsd:acpi_attach+0x14a

config_attach_loc(ca660500,c0c1d7a0,0,c0e35b50,0,0,2589,58421301,4350,53445842) 
at netbsd:config_attach_loc+0x176

config_found_ia(ca660500,c0b59f3c,c0e35b50,0,4f424101,20534843,80,f,c0c2bbe0,c0c2bc00)
 at netbsd:config_found_ia+0x36

mainbus_rescan(ca660500,c0b59f3c,0,ca660500,c0cb6ce0,c0bd71ce,c0e35bd8,c093575c,ca437f28,c0b8e0a1)
 at netbsd:mainbus_rescan+0x1c2

mainbus_attach(0,ca660500,0,c078f4b7,c0b59187,c0b59187,636f4200,7368,3001403,101)
 at netbsd:mainbus_attach+0xb4
config_attach_loc(0,c0c1bbb0,0,0,0,7368,f10,0,c0b59187,e3b000) at 
netbsd:config_attach_loc+0x176
config_attach(0,c0c1bbb0,0,0,1984,c0cc5680,c0e35cd8,c01f224e,c0b59187,0) at 
netbsd:config_attach+0x2e
config_rootfound(c0b59187,0,0,8,1984,1984,c0e35d40,c04b78d8,c0ba59a1,6) at 
netbsd:config_rootfound+0x42
cpu_configure(c0ba59a1,6,3,0,,f9b00,,f9300,0,0) at 
netbsd:cpu_configure+0x2a
main(0,0,0,0,0,0,0,0,0,0) at netbsd:main+0x2ba
db{0}

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

[Qemu-devel] [Bug 897771] Re: qemu 1.0-rc4 no longer able to boot NetBSD-current/i386

[Andreas Gustafsson]

I found the cause of the regression.  As as Stefan Weil already figured,
it was caused by the following commit:

commit d0ed8076cbdc26138a7e33fed5e45a35d019a103
Author: Avi Kivity a...@redhat.com
Date: Sun Jul 24 17:47:18 2011 +0300

pci_host: convert conf index and data ports to memory API

Reviewed-by: Richard Henderson r...@twiddle.net
Signed-off-by: Avi Kivity a...@redhat.com

This commit incorrectly changed the emulation of the PCI configuration
register at I/O port 0xCF8.  Before the commit, an outb to port 0xCFB
or an outw to port 0xCFA had no effect, but after the commit, they
change the value of the CONFIG_ADDRESS DWORD register at 0xCF8.  This
is contrary to the behavior of real PC hardware, and contrary to the
PCI standard which clearly states that the only I/O space consumed by
the CONFIG_ADDRESS register is the DWORD at address 0xCF8.

Changing pci_host_config_write() to ignore writes with addr != 0 is
sufficient for qemu to again be able to boot NetBSD.  For full
compliance with the PCI standard, it should also ignore writes with
size != 4, and a similar change should probably also be made to
pci_host_config_read().

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

Title:
  qemu 1.0-rc4 no longer able to boot NetBSD-current/i386

Status in QEMU:
  Confirmed

Bug description:
  Booting a NetBSD-current/i386 install CD using qemu 1.0-rc4 fails. The
  same CD does boot in earlier versions of qemu, for example, 0.11.0.

  To reproduce, download the

http://www.gson.org/netbsd/bugs/qemu/boot-com-20270050Z.iso

  and attempt to boot it with:

qemu -nographic -cdrom boot-com-20270050Z.iso

  This fails with a guest kernel panic:

NetBSD 5.99.57 (GENERIC) #0: Sun Nov 27 07:41:56 UTC 2011

bui...@b8.netbsd.org:/home/builds/ab/HEAD/i386/20270050Z-obj/home/builds/ab/HEAD/src/sys/arch/i386/compile/GENERIC
total memory = 127 MB
avail memory = 112 MB
cprng kernel: WARNING insufficient entropy at creation.
mainbus0 (root)
cpu0 at mainbus0 apid 0: QEMU Virtual CPU version 0.15.93, id 0x633
ioapic0 at mainbus0 apid 1
acpi0 at mainbus0: Intel ACPICA 20110623
panic: pci_make_tag: bad request
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip c0269b04 cs 8 eflags 282 cr2 0 ilevel 8
Stopped in pid 0.1 (system) at  netbsd:breakpoint+0x4:  popl%ebp
db{0}  t

breakpoint(c0c04c75,c0cc2f80,c0bc91a4,c0e358e4,2,c11b70d6,c0e35908,c053999d,c0cdef20,0)
 at netbsd:breakpoint+0x4

vpanic(c0bc91a4,c0e358e4,c117d068,f,c11e6fcc,0,c0e35918,c0665969,c0bc91a4,c0b1bf4c)
 at netbsd:vpanic+0x1e2
printf_nolog(c0bc91a4,c0b1bf4c,c0e35908,c010d957,8,c0c1f2c0,0,0,c0d08e20,0) 
at netbsd:printf_nolog
pci_decompose_tag(c0e3599c,0,0,10,0,ca675898,c0e35988,c0d08e20,c11b9200,0) 
at netbsd:pci_decompose_tag
acpi_pci_link_add_reference(c12011c0,0,0,10,0,ca41eb90,0,3,0,4) at 
netbsd:acpi_pci_link_add_reference+0xb2

mpacpi_find_interrupts(ca41eb90,c0116a4a,c0116a5e,0,ca41eb90,c0e35b50,c0e35aa8,c01180c7,c,c0116a4a)
 at netbsd:mpacpi_find_interrupts+0x5ea

acpi_md_callback(c,c0116a4a,c0116a5e,0,1,ca3fd7cc,1,c078e2e4,c0cb6ce0,ca435ea0) 
at netbsd:acpi_md_callback+0x1c

acpi_attach(ca660500,ca660d00,c0e35b50,0,c0e35b50,80,f,10,c0b5dcd9,c0e35b42) at 
netbsd:acpi_attach+0x14a

config_attach_loc(ca660500,c0c1d7a0,0,c0e35b50,0,0,2589,58421301,4350,53445842) 
at netbsd:config_attach_loc+0x176

config_found_ia(ca660500,c0b59f3c,c0e35b50,0,4f424101,20534843,80,f,c0c2bbe0,c0c2bc00)
 at netbsd:config_found_ia+0x36

mainbus_rescan(ca660500,c0b59f3c,0,ca660500,c0cb6ce0,c0bd71ce,c0e35bd8,c093575c,ca437f28,c0b8e0a1)
 at netbsd:mainbus_rescan+0x1c2

mainbus_attach(0,ca660500,0,c078f4b7,c0b59187,c0b59187,636f4200,7368,3001403,101)
 at netbsd:mainbus_attach+0xb4
config_attach_loc(0,c0c1bbb0,0,0,0,7368,f10,0,c0b59187,e3b000) at 
netbsd:config_attach_loc+0x176
config_attach(0,c0c1bbb0,0,0,1984,c0cc5680,c0e35cd8,c01f224e,c0b59187,0) at 
netbsd:config_attach+0x2e
config_rootfound(c0b59187,0,0,8,1984,1984,c0e35d40,c04b78d8,c0ba59a1,6) at 
netbsd:config_rootfound+0x42
cpu_configure(c0ba59a1,6,3,0,,f9b00,,f9300,0,0) at 
netbsd:cpu_configure+0x2a
main(0,0,0,0,0,0,0,0,0,0) at netbsd:main+0x2ba
db{0}

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

[Qemu-devel] [Bug 569760] Re: Error in i386 cmpxchg instruction emulation

[Andreas Gustafsson]

** Changed in: qemu
   Status: New = Fix Committed

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

Title:
  Error in i386 cmpxchg instruction emulation

Status in QEMU:
  Fix Committed

Bug description:
  As reported in

http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=42158

  programs using pthreads and fork() under NetBSD/i386 hang when the
  NetBSD system is run within qemu.

  This problem affects every version of qemu I have tested, including
  0.12.3.

  I have now tracked down the cause of the problem to a bug in qemu's
  emulation of the cmpxchg instruction.  Quoting the above bug report:

In a physical i386 CPU, the cmpxchg instruction performs a comparison
and read-modify-write memory cycle.  In the case where the comparison
outcome is unequal, the read-modify-write cycle is an effective
no-op, writing back the same value that was read, and the value of the
source operand is loaded into the accumulator.  Qemu attempts to
emulate this behavior including the redundant memory write.
   
To be precise, qemu first loads the accumulator and then does the
redundant memory write.  If a page fault occurs during the write, the
cmpxchg instruction will be restarted after handling the page fault,
but because the accumulator has already been changed, the comparison
will now incorrectly yield a result of equal, causing the memory
write to write the value from the source operand instead of re-writing
the original memory contents.

I assume fork() triggers the bug because it write protects pages to
implement copy-on-write, thereby producing a situation where the read
part of the cmpxchg read-modify-write cycle succeeds but the write
part causes a page fault.

Patching qemu to only change the accumulator after performing the
redundant write fixes the problem for me.

  I will attach a patch against qemu 0.12.3 shortly.

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

[Qemu-devel] [PATCH] target-i386: fix cmpxchg instruction emulation

[Andreas Gustafsson]

When the i386 cmpxchg instruction is executed with a memory operand
and the comparison result is unequal, do the memory write before
changing the accumulator instead of the other way around, because
otherwise the new accumulator value will incorrectly be used in the
comparison when the instruction is restarted after a page fault.

This bug was originally reported on 2010-04-25 as
https://bugs.launchpad.net/qemu/+bug/569760 

Signed-off-by: Andreas Gustafsson g...@gson.org
---
--- translate.c.orig2011-12-09 18:21:28.0 +0200
+++ translate.c 2011-12-09 18:21:24.0 +0200
@@ -4870,20 +4870,23 @@ static target_ulong disas_insn(DisasCont
 tcg_gen_sub_tl(t2, cpu_regs[R_EAX], t0);
 gen_extu(ot, t2);
 tcg_gen_brcondi_tl(TCG_COND_EQ, t2, 0, label1);
+label2 = gen_new_label();
 if (mod == 3) {
-label2 = gen_new_label();
 gen_op_mov_reg_v(ot, R_EAX, t0);
 tcg_gen_br(label2);
 gen_set_label(label1);
 gen_op_mov_reg_v(ot, rm, t1);
-gen_set_label(label2);
 } else {
-tcg_gen_mov_tl(t1, t0);
+/* perform no-op store cycle like physical cpu; must be
+   before changing accumulator to ensure idempotency if
+   the store faults and the instruction is restarted */
+gen_op_st_v(ot + s-mem_index, t0, a0);
 gen_op_mov_reg_v(ot, R_EAX, t0);
+tcg_gen_br(label2);
 gen_set_label(label1);
-/* always store */
 gen_op_st_v(ot + s-mem_index, t1, a0);
 }
+gen_set_label(label2);
 tcg_gen_mov_tl(cpu_cc_src, t0);
 tcg_gen_mov_tl(cpu_cc_dst, t2);
 s-cc_op = CC_OP_SUBB + ot;

Re: [Qemu-devel] [PATCH] target-i386: fix cmpxchg instruction emulation

[Andreas Gustafsson]

malc wrote:
 On Sat, 10 Dec 2011, Andreas Gustafsson wrote:
 
  When the i386 cmpxchg instruction is executed with a memory operand
  and the comparison result is unequal, do the memory write before
  changing the accumulator instead of the other way around, because
  otherwise the new accumulator value will incorrectly be used in the
  comparison when the instruction is restarted after a page fault.
  
  This bug was originally reported on 2010-04-25 as
  https://bugs.launchpad.net/qemu/+bug/569760 
 
 I'm starting to lose count on how many times this patch resurfaces here.

This was the first time I posted the patch to the list.  I originally
attached it to the bug launchpad ticket since the instructions
on the qemu web site at the time did not clearly indicate otherwise,
and was then specifically asked to send it to the mailing list.  It
took me some time, but that's what I just did.

 Please see http://web.archiveorange.com/archive/v/1XS1vaW9MlyMzguWl5fE
 and the links in the thread.

Thank you for the links.  This is the first time I see them, as no one
had CC:d me on that discussion, nor updated the launchpad ticket.

I found http://emulators.com/docs/nx33_qemu_0125.htm especially
illuminating.  It should be required reading for anyone contemplating
the use of qemu for x86 emulation.

In your message of 8 Sep 2010 (which I never received), you said:
 This is tab damaged.

This has already been addressed in the version I sent to the list
today.

 Secondly it looks as if this addresses only a small part of a general
 problem [1],

Since the general problem still hasn't been addressed, the partial fix
is still better than nothing.  It is being applied as part of the
local qemu patches in pkgsrc (www.pkgsrc.org), and has enabled the use
of qemu for extensive automated regression testing of NetBSD which
would not be possible without the patch.

 also in a very naive and inefficient way,

Inefficient in what way?  The generated code only grows by a single
unconditional branch.

 while also opening a hole can of worms (should real parallel execution
 for TCG be ever implemented)

Would you care to explain what this can of worms is, and how it is
not already open in the original code?
-- 
Andreas Gustafsson, g...@gson.org

Re: [Qemu-devel] [PATCH] target-i386: fix cmpxchg instruction emulation

[Andreas Gustafsson]

malc wrote:
  Inefficient in what way?  The generated code only grows by a single
  unconditional branch.
 
 The generated code grows by a memory write

Yes, an additional store instruction is generated, but the number of
store instructions *executed* does not change.  The original code
already does a store in both the compare-equal and the compare-unequal
case, by branching to the same store instruction; with my patch, a
store is still done in both cases, but the store instruction executed
is a separate one in each.

 (which is not what the hardware does).

The hardware does an atomic read-modify-write; qemu emulates this as a
separate read and write, and like the hardware, always does the write
part whether or not the modify part actually modified the data.  My
patch does *not* change this in any way.

 I recall having discussion aboutit with Fabrcie (in private) and i
 blieve (and if my memory serves me) we came to the conclusion that
 there's a way forward w.r.t. to this issue i just never came around of
 implementing it, i can try to dig out the old mails and share the
 highlights with you if you are interested.

Yes, please.
-- 
Andreas Gustafsson, g...@gson.org

[Qemu-devel] [Bug 897771] Re: qemu 1.0-rc4 no longer able to boot NetBSD-current/i386

[Andreas Gustafsson]

 Please try to find what is the last major release of qemu that did
boot this correctly.

I assume this is unecessary because Stefan Weil already identified the
excact commit where the problem appeared.

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

Title:
  qemu 1.0-rc4 no longer able to boot NetBSD-current/i386

Status in QEMU:
  Confirmed

Bug description:
  Booting a NetBSD-current/i386 install CD using qemu 1.0-rc4 fails. The
  same CD does boot in earlier versions of qemu, for example, 0.11.0.

  To reproduce, download the

http://www.gson.org/netbsd/bugs/qemu/boot-com-20270050Z.iso

  and attempt to boot it with:

qemu -nographic -cdrom boot-com-20270050Z.iso

  This fails with a guest kernel panic:

NetBSD 5.99.57 (GENERIC) #0: Sun Nov 27 07:41:56 UTC 2011

bui...@b8.netbsd.org:/home/builds/ab/HEAD/i386/20270050Z-obj/home/builds/ab/HEAD/src/sys/arch/i386/compile/GENERIC
total memory = 127 MB
avail memory = 112 MB
cprng kernel: WARNING insufficient entropy at creation.
mainbus0 (root)
cpu0 at mainbus0 apid 0: QEMU Virtual CPU version 0.15.93, id 0x633
ioapic0 at mainbus0 apid 1
acpi0 at mainbus0: Intel ACPICA 20110623
panic: pci_make_tag: bad request
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip c0269b04 cs 8 eflags 282 cr2 0 ilevel 8
Stopped in pid 0.1 (system) at  netbsd:breakpoint+0x4:  popl%ebp
db{0}  t

breakpoint(c0c04c75,c0cc2f80,c0bc91a4,c0e358e4,2,c11b70d6,c0e35908,c053999d,c0cdef20,0)
 at netbsd:breakpoint+0x4

vpanic(c0bc91a4,c0e358e4,c117d068,f,c11e6fcc,0,c0e35918,c0665969,c0bc91a4,c0b1bf4c)
 at netbsd:vpanic+0x1e2
printf_nolog(c0bc91a4,c0b1bf4c,c0e35908,c010d957,8,c0c1f2c0,0,0,c0d08e20,0) 
at netbsd:printf_nolog
pci_decompose_tag(c0e3599c,0,0,10,0,ca675898,c0e35988,c0d08e20,c11b9200,0) 
at netbsd:pci_decompose_tag
acpi_pci_link_add_reference(c12011c0,0,0,10,0,ca41eb90,0,3,0,4) at 
netbsd:acpi_pci_link_add_reference+0xb2

mpacpi_find_interrupts(ca41eb90,c0116a4a,c0116a5e,0,ca41eb90,c0e35b50,c0e35aa8,c01180c7,c,c0116a4a)
 at netbsd:mpacpi_find_interrupts+0x5ea

acpi_md_callback(c,c0116a4a,c0116a5e,0,1,ca3fd7cc,1,c078e2e4,c0cb6ce0,ca435ea0) 
at netbsd:acpi_md_callback+0x1c

acpi_attach(ca660500,ca660d00,c0e35b50,0,c0e35b50,80,f,10,c0b5dcd9,c0e35b42) at 
netbsd:acpi_attach+0x14a

config_attach_loc(ca660500,c0c1d7a0,0,c0e35b50,0,0,2589,58421301,4350,53445842) 
at netbsd:config_attach_loc+0x176

config_found_ia(ca660500,c0b59f3c,c0e35b50,0,4f424101,20534843,80,f,c0c2bbe0,c0c2bc00)
 at netbsd:config_found_ia+0x36

mainbus_rescan(ca660500,c0b59f3c,0,ca660500,c0cb6ce0,c0bd71ce,c0e35bd8,c093575c,ca437f28,c0b8e0a1)
 at netbsd:mainbus_rescan+0x1c2

mainbus_attach(0,ca660500,0,c078f4b7,c0b59187,c0b59187,636f4200,7368,3001403,101)
 at netbsd:mainbus_attach+0xb4
config_attach_loc(0,c0c1bbb0,0,0,0,7368,f10,0,c0b59187,e3b000) at 
netbsd:config_attach_loc+0x176
config_attach(0,c0c1bbb0,0,0,1984,c0cc5680,c0e35cd8,c01f224e,c0b59187,0) at 
netbsd:config_attach+0x2e
config_rootfound(c0b59187,0,0,8,1984,1984,c0e35d40,c04b78d8,c0ba59a1,6) at 
netbsd:config_rootfound+0x42
cpu_configure(c0ba59a1,6,3,0,,f9b00,,f9300,0,0) at 
netbsd:cpu_configure+0x2a
main(0,0,0,0,0,0,0,0,0,0) at netbsd:main+0x2ba
db{0}

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

[Qemu-devel] [Bug 897771] [NEW] qemu 1.0-rc4 no longer able to boot NetBSD-current/i386

[Andreas Gustafsson]

Public bug reported:

Booting a NetBSD-current/i386 install CD using qemu 1.0-rc4 fails. The
same CD does boot in earlier versions of qemu, for example, 0.11.0.

To reproduce, download the

  http://www.gson.org/netbsd/bugs/qemu/boot-com-20270050Z.iso

and attempt to boot it with:

  qemu -nographic -cdrom boot-com-20270050Z.iso

This fails with a guest kernel panic:

  NetBSD 5.99.57 (GENERIC) #0: Sun Nov 27 07:41:56 UTC 2011
  
bui...@b8.netbsd.org:/home/builds/ab/HEAD/i386/20270050Z-obj/home/builds/ab/HEAD/src/sys/arch/i386/compile/GENERIC
  total memory = 127 MB
  avail memory = 112 MB
  cprng kernel: WARNING insufficient entropy at creation.
  mainbus0 (root)
  cpu0 at mainbus0 apid 0: QEMU Virtual CPU version 0.15.93, id 0x633
  ioapic0 at mainbus0 apid 1
  acpi0 at mainbus0: Intel ACPICA 20110623
  panic: pci_make_tag: bad request
  fatal breakpoint trap in supervisor mode
  trap type 1 code 0 eip c0269b04 cs 8 eflags 282 cr2 0 ilevel 8
  Stopped in pid 0.1 (system) at  netbsd:breakpoint+0x4:  popl%ebp
  db{0}  t
  
breakpoint(c0c04c75,c0cc2f80,c0bc91a4,c0e358e4,2,c11b70d6,c0e35908,c053999d,c0cdef20,0)
 at netbsd:breakpoint+0x4
  
vpanic(c0bc91a4,c0e358e4,c117d068,f,c11e6fcc,0,c0e35918,c0665969,c0bc91a4,c0b1bf4c)
 at netbsd:vpanic+0x1e2
  printf_nolog(c0bc91a4,c0b1bf4c,c0e35908,c010d957,8,c0c1f2c0,0,0,c0d08e20,0) 
at netbsd:printf_nolog
  pci_decompose_tag(c0e3599c,0,0,10,0,ca675898,c0e35988,c0d08e20,c11b9200,0) at 
netbsd:pci_decompose_tag
  acpi_pci_link_add_reference(c12011c0,0,0,10,0,ca41eb90,0,3,0,4) at 
netbsd:acpi_pci_link_add_reference+0xb2
  
mpacpi_find_interrupts(ca41eb90,c0116a4a,c0116a5e,0,ca41eb90,c0e35b50,c0e35aa8,c01180c7,c,c0116a4a)
 at netbsd:mpacpi_find_interrupts+0x5ea
  
acpi_md_callback(c,c0116a4a,c0116a5e,0,1,ca3fd7cc,1,c078e2e4,c0cb6ce0,ca435ea0) 
at netbsd:acpi_md_callback+0x1c
  acpi_attach(ca660500,ca660d00,c0e35b50,0,c0e35b50,80,f,10,c0b5dcd9,c0e35b42) 
at netbsd:acpi_attach+0x14a
  
config_attach_loc(ca660500,c0c1d7a0,0,c0e35b50,0,0,2589,58421301,4350,53445842) 
at netbsd:config_attach_loc+0x176
  
config_found_ia(ca660500,c0b59f3c,c0e35b50,0,4f424101,20534843,80,f,c0c2bbe0,c0c2bc00)
 at netbsd:config_found_ia+0x36
  
mainbus_rescan(ca660500,c0b59f3c,0,ca660500,c0cb6ce0,c0bd71ce,c0e35bd8,c093575c,ca437f28,c0b8e0a1)
 at netbsd:mainbus_rescan+0x1c2
  
mainbus_attach(0,ca660500,0,c078f4b7,c0b59187,c0b59187,636f4200,7368,3001403,101)
 at netbsd:mainbus_attach+0xb4
  config_attach_loc(0,c0c1bbb0,0,0,0,7368,f10,0,c0b59187,e3b000) at 
netbsd:config_attach_loc+0x176
  config_attach(0,c0c1bbb0,0,0,1984,c0cc5680,c0e35cd8,c01f224e,c0b59187,0) at 
netbsd:config_attach+0x2e
  config_rootfound(c0b59187,0,0,8,1984,1984,c0e35d40,c04b78d8,c0ba59a1,6) at 
netbsd:config_rootfound+0x42
  cpu_configure(c0ba59a1,6,3,0,,f9b00,,f9300,0,0) at 
netbsd:cpu_configure+0x2a
  main(0,0,0,0,0,0,0,0,0,0) at netbsd:main+0x2ba
  db{0}

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  qemu 1.0-rc4 no longer able to boot NetBSD-current/i386

Status in QEMU:
  New

Bug description:
  Booting a NetBSD-current/i386 install CD using qemu 1.0-rc4 fails. The
  same CD does boot in earlier versions of qemu, for example, 0.11.0.

  To reproduce, download the

http://www.gson.org/netbsd/bugs/qemu/boot-com-20270050Z.iso

  and attempt to boot it with:

qemu -nographic -cdrom boot-com-20270050Z.iso

  This fails with a guest kernel panic:

NetBSD 5.99.57 (GENERIC) #0: Sun Nov 27 07:41:56 UTC 2011

bui...@b8.netbsd.org:/home/builds/ab/HEAD/i386/20270050Z-obj/home/builds/ab/HEAD/src/sys/arch/i386/compile/GENERIC
total memory = 127 MB
avail memory = 112 MB
cprng kernel: WARNING insufficient entropy at creation.
mainbus0 (root)
cpu0 at mainbus0 apid 0: QEMU Virtual CPU version 0.15.93, id 0x633
ioapic0 at mainbus0 apid 1
acpi0 at mainbus0: Intel ACPICA 20110623
panic: pci_make_tag: bad request
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip c0269b04 cs 8 eflags 282 cr2 0 ilevel 8
Stopped in pid 0.1 (system) at  netbsd:breakpoint+0x4:  popl%ebp
db{0}  t

breakpoint(c0c04c75,c0cc2f80,c0bc91a4,c0e358e4,2,c11b70d6,c0e35908,c053999d,c0cdef20,0)
 at netbsd:breakpoint+0x4

vpanic(c0bc91a4,c0e358e4,c117d068,f,c11e6fcc,0,c0e35918,c0665969,c0bc91a4,c0b1bf4c)
 at netbsd:vpanic+0x1e2
printf_nolog(c0bc91a4,c0b1bf4c,c0e35908,c010d957,8,c0c1f2c0,0,0,c0d08e20,0) 
at netbsd:printf_nolog
pci_decompose_tag(c0e3599c,0,0,10,0,ca675898,c0e35988,c0d08e20,c11b9200,0) 
at netbsd:pci_decompose_tag
acpi_pci_link_add_reference(c12011c0,0,0,10,0,ca41eb90,0,3,0,4) at 
netbsd:acpi_pci_link_add_reference+0xb2

mpacpi_find_interrupts(ca41eb90,c0116a4a,c0116a5e,0,ca41eb90,c0e35b50,c0e35aa8,c01180c7,c,c0116a4a)
 at