[Qemu-devel] [Bug 1181796] Re: Qemu locks up when incoming serial fills up

[Evan Green]

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