** 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
St
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:
Fix
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.
https://bugs.launchpad.
** 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:
Con
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 y
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 withou
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
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_
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 “qemu
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 remove-7c7db75
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 incre
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
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 comm
Jamie Heilman (the debian bug #680719 reporter) bisected this issue to
this commit:
7c7db75576bd5a31508208f153c5aada64b2c8df is the first bad commit
commit 7c7db75576bd5a31508208f153c5aada64b2c8df
Author: Stefano Stabellini
Date: Fri Apr 13 19:35:04 2012 +0100
main_loop_wait: block indefin
** 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:
Confi
** 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 “qemu
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-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
Sta
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 requires
** 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:
qem
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 because
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:
qe
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 fo
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
** 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
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 waits
26 matches
Mail list logo
