[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [Bug 1181796] Re: Qemu locks up when incoming serial fills
From: |
Evan Green |
Subject: |
[Qemu-devel] [Bug 1181796] Re: Qemu locks up when incoming serial fills up |
Date: |
Wed, 22 May 2013 06:02:08 -0000 |
The following patch gets things moving again for me. It only reports
that the poll was satisfied if there was data that could be written to
the destination. While it successfully opens up a window where the I/O
thread is unlocked (previously there was no such window, hence the
hang), it's far from ideal.
Someone with more familiarity than me could consider an approach where
descriptors that have responded to the poll but are unable to be acted
on are temporarily disabled or removed from the list. This would allow
the main thread to quiet back down, rather than aggressively spinning
locking and unlocking the global mutex, which puts a drag on the VCPU
threads that need to acquire the same lock and do real work.
The line numbers here might not line up, but you get the idea.
--- qemu-char.c.orig2 2013-05-19 22:27:16 -0700
+++ qemu-char.c 2013-05-19 23:49:38 -0700
@@ -1650,6 +1650,7 @@
static int win_chr_poll(void *opaque)
{
+ int available;
CharDriverState *chr = opaque;
WinCharState *s = chr->opaque;
COMSTAT status;
@@ -1658,9 +1659,9 @@
ClearCommError(s->hcom, &comerr, &status);
if (status.cbInQue > 0) {
s->len = status.cbInQue;
- win_chr_read_poll(chr);
+ available = win_chr_read_poll(chr);
win_chr_read(chr);
- return 1;
+ return available != 0;
}
return 0;
}
@@ -1692,6 +1693,7 @@
static int win_chr_pipe_poll(void *opaque)
{
+ int available;
CharDriverState *chr = opaque;
WinCharState *s = chr->opaque;
DWORD size;
@@ -1699,9 +1701,9 @@
PeekNamedPipe(s->hcom, NULL, 0, NULL, &size, NULL);
if (size > 0) {
s->len = size;
- win_chr_read_poll(chr);
+ available = win_chr_read_poll(chr);
win_chr_read(chr);
- return 1;
+ return available != 0;
}
return 0;
}
--
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