[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [Bug 1181796] [NEW] Qemu locks up when incoming serial fill
From: |
Evan Green |
Subject: |
[Qemu-devel] [Bug 1181796] [NEW] Qemu locks up when incoming serial fills up |
Date: |
Sun, 19 May 2013 16:48:58 -0000 |
Public bug reported:
I'm using Windows, I'm not sure if this happens on Linux, but for all I
know it does. To repro, fire up any image (ideally one that does almost
nothing, and doesn't read the serial port), and use the option "-serial
pipe:mypipe". Then use Putty or something else to connect to that named
pipe so Qemu starts up. Now start typing into Putty. For a VM image that
never reads the serial port, upon typing the 16th character Qemu stops
executing instructions in the guest (as evidenced either by being unable
to step in gdb, seeing that "info registers" in the monitor always
reports the same value, or just by observing that the guest is hung).
For OS images that do regularly read the serial port, this may require
pasting >16 bytes into Putty at once. This occurs with more than just
Putty, use anything that can write at a named pipe.
I would have expected that bytes get dropped, or even more ideally
blocked at the sender's side of the named pipe. I would not expect that
the entire VM stops. You seem to be able to unwedge the VM by switching
to the monitor and running "i /1c 0x3f8" until you've pulled enough out
of buffer that it's happy to run again. Interestingly, all bytes seem to
come through (more than just the 16) when read from the monitor.
I haven't been able to get a source environment set up, but I have tried
a few of the Windows binaries. This repros in 1.4.1, 1.3.0, 1.2, and
1.0, the most recent build I found that did not have this behavior was
0.15.0.
Maybe I'm missing something very obvious, and if so, I apologize in
advance. I'm also happy to create an OS image that highlights this
problem if it would help.
** 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/1181796
Title:
Qemu locks up when incoming serial fills up
Status in QEMU:
New
Bug description:
I'm using Windows, I'm not sure if this happens on Linux, but for all
I know it does. To repro, fire up any image (ideally one that does
almost nothing, and doesn't read the serial port), and use the option
"-serial pipe:mypipe". Then use Putty or something else to connect to
that named pipe so Qemu starts up. Now start typing into Putty. For a
VM image that never reads the serial port, upon typing the 16th
character Qemu stops executing instructions in the guest (as evidenced
either by being unable to step in gdb, seeing that "info registers" in
the monitor always reports the same value, or just by observing that
the guest is hung). For OS images that do regularly read the serial
port, this may require pasting >16 bytes into Putty at once. This
occurs with more than just Putty, use anything that can write at a
named pipe.
I would have expected that bytes get dropped, or even more ideally
blocked at the sender's side of the named pipe. I would not expect
that the entire VM stops. You seem to be able to unwedge the VM by
switching to the monitor and running "i /1c 0x3f8" until you've pulled
enough out of buffer that it's happy to run again. Interestingly, all
bytes seem to come through (more than just the 16) when read from the
monitor.
I haven't been able to get a source environment set up, but I have
tried a few of the Windows binaries. This repros in 1.4.1, 1.3.0, 1.2,
and 1.0, the most recent build I found that did not have this behavior
was 0.15.0.
Maybe I'm missing something very obvious, and if so, I apologize in
advance. I'm also happy to create an OS image that highlights this
problem if it would help.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1181796/+subscriptions
- [Qemu-devel] [RFC PATCH v1 00/20] Refactor PC machine to take advantage of QOM, Hu Tao, 2013/05/22
- [Qemu-devel] [RFC PATCH v1 01/20] i440fx: remove unused parameter i440fx_state of i440fx_init., Hu Tao, 2013/05/22
- [Qemu-devel] [RFC PATCH v1 06/20] piix3: prepare for composition, Hu Tao, 2013/05/22
- [Qemu-devel] [RFC PATCH v1 09/20] ich9: function rename, Hu Tao, 2013/05/22
- [Qemu-devel] [RFC PATCH v1 05/20] piix3: make PIIX3-xen a subclass of PIIX3, Hu Tao, 2013/05/22
- [Qemu-devel] [RFC PATCH v1 04/20] i440fx: prepare for composition, Hu Tao, 2013/05/22
- [Qemu-devel] [RFC PATCH v1 03/20] i440fx: rename i440FX-pcihost to i440FX, Hu Tao, 2013/05/22
- [Qemu-devel] [RFC PATCH v1 18/20] q35-mch: create pci address space, Hu Tao, 2013/05/22
- [Qemu-devel] [RFC PATCH v1 02/20] i440fx: rename i440FX to i440FX-PMC, Hu Tao, 2013/05/22
- [Qemu-devel] [RFC PATCH v1 10/20] piix3, ich9: create the HPET through composition, Hu Tao, 2013/05/22
- [Qemu-devel] [RFC PATCH v1 12/20] piix3, ich9: create the RTC through composition, Hu Tao, 2013/05/22