Ctrl-A b not working in 2.8.0

[Paul Goyette]

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.

[Andreas Gustafsson (gson)]

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.

[elmarco (marcandre-lureau)]

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

[elmarco (marcandre-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

[elmarco (marcandre-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

[Paul Goyette (paul-whooppee)]

I can confirm that this bug is fixed in qemu 2.8.1

Thanks!

[Thomas Huth (th-huth)]

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

[Andreas Gustafsson (gson)]

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.

[Paul Goyette (paul-whooppee)]

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

[Andreas Gustafsson (gson)]

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.

[Daniel Berrange (berrange)]

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

[Andreas Gustafsson (gson)]

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

[Philippe Mathieu-Daudé (philmd)]

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

[Peter Maydell (pmaydell)]

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.

[Thomas Huth (th-huth)]

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