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
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
|
<!DOCTYPE HTML PUBLIC "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension//EN" [
<!ENTITY base CDATA "../..">
<!ENTITY email 'freebsd-qa'>
<!ENTITY date "$FreeBSD: www/en/releases/6.1R/todo.sgml,v 1.31 2006/05/04 10:03:52 rwatson Exp $">
<!ENTITY local.rel "6.1">
<!ENTITY title "FreeBSD 6.1 Open Issues">
<!ENTITY % navinclude.download "INCLUDE">
<!ENTITY % developers SYSTEM "../../developers.sgml"> %developers;
<!-- Status levels -->
<!ENTITY status.na "<font color=green>N/A</font>">
<!ENTITY status.done "<font color=green>Done</font>">
<!ENTITY status.wip "<font color=blue>In progress</font>">
<!ENTITY status.untested "<font color=orange>Needs testing</font>">
<!ENTITY status.new "<font color=red>Not done</font>">
<!ENTITY status.unknown "<font color=red>Unknown</font>">
<!ENTITY status.deferred "<font color=gray>Deferred for future release</font>">
<!ENTITY url.cvsweb "http://www.freebsd.org/cgi/cvsweb.cgi">
<!ENTITY url.mid "http://docs.freebsd.org/cgi/mid.cgi?">
<!ENTITY url.pr "http://www.freebsd.org/cgi/query-pr.cgi?">
<!ENTITY stresstest SYSTEM "./stress.html">
]>
<!--
Changes to this list MUST NOT be committed without approval of
Release Engineering Team (re@FreeBSD.org) (for general items) or
Documentation Engineering Team (doceng@FreeBSD.org) (for doc-related
items).
-->
<html>
&header;
<p>This is a list of open issues that need to be resolved for FreeBSD
&local.rel;. If you have any updates for this list, please e-mail
re@FreeBSD.org.</p>
<ul>
<li><a href="#showstopper">Show stopper defects</a></li>
<li><a href="#required">Required features</a></li>
<li><a href="#desired">Desired features</a></li>
<li><a href="#docs">Documentation Items</a></li>
<li><a href="#testing">Testing foci</a></li>
<li><a href="#stresstest">Problems Discovered by Kernel Stress Test Suite</a></li>
<li><a href="#sparc64">Problems specific to the sparc64 architecture</a></li>
</ul>
<h3>Show stopper defects for &local.rel;-RELEASE</h3>
<a name="showstopper"></a>
<table class="tblbasic">
<tr class="heading">
<th>Issue</th>
<th>Status</th>
<th>Responsible</th>
<th>Description</th>
</tr>
<tr><td colspan="4">No pending issue.</td></tr>
</table>
<h3>Required features for &local.rel;-RELEASE</h3>
<a name="required"></a>
<table class="tblbasic">
<tr class="heading">
<th>Issue</th>
<th>Status</th>
<th>Responsible</th>
<th>Description</th>
</tr>
<tr><td colspan="4">No pending issue.</td></tr>
</table>
<h3>Desired features for &local.rel;-RELEASE</h3>
<a name="desired"></a>
<table class="tblbasic">
<tr class="heading">
<th>Issue</th>
<th>Status</th>
<th>Responsible</th>
<th>Description</th>
</tr>
<tr>
<td>devfs locking problem</td>
<td>&status.wip;</td>
<td>&a.jeff;</td>
<td>It is trivial to deadlock it on an SMP system, and
there are other panics with device removal.</td>
</tr>
<tr>
<td>pty leak</td>
<td>&status.wip;</td>
<td>&a.cognet;</td>
<td>Since 6.x has a hard-coded limit, once all ptys are
leaked things like ssh and login no longer work.
This seems devfs-related, and occurs only under extreme stress
testing, not normal use.</td>
</tr>
<tr>
<td>swap_pager warnings</td>
<td>&status.unknown;</td>
<td>&a.truckman;?</td>
<td>When swapfiles are in use, there are often warnings printed:
<tt>swap_pager: indefinite wait buffer: bufobj: 0, blkno: 889347, size: 8192</tt>. There is also the possibility of deadlock.</td>
</tr>
<tr>
<td>unmount pending error</td>
<td>&status.wip;</td>
<td>&a.ssouhlal;</td>
<td>When unmounting filesystems &a.kris; reports seeing this warning: <tt>/c: unmount pending error: blocks -68512 files 0</tt>. This dates back at least to 5.3. It might be associated with
filesystem corruption reported by many users in which the 'used' space
on a filesystem is negative; fsck -f is needed to correct this.</td>
</tr>
<tr>
<td>"calcru: runtime went backwards" problem for threaded program</td>
<td>&status.unknown;</td>
<td> </td>
<td>stress2 thr1 test can trigger "calcru: runtime went backwards" problem
and there are also many similar reports on -stable and -current.
&a.phk; committed a possible fix (src/sys/kern/kern_tc.c rev.1.169) to
update the calibration code to be more precise on 2 March.</td>
</tr>
<tr>
<td>NFS data corruption between two 7.0 machines</td>
<td>&status.wip;</td>
<td>&a.mohans;</td>
<td>Running fsx between a 7.0 NFS client and server
detects data corruption. This problem can also be reproduced
by using 6.1 NFS server. The problem seems to be avoidable by
turning off the attribute cache on the NFS client.</td>
</tr>
<tr>
<td>sort(1) does not work with some locales</td>
<td>&status.new;</td>
<td> </td>
<td>sort(1) can cause a coredump with some locales.
See also gnu/93629.</td>
</tr>
<tr>
<td>unreliable serial console</td>
<td>&status.unknown;</td>
<td></td>
<td>At the manual 'root mount' prompt, the serial console is very
unreliable and drops most characters. This appears to be caused
by cngetc() polling the sio driver for input, and the sio driver
resetting the chip on every poll iteration. That results in a very
small window for it to accept input. Fixing this requires a
large review of the operation of the sio driver. The uart driver
looks to handle this better and might be a suitable replacement.</td>
</tr>
<tr>
<td>fix ntpdate(1) bogus output on amd64.</td>
<td>&status.unknown;</td>
<td>&a.roberto;</td>
<td></td>
</tr>
<tr>
<td>make -jN</td>
<td>&status.new;</td>
<td> </td>
<td>Doing 'make -jN', then suspending/resuming it may result in make
reporting it lost child process(es).</td>
</tr>
<tr>
<td>update sysinstall disk labeling</td>
<td>&status.wip;</td>
<td>&a.rodrigc;</td>
<td>Sysinstall could use the same fixes recently made to fdisk so it
plays nice with GEOM and disk labeling. This does not cause problems
during install because nothing on the disk is mounted when its label
is being manipulated but it can cause problems if sysinstall gets
used on a live system to adjust labels on existing disks which
sys-admins tend to do.</td>
</tr>
<tr>
<td>i386 deadlocks with >16GB swap</td>
<td>&status.deferred;</td>
<td>&a.alc;</td>
<td>i386 deadlocks if more than 16GB of swap is in use.
Increasing the kern.maxswzone tunable would be a workaround
this. Although a patch from &a.alc; is needed to allow this variable to
be increased, this is not suitable for 6.1R. This limitation should
be documented in the Release Notes.</td>
</tr>
<tr>
<td>panic in bpf</td>
<td>&status.deferred;</td>
<td>&a.sam;</td>
<td>killing tcpdump (e.g. with ^C) can cause panics in bpf.
To fix this problem, some architectural changes are needed.</td>
</tr>
<tr>
<td>OpenBSM</td>
<td>&status.deferred;</td>
<td>&a.rwatson;</td>
<td>The integration of OpenBSM is waiting on some final licensing hurdles.
It is expected to be available in the next release.</td>
</tr>
</table>
<h3>Documentation items that must be resolved for &local.rel;</h3>
<a name="docs"></a>
<table class="tblbasic">
<tr class="heading">
<th>Issue</th>
<th>Status</th>
<th>Responsible</th>
<th>Description</th>
</tr>
<tr><td colspan="4">No pending issue.</td></tr>
</table>
<h3>Testing foci for &local.rel;-RELEASE</h3>
<a name="testing"></a>
<table class="tblbasic">
<tr class="heading">
<th>Issue</th>
<th>Status</th>
<th>Responsible</th>
<th>Description</th>
</tr>
<tr>
<td>manual root mount lockmgr panics</td>
<td>&status.untested;</td>
<td>&a.ssouhlal;</td>
<td>Specifying a manual root mount location causes lockmgr panics.
&a.ssouhlal; has committed a patch for this.</td>
</tr>
<tr>
<td>dhclient causes ipv6 panics.</td>
<td>&status.untested;</td>
<td>&a.dougb;</td>
<td>&a.dougb; has more details about this.</td>
</tr>
<tr>
<td>amd64 panics in ipv6 with date(1)</td>
<td>&status.untested;</td>
<td>&a.ume;</td>
<td>amd64 panics in ipv6 when the date is changed using date(1) or
ntpdate(1). This may be a MI issue.</td>
</tr>
<tr>
<td>grep(1) -w does not work with multibyte locales</td>
<td>&status.untested;</td>
<td>&a.tjr;</td>
<td>grep(1) -w generates wrong results with non-UTF-8
multibyte locales. &a.tjr; has committed a patch
to -HEAD. See also gnu/91909.</td>
</tr>
<tr>
<td>Improve kbdmux</td>
<td>&status.untested;</td>
<td>&a.emax;</td>
<td><em>From the <a
href="http://www.freebsd.org/projects/ideas/">ideas
page</a>.</em> We need this for the growing number of systems
that assume that USB is the primary keyboard. Current status
appears to be that the kbdmux driver breaks very easily. We need
this working well enough where it can be enabled by default, and
all attached keyboards Just Work. &a.emax; commit kbdmux and
rc.d/syscons patches in HEAD and RELENG_6. It is not yet enabled
by default. See kbdmux(4) and contact &a.emax; if you have
problems.</td>
</tr>
<tr>
<td>umount -f panics</td>
<td>&status.untested;</td>
<td>&a.jeff;, &a.ssouhlal;</td>
<td>panics from race conditions.
A patch from &a.jeff; seems to fix some of them.</td>
</tr>
<tr>
<td>quota deadlocks</td>
<td>&status.untested;</td>
<td>&a.jeff;</td>
<td>Quota support is not locked properly and causes deadlocks.
A patch from &a.jeff; seems to fix some of them.</td>
</tr>
<tr>
<td>ifconfig regression on 6.x</td>
<td>&status.untested;</td>
<td>&a.yar;</td>
<td>ifconfig cannot handle vlan and mtu parameters at the same time
after rev.1.7.2.3 of sbin/ifconfig/ifvlan.c commit.
For more information and a proposed patch, see
<a href="http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/94028">bin/94028</a>.</td>
</tr>
<tr>
<td>SMP kernels for install</td>
<td>&status.untested;</td>
<td>&a.sam;</td>
<td><em>From the <a
href="http://www.freebsd.org/projects/ideas/">ideas
page</a>.</em> Right now we only install a UP kernel, for performance
reasons. We should be able to package both a UP and SMP kernel
into the release bits, and have sysinstall install both. It
should also select the correct one for the target system and
make that the default on boot. The easiest way to do this would
be to have sysinstall boot an SMP kernel and then look at the
hw.ncpu sysctl. The only problem is being able to have
sysinstall fall back to booting a UP kernel for itself if the
SMP one fails. This can probably be 'faked' by setting one of
the SMP-disabling variables in the loader. But in any case, the
point is to make the process Just Work for the user, without the
user needing to know arcane loader/sysctl knobs. SMP laptops are
here, and we should be ready to support SMP out-of-the-box.</td>
</tr>
<tr>
<td>dup(2) regression on 6.x</td>
<td>&status.untested;</td>
<td>&a.csjp;</td>
<td>Simple "close(0); dup(fd)" does not return descriptor "0" in some cases.
This problem has been reported in
<a href="http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/87208">kern/87208</a>,
and there is a proposed patch in the PR, too. &a.csjp; has committed a
fix for this.</td>
</tr>
<tr>
<td>cpu_ipi_selected() can cause a trap on FreeBSD/sparc64</td>
<td>&status.untested;</td>
<td>&a.marius;</td>
<td>On sparc64, cpu_ipi_selected() can cause a trap (which is bad since
it appears in the trap code path).</td>
</tr>
<tr>
<td>UFS deadlocks on amd64</td>
<td>&status.untested;</td>
<td>&a.tegge;</td>
<td>Seen by &a.kris;. This problem seems MI.</td>
</tr>
<tr>
<td>UFS deadlocks</td>
<td>&status.untested;</td>
<td>&a.tegge;</td>
<td>Seen by Peter Jeremy.</td>
</tr>
<tr>
<td>panic in fxp driver</td>
<td>&status.untested;</td>
<td>&a.andre;</td>
<td>See <a href="http://people.freebsd.org/~pho/stress/log/cons186.html">http://people.freebsd.org/~pho/stress/log/cons186.html</a>.</td>
</tr>
<tr>
<td>exec_map depletion</td>
<td>&status.untested;</td>
<td>&a.ups;</td>
<td>The exec_map is regularly running out of space
on machines running 7.0. &a.ups; has a committed a
patch that seems to fix this problem.</td>
</tr>
<tr>
<td>/dev/mem instability</td>
<td>&status.untested;</td>
<td>&a.marius;, &a.ups;</td>
<td>Instability when accessing /dev/mem. A fix was committed
for i386. amd64 does not seem to have the problem. A sparc64
fix is still in progress.</td>
</tr>
<tr>
<td>deadlock in vn_start_write() consumers</td>
<td>&status.untested;</td>
<td>&a.tegge;</td>
<td>Many potential deadlocks have been fixed.</td>
</tr>
</table>
<h3>Stress Test Panics</h3>
<a name="stresstest"></a>
<p>The system is continuously being subjected to Peter Holm's <a
href="http://www.holm.cc/stress/">Kernel Stress Test Suite</a>. The
following issues have recently been discovered from this test
suite.</p>
&stresstest;
<h3>sparc64 problems</h3>
<a name="sparc64"></a>
<p>These are problems that range in severity for FreeBSD/sparc64. They
will not hold up the release, but they will still be tracked for future
releases.</p>
<table class="tblbasic">
<tr class="heading">
<th>Issue</th>
<th>Status</th>
<th>Responsible</th>
<th>Description</th>
</tr>
<tr>
<td>sparc64 frequent hangs</td>
<td>&status.wip;</td>
<td>&a.marius;</td>
<td>Some of the more serious hangs on sparc64 have been fixed, but more
remain.</td>
</tr>
<tr>
<td>serious sparc64 IPv6 panic</td>
<td>&status.wip;</td>
<td>&a.gnn;</td>
<td>Triggered by just ping6'ing the box. It may even be a MI
issue, the reporter of this bug only uses IPv6 with
sparc64. This problem seems to be triggered even when debug.mpsafenet=0.</td>
</tr>
<tr>
<td>swap panic on sparc64</td>
<td>&status.unknown;</td>
<td>&a.kris; has panic info</td>
<td>&a.kris; reports configuring a 74GB swap-backed md on sparc64 that
caused a panic after a week or two of load (during which time
swap was slowly filling as more of the md was dirtied).</td>
</tr>
<tr>
<td>KLDs on sparc64</td>
<td>&status.new;</td>
<td> </td>
<td>On sparc64 machines with more than 4Gb memory KLDs are not usable
and will panic the system. The problem is reportedly with how the
KLDs are compiled, it only works if the code ends up below 4G.</td>
</tr>
<tr>
<td>Max RAM on sparc64</td>
<td>&status.new;</td>
<td> </td>
<td>Maximum RAM on sparc64 appears to be limited to 16Gb.</td>
</tr>
</table>
&footer;
</body>
</html>
|
