Update the list. Many problems were fixed and moved down to the testing
list. The others have been demoted to the 'Desired' list due to either having a workaround, not having much interest or reproducability, or not being severe to begin with.
This commit is contained in:
Scott Long
parent
fb7347e37f
commit
baf99458ae
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/www/; revision=27528
1 changed files with 132 additions and 119 deletions
|
|
@ -1,7 +1,7 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" [
|
||||
<!ENTITY base CDATA "../..">
|
||||
<!ENTITY email 'freebsd-qa'>
|
||||
<!ENTITY date "$FreeBSD: www/en/releases/6.1R/todo.sgml,v 1.23 2006/04/01 15:06:38 mux Exp $">
|
||||
<!ENTITY date "$FreeBSD: www/en/releases/6.1R/todo.sgml,v 1.24 2006/04/02 18:58:04 hrs Exp $">
|
||||
<!ENTITY local.rel "6.1">
|
||||
<!ENTITY title "FreeBSD 6.1 Open Issues">
|
||||
<!ENTITY % navincludes SYSTEM "../../includes.navdownload.sgml"> %navincludes;
|
||||
|
|
@ -59,124 +59,6 @@
|
|||
<th>Description</th>
|
||||
</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.</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>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>/dev/mem instability</td>
|
||||
<td>&status.unknown;</td>
|
||||
<td>&a.marius;</td>
|
||||
<td>Instability when accessing /dev/mem. Contact
|
||||
&a.marius; or &a.kris; for debugging information.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>sparc64 frequent hangs</td>
|
||||
<td>&status.unknown;</td>
|
||||
<td></td>
|
||||
<td>no DDB break possible, so impossible to diagnose</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>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>exec_map depletion</td>
|
||||
<td>&status.wip;</td>
|
||||
<td>&a.ups;</td>
|
||||
<td>The exec_map is regularly running out of space
|
||||
on machines running 7.0. &a.ups; has a proposed
|
||||
patch and it seems to fix this problem.</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.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>deadlock in vn_start_write() consumers</td>
|
||||
<td>&status.wip;</td>
|
||||
<td>&a.tegge;</td>
|
||||
<td></td>
|
||||
</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.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>rpc.lockd interoperability problems</td>
|
||||
<td>&status.unknown;</td>
|
||||
<td>&a.kuriyama;</td>
|
||||
<td>After <a href="http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/80389">this commit</a>
|
||||
rpc.lockd seems to have interoperability problems.
|
||||
This may be the cause of the many "rpc.lockd no longer interoperates"
|
||||
bug reports seen on -stable.</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>
|
||||
</table>
|
||||
|
||||
<h3>Required features for &local.rel;-RELEASE</h3>
|
||||
|
|
@ -203,6 +85,111 @@ on a filesystem is negative; fsck -f is needed to correct this.</td>
|
|||
<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.</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>rpc.lockd interoperability problems</td>
|
||||
<td>&status.unknown;</td>
|
||||
<td>&a.kuriyama;</td>
|
||||
<td>After <a href="http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/80389">this commit</a>
|
||||
rpc.lockd seems to have interoperability problems.
|
||||
This may be the cause of the many "rpc.lockd no longer interoperates"
|
||||
bug reports seen on -stable. Unfortunately, rpc.lockd contains a
|
||||
number of severe architectural issues that make it unsuitable for a
|
||||
production environment. Fixing these is beyond the scope of the
|
||||
6.1 release.</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>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>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>swap panic on sparc64</td>
|
||||
<td>&status.unknown;</td>
|
||||
|
|
@ -477,6 +464,32 @@ on a filesystem is negative; fsck -f is needed to correct this.</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 sarc64
|
||||
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>
|
||||
|
|
|
|||
Loading…
Reference in a new issue