** Changed in: qemu
Status: Incomplete => 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/1021649
Title:
qemu 1.1.0 waits for a keypress at boot
Status in QEMU:
Fix Released
No this refers to a very old version of qemu. This bug should 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/1021649
Title:
qemu 1.1.0 waits for a keypress at boot
Status in QEMU:
Can this issue still be reproduced with the latest version of QEMU, or
can we close this bug nowadays?
** Changed in: qemu
Status: Confirmed => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
** Changed in: qemu-kvm (Debian)
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/1021649
Title:
qemu 1.1.0 waits for a keypress at boot
Status in QEMU:
The patch at http://permalink.gmane.org/gmane.comp.emulators.qemu/162828
fixes it for ioeventfd=on (the bug is that the ioeventfd is not added to
the select() arguments), but I and Avi disagreed on whether
ioeventfd=off works. :)
Jamie/Richard/Georg, can you test your respective reproducers
Paolo Bonzini wrote:
The patch at http://permalink.gmane.org/gmane.comp.emulators.qemu/162828
fixes it for ioeventfd=on (the bug is that the ioeventfd is not added to
the select() arguments), but I and Avi disagreed on whether
ioeventfd=off works. :)
Jamie/Richard/Georg, can you test your
On 08/04/2012 07:58 AM, Jamie Heilman wrote:
Avi Kivity wrote:
On 07/25/2012 02:12 PM, Stefano Stabellini wrote:
On Wed, 25 Jul 2012, Michael Tokarev wrote:
Stefano, Paul, can you take a look please?
https://bugs.launchpad.net/bugs/1021649
That is a very good bug triage that you
Avi Kivity wrote:
On 07/25/2012 02:12 PM, Stefano Stabellini wrote:
On Wed, 25 Jul 2012, Michael Tokarev wrote:
Stefano, Paul, can you take a look please?
https://bugs.launchpad.net/bugs/1021649
That is a very good bug triage that you did!
However main_loop_wait: block
This is definitely a wrong way to fix this issue.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649
Title:
qemu 1.1.0 waits for a keypress at boot
Status in QEMU:
Confirmed
Status in
Jamie Heilman (the debian bug #680719 reporter) bisected this issue to
this commit:
7c7db75576bd5a31508208f153c5aada64b2c8df is the first bad commit
commit 7c7db75576bd5a31508208f153c5aada64b2c8df
Author: Stefano Stabellini stefano.stabell...@eu.citrix.com
Date: Fri Apr 13 19:35:04 2012 +0100
Stefano, Paul, can you take a look please?
https://bugs.launchpad.net/bugs/1021649
Thanks,
/mjt
On 25.07.2012 12:25, Michael Tokarev wrote:
Jamie Heilman (the debian bug #680719 reporter) bisected this issue to
this commit:
7c7db75576bd5a31508208f153c5aada64b2c8df is the first bad commit
On Wed, 25 Jul 2012, Michael Tokarev wrote:
Stefano, Paul, can you take a look please?
https://bugs.launchpad.net/bugs/1021649
That is a very good bug triage that you did!
However main_loop_wait: block indefinitely only increases the maximum
select timeout of QEMU's main_loop.
That mean that
On 07/25/2012 02:12 PM, Stefano Stabellini wrote:
On Wed, 25 Jul 2012, Michael Tokarev wrote:
Stefano, Paul, can you take a look please?
https://bugs.launchpad.net/bugs/1021649
That is a very good bug triage that you did!
However main_loop_wait: block indefinitely only increases the
I encountered the same thing and created a patch that fixes the problem
for me.
This is not a real fix. All i have done is the following:
- Clone the repo.
- Get a reverse diff for the commit in question git diff 7c7db75..4ffd16f
foo1.patch.
- Try to apply this on master patch foo1.patch and
** Changed in: qemu-kvm (Debian)
Status: Incomplete = Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649
Title:
qemu 1.1.0 waits for a keypress at boot
Status in QEMU:
Well that's very interesting because one of the patches we have added in
Fedora is:
http://pkgs.fedoraproject.org/gitweb/?p=qemu.git;a=blob;f=0001-qemu-kvm-
Add-missing-default-machine-
options.patch;h=e785a708d0bf0861c2f0f1777b8cc477d12fe145;hb=HEAD
--
You received this bug notification
** Changed in: qemu
Status: Invalid = 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/1021649
Title:
qemu 1.1.0 waits for a keypress at boot
Status in QEMU:
New
Bug description:
This is a bit more interesting. I've got a bugreport in debian about
the same thing, and verified it in debian qemu-kvm package - indeed,
with -nographics, upstream 1.1 qemu and qemu-kvm refuses to boot without
an extra keypress, but only when kernel_irqchip is enabled. Ie, the
following
** Changed in: qemu-kvm (Debian)
Status: Unknown = Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649
Title:
qemu 1.1.0 waits for a keypress at boot
Status in QEMU:
New
when the guest is waiting for the keypress, it is sitting in KVM_RUN
ioctl and eating 100% CPU. When enabling Seabios debugging, the last
lines before the stall is this:
Returned 57344 bytes of ZoneHigh
e820 map has 7 items:
0: - 0009dc00 = 1 RAM
1: 0009dc00
** Changed in: qemu
Status: New = Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649
Title:
qemu 1.1.0 waits for a keypress at boot
Status in QEMU:
Confirmed
Status in
I don't see this problem. Are you sure you're not using the bios from
Fedora? Perhaps it's configured incorrectly.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649
Title:
qemu 1.1.0 waits
Yes, I tested it again and it does look like it's loading a Fedora ROM.
Dammit ...
** Changed in: qemu
Status: New = Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649
Title:
Also affects upstream qemu from git.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649
Title:
qemu 1.1.0 waits for a keypress at boot
Status in QEMU:
New
Bug description:
qemu 1.1.0
** Attachment added: test-qemu.sh
https://bugs.launchpad.net/bugs/1021649/+attachment/3214808/+files/test-qemu.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/1021649
Title:
qemu 1.1.0 waits
Using -device sga fixes the problem, but also means I cannot see what
it's trying to wait for.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649
Title:
qemu 1.1.0 waits for a keypress at boot
26 matches
Mail list logo
