os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Use entities (for consistency).

Browse source
This commit is contained in:
Joel Dahl 2006-01-31 22:26:51 +00:00
parent 59a67b66ec
commit 4b0549ecf3
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/www/; revision=27002
1 changed files with 21 additions and 21 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

42
en/releases/6.1R/todo.sgml
View file

@ -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.6 2006/01/27 05:53:28 murray Exp $">
<!ENTITY date "$FreeBSD: www/en/releases/6.1R/todo.sgml,v 1.7 2006/01/28 02:52:42 murray Exp $">
<!ENTITY local.rel "6.1">
<!ENTITY title "FreeBSD 6.1 Open Issues">
<!ENTITY % navincludes SYSTEM "../../includes.navdownload.sgml"> %navincludes;
@ -70,18 +70,18 @@
<tr>
<td>manual root mount lockmgr panics</td>
<td>&status.wip;</td>
<td>ssouhlal</td>
<td>&a.ssouhlal;</td>
<td>Specifying a manual root mount location causes lockmgr panics.
ssouhlal has a patch for this.</td>
&a.ssouhlal; has a patch for this.</td>
</tr>
<tr>
<td>i386 deadlocks with >16GB swap</td>
<td>&status.wip;</td>
<td>alc</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, but a patch from alc@ is needed to allow this variable to
this, but a patch from &a.alc; is needed to allow this variable to
be increased.</td>
</tr>
@ -89,7 +89,7 @@
<td>unmount pending error</td>
<td>&status.unknown;</td>
<td></td>
<td>When unmounting filesystems 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
<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>
@ -97,7 +97,7 @@ on a filesystem is negative; fsck -f is needed to correct this.</td>
<tr>
<td>swap_pager warnings</td>
<td>&status.unknown;</td>
<td>truckman?</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>
@ -105,7 +105,7 @@ on a filesystem is negative; fsck -f is needed to correct this.</td>
<tr>
<td>umount -f panics</td>
<td>&status.wip;</td>
<td>jeffr, ssouhlal</td>
<td>&a.jeff;, &a.ssouhlal;</td>
<td>panics from race conditions.</td>
</tr>
@ -119,8 +119,8 @@ on a filesystem is negative; fsck -f is needed to correct this.</td>
<tr>
<td>UFS deadlocks on amd64</td>
<td>&status.unknown;</td>
<td>tegge</td>
<td>Seen by Kris Kennaway.</td>
<td>&a.tegge;</td>
<td>Seen by &a.kris;.</td>
</tr>
<tr>
@ -141,16 +141,16 @@ on a filesystem is negative; fsck -f is needed to correct this.</td>
<tr>
<td>sparc64 instability.</td>
<td>&status.unknown;</td>
<td>marius</td>
<td>&a.marius;</td>
<td>sparc64 installability when accessing /dev/mem. Contact
marius or kris for debugging information.</td>
&a.marius; or &a.kris; for debugging information.</td>
</tr>
<tr>
<td>dhclient causes ipv6 panics.</td>
<td>&status.unknown;</td>
<td></td>
<td>dougb has more details about this.</td>
<td>&a.dougb; has more details about this.</td>
</tr>
<tr>
@ -163,7 +163,7 @@ on a filesystem is negative; fsck -f is needed to correct this.</td>
<tr>
<td>serious sparc64 IPv6 panic</td>
<td>&status.unknown;</td>
<td>gnn</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.</td>
@ -220,7 +220,7 @@ on a filesystem is negative; fsck -f is needed to correct this.</td>
<tr>
<td>Improve kbdmux</td>
<td>&status.unknown;</td>
<td>emax</td>
<td>&a.emax;</td>
<td><em>From the <a
href="http://www.freebsd.org/projects/ideas/#p-kbdmux">ideas
page</a>.</em> We need this for the growing number of systems
@ -233,9 +233,9 @@ on a filesystem is negative; fsck -f is needed to correct this.</td>
<tr>
<td>swap panic on sparc64</td>
<td>&status.unknown;</td>
<td>kris has panic info</td>
<td>&a.kris; has panic info</td>
<td>Kris reports configuring a 74GB swap-backed md on sparc64 that
<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>
@ -243,14 +243,14 @@ on a filesystem is negative; fsck -f is needed to correct this.</td>
<tr>
<td>updated hal and ath drivers</td>
<td>&status.new;</td>
<td>sam</td>
<td>&a.sam;</td>
<td></td>
</tr>
<tr>
<td>fix ntpdate(1) bogus output on amd64.</td>
<td>&status.unknown;</td>
<td>roberto</td>
<td>&a.roberto;</td>
<td></td>
</tr>
@ -260,14 +260,14 @@ on a filesystem is negative; fsck -f is needed to correct this.</td>
<td></td>
<td>What seem to be 4BSD scheduler bugs in 6.0 that
cause performance to be anomalously low in certain situations.
davidxu has expressed some interest in this problem.</td>
&a.davidxu; has expressed some interest in this problem.</td>
</tr>
<tr>
<td>/dev/kmem panic</td>
<td>&status.new;</td>
<td>&nbsp;</td>
<td>Kris has noticed panics on SMP machines when there was ABI
<td>&a.kris; has noticed panics on SMP machines when there was ABI
breakage of libkvm and world was not rebuilt and utilities like
fstat were used. This suggests panics can be caused by incorrect
accesses to /dev/kmem.</td>