Relegate ffs_blkfree panic to "testing" since we believe this problem

is now resolved.
This commit is contained in:
Robert Watson 2003-05-05 17:24:58 +00:00
parent b26513aeea
commit 56ebbda3d6
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/www/; revision=16807

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/5.1R/todo.sgml,v 1.31 2003/05/05 16:15:47 rwatson Exp $">
<!ENTITY date "$FreeBSD: www/en/releases/5.1R/todo.sgml,v 1.32 2003/05/05 16:23:37 rwatson Exp $">
<!ENTITY title "FreeBSD 5.1 Open Issues">
<!ENTITY % includes SYSTEM "../../includes.sgml"> %includes;
<!ENTITY % developers SYSTEM "../../developers.sgml"> %developers;
@ -107,24 +107,6 @@
dynamic policies are not loaded.</td>
</tr>
<tr>
<td>panic: ffs_blkfree</td>
<td>In progress</td>
<td>--</td>
<td>Starting in late April, reports of a new UFS panic,
"panic: ffs_blkfree: freeing free frag" began to pop up with
a high frequency in some environments. It appears not to
have been the direct result of a commit to UFS itself,
pointing the finger at other recent changes (VM locking and
fixes, proc locking, ...). While some changes to VM have
been made that were intended to fix this problem (and appear
to have for several cases), there's at least one remaining
report of a problem that may or may not result from
persisting un-fsck'd file systems. This is a show stopper
bug that will prevent a transition to 5.1-BETA unless
resolved.</td>
</tr>
<tr>
<td>Panic on load/unload a kernel module for a driver already
statically linked into the kernel.</td>
@ -328,6 +310,22 @@
This change has been committed, and requires broader testing.</td>
</tr>
<tr>
<td>panic: ffs_blkfree</td>
<td>Patch committed</td>
<td>&a.alc;</td>
<td>Starting in late April, reports of a new UFS panic,
"panic: ffs_blkfree: freeing free frag" began to pop up with
a high frequency in some environments. This problem appears
to have been associated with a bug introduced in the VM system
that has now been resolved. Users who updated to a kernel
between approximately May 1 and May 4 will want to run a full
foreground fsck on all file systems to make sure that no
remaining free space accounting errors exist. However, we
should be on the lookout for any recurrence of this problem
due to its serious nature.</td>
</tr>
</table>
&footer;