.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 Gusta
? 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 wit
** 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:
Philippe Mathieu-Daudé wrote:
> Thanks, can I add "Tested-by: Andreas Gustafsson "
> to the patch?
Fine by me.
--
Andreas Gustafsson, g...@gson.org
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
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_acces
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
> 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 reprod
> 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
> 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 subsc
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:/
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
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% n
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 bisectio
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
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://la
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
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.
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 subscribe
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
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 optimiz
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
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 AC
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
: Andreas Gustafsson
---
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
is smaller than a page.
Signed-off-by: Andreas Gustafsson
---
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
@@ -457
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:
N
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 sysca
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/ab
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
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, b
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
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
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 li
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
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 fa
ot
present" message, so I ran "git submodule update --init pixman" and
reconfigured. After that, qemu built successfully.
Thanks,
--
Andreas Gustafsson, g...@gson.org
IXMAN_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
I
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
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 descr
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 beca
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 fast
Looks like the lack of initial bug submissions only affects the thread
indices of the archives on lists.gnu.org - the date indices are OK.
Does anyone know what might cause this and/or how to get it fixed?
--
Andreas Gustafsson, g...@gson.org
/qemu-devel/2013-05/threads.html
--
Andreas Gustafsson, g...@gson.org
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
** 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 Commit
** 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 QEM
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 notificatio
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
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.
h
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)
57c0b9fa7ee04d2871a6e48a41f119c469,
works as expected.
--
Andreas Gustafsson, g...@gson.org
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1127369/+subscriptions
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
3c7d5678c6edd.
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 re
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
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/Ne
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
Date: Wed Sep 19 12:
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
> 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"
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
Date: Sun Jul 24 17:47:18 2011 +0300
pci_host: convert conf index and data ports to memory API
** 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
it 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
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 aro
n 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
---
--- translate.c.orig2011-12-09 18:21:28.0 +0200
+++ translate.c 2011-12-09 18:21:24.0 +0200
@
> 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 su
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 -nogr
66 matches
Mail list logo
