Ctrl-A b not working in 2.8.0

With a recent update from 2.7.0 to 2.8.0 I have discovered that I can no longer send a "break" to the VM.  Ctrl-A b is simply ignored.  Other Ctrl-A sequences seem to work correctly.

This is on a NetBSD amd64 system, version 7.99.53, and qemu was installed on this system from source.

Reverting to the previous install restores "break" capability.

I am also seeing this problem.  In case it was not clear from Paul's original report, it affects guests using a serial console.

Also, it is not specific to NetBSD.  I can reproduce it using a Linux guest on a Linux host, by running the following on a Debian 8 system:

  wget http://landley.net/aboriginal/downloads/old/binaries/1.4.5/system-image-i686.tar.gz
  tar xfz system-image-i686.tar.gz 
  cd system-image-i686
  sh run-emulator.sh 

and typing Control-A b m once the guest has started.

Using qemu 2.1.2, this successfully causes the guest to print a memory usage summary.  Using current qemu sources from git (dbe2b65566e76d3c3a0c3358285c0336ac61e757), nothing happens.


Hi

On Fri, Jan 6, 2017 at 2:46 PM Andreas Gustafsson <email address hidden> wrote:

> I am also seeing this problem.  In case it was not clear from Paul's
> original report, it affects guests using a serial console.
>
> Also, it is not specific to NetBSD.  I can reproduce it using a Linux
> guest on a Linux host, by running the following on a Debian 8 system:
>
>   wget
> http://landley.net/aboriginal/downloads/old/binaries/1.4.5/system-image-i686.tar.gz
>   tar xfz system-image-i686.tar.gz
>   cd system-image-i686
>   sh run-emulator.sh
>
> and typing Control-A b m once the guest has started.
>
> Using qemu 2.1.2, this successfully causes the guest to print a memory
> usage summary.  Using current qemu sources from git
> (dbe2b65566e76d3c3a0c3358285c0336ac61e757), nothing happens.
>
> --
> You received this bug notification because you are a member of qemu-
> devel-ml, which is subscribed to QEMU.
> https://bugs.launchpad.net/bugs/1654137
>
> Title:
>   Ctrl-A b not working in 2.8.0
>
> Status in QEMU:
>   New
>
> Bug description:
>   With a recent update from 2.7.0 to 2.8.0 I have discovered that I can
>   no longer send a "break" to the VM.  Ctrl-A b is simply ignored.
>   Other Ctrl-A sequences seem to work correctly.
>

It could be related to the chardev changes in 2.8, I am bisecting and
looking at it.

thanks


>   This is on a NetBSD amd64 system, version 7.99.53, and qemu was
>   installed on this system from source.
>
>   Reverting to the previous install restores "break" capability.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1654137/+subscriptions
>
> --
Marc-André Lureau


Hi

On Mon, Jan 9, 2017 at 4:39 PM Marc-André Lureau <email address hidden>
wrote:

> Hi
>
> On Fri, Jan 6, 2017 at 2:46 PM Andreas Gustafsson <email address hidden> wrote:
>
> I am also seeing this problem.  In case it was not clear from Paul's
> original report, it affects guests using a serial console.
>
> Also, it is not specific to NetBSD.  I can reproduce it using a Linux
> guest on a Linux host, by running the following on a Debian 8 system:
>
>   wget
> http://landley.net/aboriginal/downloads/old/binaries/1.4.5/system-image-i686.tar.gz
>   tar xfz system-image-i686.tar.gz
>   cd system-image-i686
>   sh run-emulator.sh
>
> and typing Control-A b m once the guest has started.
>
> Using qemu 2.1.2, this successfully causes the guest to print a memory
> usage summary.  Using current qemu sources from git
> (dbe2b65566e76d3c3a0c3358285c0336ac61e757), nothing happens.
>
> --
> You received this bug notification because you are a member of qemu-
> devel-ml, which is subscribed to QEMU.
> https://bugs.launchpad.net/bugs/1654137
>
> Title:
>   Ctrl-A b not working in 2.8.0
>
> Status in QEMU:
>   New
>
> Bug description:
>   With a recent update from 2.7.0 to 2.8.0 I have discovered that I can
>   no longer send a "break" to the VM.  Ctrl-A b is simply ignored.
>   Other Ctrl-A sequences seem to work correctly.
>
>
> It could be related to the chardev changes in 2.8, I am bisecting and
> looking at it.
>
>
it's a regression from commit a4afa548fc6dd9842ed866, I will send a fix
asap.


> thanks
>
>
>   This is on a NetBSD amd64 system, version 7.99.53, and qemu was
>   installed on this system from source.
>
>   Reverting to the previous install restores "break" capability.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1654137/+subscriptions
>
> --
> Marc-André Lureau
>
-- 
Marc-André Lureau


On Tue, Jan 10, 2017 at 12:23 PM Paolo Bonzini <email address hidden> wrote:



On 10/01/2017 12:06, Marc-André Lureau wrote:
> CharDriverState.be should be updated to point to the current
> associated backend.
>
> Fix the regression introduced in the "mux" chardev from commit
> a4afa548fc6dd9842ed86639b4d37d4d1c4ad480.
>
> https://bugs.launchpad.net/bugs/1654137

Queued.

However, can you also simplify mux_chr_accept_input, mux_chr_can_read
and mux_chr_read to use d->be directly, with this change?


Yes, not a big improvement though. I'll consider it in the reactoring
series (https://github.com/elmarco/qemu/commits/chrfe)
-- 
Marc-André Lureau


I can confirm that this bug is fixed in qemu 2.8.1

Thanks!

http://git.qemu.org/?p=qemu.git;a=commitdiff;h=fb5e19d2e1472e96d

This is broken again as of revision 7398166ddf7c6dbbc9cae6ac69bb2feda14b40ac.

Bisection shows it was broken by commit df85a78bf83d85627de27f492e78e73bbbd3df4a,
"char: move mux to its own file".  Somewhat confusingly, this commit predates the fix
(fb5e19d2e1472e96d72d5e4d89c20033f8ab345c), but it is part of a branch that was merged
after the fix, in merge commit 2d6752d38d8acda6aae674a72b72be05482a58eb.  Apparently
this caused a reversion to an old version of the mux code that still has the bug.

Credit for discovering the regression goes to Paul Goyette.


This bug is no longer fixed.  See also bug #1743191

This regression is still unfixed three months after being reported, and it's rendering qemu 2.11.1 unusable for my present use case, so I just reverted my system to the ever reliable qemu 0.15.1.



@elmarco could you take a look at this possible regression since bisect claims it was due to the mux refactor

Fixed on qemu mainline in 1b2503fcf7b5932c5a3779ca2ceb92bd403c4ee7 - thanks.  I have backported the fix to pkgsrc as qemu-2.11.1nb3.


Hi Andreas, beware... while 1b2503fcf7b5 fixes this bug, it introduces another regression.
I suggest waiting for the release tag before cherry-picking it.

Commit 1b2503fcf7b5932c reverted by commit 6f660996f1623034. We'll release 2.12 without a fix for this bug, and look at it for 2.13 and 2.12.1.

https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg02505.html and followups describe the regression that 1b2503fcf7b5932c caused.


... and it has been fixed again for 3.0:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=eeaa6715050ed3f9cbedd32