summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/118/all/1654137
blob: d7b470b33d2dea3346a094594b2796de2958df1a (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
permissions: 0.988
assembly: 0.979
debug: 0.979
register: 0.976
PID: 0.972
device: 0.970
semantic: 0.967
network: 0.967
arm: 0.965
graphic: 0.965
files: 0.960
socket: 0.960
hypervisor: 0.957
performance: 0.955
architecture: 0.952
virtual: 0.948
KVM: 0.941
user-level: 0.941
peripherals: 0.938
VMM: 0.937
risc-v: 0.935
vnc: 0.935
TCG: 0.929
ppc: 0.927
kernel: 0.914
x86: 0.908
boot: 0.906
mistranslation: 0.902
i386: 0.803

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