* [Qemu-devel] [Bug 1154328] [NEW] qemu locks up on typing 41 characters at once into serial console
@ 2013-03-12 21:31 Andreas Gustafsson
2013-04-01 6:56 ` Amit Shah
` (4 more replies)
0 siblings, 5 replies; 7+ messages in thread
From: Andreas Gustafsson @ 2013-03-12 21:31 UTC (permalink / raw)
To: qemu-devel
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 <aliguori@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 <aliguori@us.ibm.com>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Message-id: 0cb5d14510ee835a0ebc23676d10a2cce9280da5.1362505276.git.amit.shah@redhat.com
Signed-off-by: Anthony Liguori <aliguori@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 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 <aliguori@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 <aliguori@us.ibm.com>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Message-id: 0cb5d14510ee835a0ebc23676d10a2cce9280da5.1362505276.git.amit.shah@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1154328/+subscriptions
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] [Bug 1154328] [NEW] qemu locks up on typing 41 characters at once into serial console
2013-03-12 21:31 [Qemu-devel] [Bug 1154328] [NEW] qemu locks up on typing 41 characters at once into serial console Andreas Gustafsson
@ 2013-04-01 6:56 ` Amit Shah
2013-04-01 17:04 ` Aurelien Jarno
2013-04-07 15:51 ` [Qemu-devel] [Bug 1154328] " Andreas Gustafsson
` (3 subsequent siblings)
4 siblings, 1 reply; 7+ messages in thread
From: Amit Shah @ 2013-04-01 6:56 UTC (permalink / raw)
To: Bug 1154328; +Cc: Anthony Liguori, qemu-devel, aurelien
On (Tue) 12 Mar 2013 [21:31:29], Andreas Gustafsson wrote:
> 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 <aliguori@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.
Does
[PATCH] qemu-char: rewrite io_channel_send_all and drop the '_all' suffix
that's on the list help?
If not, does reverting fcfb4d6aae611d1f804d486d3c998000912c4c81 help?
(That is "serial: add flow control to transmit").
Amit
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] [Bug 1154328] [NEW] qemu locks up on typing 41 characters at once into serial console
2013-04-01 6:56 ` Amit Shah
@ 2013-04-01 17:04 ` Aurelien Jarno
0 siblings, 0 replies; 7+ messages in thread
From: Aurelien Jarno @ 2013-04-01 17:04 UTC (permalink / raw)
To: Amit Shah; +Cc: Bug 1154328, qemu-devel, Anthony Liguori
On Mon, Apr 01, 2013 at 12:26:16PM +0530, Amit Shah wrote:
> On (Tue) 12 Mar 2013 [21:31:29], Andreas Gustafsson wrote:
>
> > 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 <aliguori@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.
>
> Does
>
> [PATCH] qemu-char: rewrite io_channel_send_all and drop the '_all' suffix
>
> that's on the list help?
No, it doesn't.
> If not, does reverting fcfb4d6aae611d1f804d486d3c998000912c4c81 help?
>
> (That is "serial: add flow control to transmit").
It also doesn't help.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Qemu-devel] [Bug 1154328] Re: qemu locks up on typing 41 characters at once into serial console
2013-03-12 21:31 [Qemu-devel] [Bug 1154328] [NEW] qemu locks up on typing 41 characters at once into serial console Andreas Gustafsson
2013-04-01 6:56 ` Amit Shah
@ 2013-04-07 15:51 ` Andreas Gustafsson
2013-04-10 15:50 ` Andreas Gustafsson
` (2 subsequent siblings)
4 siblings, 0 replies; 7+ messages in thread
From: Andreas Gustafsson @ 2013-04-07 15:51 UTC (permalink / raw)
To: qemu-devel
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 <aliguori@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 <aliguori@us.ibm.com>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Message-id: 0cb5d14510ee835a0ebc23676d10a2cce9280da5.1362505276.git.amit.shah@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1154328/+subscriptions
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Qemu-devel] [Bug 1154328] Re: qemu locks up on typing 41 characters at once into serial console
2013-03-12 21:31 [Qemu-devel] [Bug 1154328] [NEW] qemu locks up on typing 41 characters at once into serial console Andreas Gustafsson
2013-04-01 6:56 ` Amit Shah
2013-04-07 15:51 ` [Qemu-devel] [Bug 1154328] " Andreas Gustafsson
@ 2013-04-10 15:50 ` Andreas Gustafsson
2013-05-17 18:00 ` Andreas Gustafsson
2013-05-20 17:31 ` Aurelien Jarno
4 siblings, 0 replies; 7+ messages in thread
From: Andreas Gustafsson @ 2013-04-10 15:50 UTC (permalink / raw)
To: qemu-devel
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 <aliguori@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 <aliguori@us.ibm.com>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Message-id: 0cb5d14510ee835a0ebc23676d10a2cce9280da5.1362505276.git.amit.shah@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1154328/+subscriptions
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Qemu-devel] [Bug 1154328] Re: qemu locks up on typing 41 characters at once into serial console
2013-03-12 21:31 [Qemu-devel] [Bug 1154328] [NEW] qemu locks up on typing 41 characters at once into serial console Andreas Gustafsson
` (2 preceding siblings ...)
2013-04-10 15:50 ` Andreas Gustafsson
@ 2013-05-17 18:00 ` Andreas Gustafsson
2013-05-20 17:31 ` Aurelien Jarno
4 siblings, 0 replies; 7+ messages in thread
From: Andreas Gustafsson @ 2013-05-17 18:00 UTC (permalink / raw)
To: qemu-devel
** 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 <aliguori@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 <aliguori@us.ibm.com>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Message-id: 0cb5d14510ee835a0ebc23676d10a2cce9280da5.1362505276.git.amit.shah@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1154328/+subscriptions
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Qemu-devel] [Bug 1154328] Re: qemu locks up on typing 41 characters at once into serial console
2013-03-12 21:31 [Qemu-devel] [Bug 1154328] [NEW] qemu locks up on typing 41 characters at once into serial console Andreas Gustafsson
` (3 preceding siblings ...)
2013-05-17 18:00 ` Andreas Gustafsson
@ 2013-05-20 17:31 ` Aurelien Jarno
4 siblings, 0 replies; 7+ messages in thread
From: Aurelien Jarno @ 2013-05-20 17:31 UTC (permalink / raw)
To: qemu-devel
** Changed in: qemu
Status: Fix Committed => 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/1154328
Title:
qemu locks up on typing 41 characters at once into serial console
Status in QEMU:
Fix Released
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 <aliguori@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 <aliguori@us.ibm.com>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Message-id: 0cb5d14510ee835a0ebc23676d10a2cce9280da5.1362505276.git.amit.shah@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1154328/+subscriptions
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-05-20 17:41 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-12 21:31 [Qemu-devel] [Bug 1154328] [NEW] qemu locks up on typing 41 characters at once into serial console Andreas Gustafsson
2013-04-01 6:56 ` Amit Shah
2013-04-01 17:04 ` Aurelien Jarno
2013-04-07 15:51 ` [Qemu-devel] [Bug 1154328] " Andreas Gustafsson
2013-04-10 15:50 ` Andreas Gustafsson
2013-05-17 18:00 ` Andreas Gustafsson
2013-05-20 17:31 ` Aurelien Jarno
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.