[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: |
Mon, 20 May 2013 00:26:13 -0000 |
Some food for thought:
* os_host_main_loop_wait quickly calls "unlock IO thread", poll, "lock IO
thread".
* win_chr_pipe_poll calls PeekNamedPipe, which would report data available,
satisfying the poll.
* win_chr_read_poll calls qemu_chr_be_can_write, which I think calls
serial_can_receive1, which might say sorry, no space.
* win_chr_read would then bail as s->max_size is zero, skipping the call to
ReadFile.
So perhaps the poll was satisfied, but no data was ever read from that
pipe, putting it in a tight loop? The non-Windows version of
os_host_main_loop_wait has some sort of MAX_MAIN_LOOP_SPIN valve in
which the comment suggests the VCPU threads could starve. Could this be
happening in the Windows version as well?
--
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |