Update panic on file system fill bug: I've committed a possible fix, and

we're now waiting for the tinderboxes to break, systems to die left and
right, etc, so that it can be refined, then MFC'd.
This commit is contained in:
Robert Watson 2005-09-19 16:55:55 +00:00
parent 56b6c7625b
commit 3c6b045f0f
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/www/; revision=25706

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.0R/todo.sgml,v 1.35 2005/09/18 16:32:48 scottl Exp $">
<!ENTITY date "$FreeBSD: www/en/releases/6.0R/todo.sgml,v 1.36 2005/09/18 17:56:43 rwatson Exp $">
<!ENTITY title "FreeBSD 6.0 Open Issues">
<!ENTITY % includes SYSTEM "../../includes.sgml"> %includes;
<!ENTITY % developers SYSTEM "../../developers.sgml"> %developers;
@ -90,13 +90,16 @@
<tr>
<td>Panic when filesystem fills</td>
<td>&status.wip;</td>
<td>&a.ps;</td>
<td>&a.rwatson;</td>
<td>Inadequate locking causes panics when calling kernel printf functions.
This is most often seen when a filesystem fills up and uprintf() is
called to report it to the console, but it can happen in many other
places also. Properly locking the upper and lower parts of the tty
subsystem likely cannot happen for 6.0, but temporary fixes must be
developed and committed.</td>
developed and committed. A patch has now been committed that is
believed to fix this problem by acquiring Giant around uprintf() and
tprintf(), as well as a regression test. After additional testing and
refinement, it will be merged to RELENG_6.</td>
</tr>
</table>