More issues submitted by Kris that we should work on fixing before

6.1R.
This commit is contained in:
Murray Stokely 2006-01-28 02:52:42 +00:00
parent dc66eebf94
commit 3b617b7c62
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/www/; revision=26988

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.5 2006/01/27 05:08:24 murray Exp $">
<!ENTITY date "$FreeBSD: www/en/releases/6.1R/todo.sgml,v 1.6 2006/01/27 05:53:28 murray Exp $">
<!ENTITY local.rel "6.1">
<!ENTITY title "FreeBSD 6.1 Open Issues">
<!ENTITY % navincludes SYSTEM "../../includes.navdownload.sgml"> %navincludes;
@ -59,6 +59,49 @@
<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>manual root mount lockmgr panics</td>
<td>&status.wip;</td>
<td>ssouhlal</td>
<td>Specifying a manual root mount location causes lockmgr panics.
ssouhlal has a patch for this.</td>
</tr>
<tr>
<td>i386 deadlocks with >16GB swap</td>
<td>&status.wip;</td>
<td>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
be increased.</td>
</tr>
<tr>
<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
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>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>umount -f panics</td>
<td>&status.wip;</td>
@ -187,6 +230,16 @@
all attached keyboards Just Work.</td>
</tr>
<tr>
<td>swap panic on sparc64</td>
<td>&status.unknown;</td>
<td>kris has panic info</td>
<td>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>updated hal and ath drivers</td>
<td>&status.new;</td>