Remove the SMP double fault item as it was most likely due to bad hardware.

Move the nullfs item to the 'Nice To Have' section since it doesn't
affect package building.
This commit is contained in:
Scott Long 2003-05-03 08:21:18 +00:00
parent 50e89cd006
commit 2dca917c7e
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/www/; revision=16759

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.26 2003/05/01 14:30:16 rwatson Exp $">
<!ENTITY date "$FreeBSD: www/en/releases/5.1R/todo.sgml,v 1.27 2003/05/03 07:42:13 scottl Exp $">
<!ENTITY title "FreeBSD 5.1 Open Issues">
<!ENTITY % includes SYSTEM "../../includes.sgml"> %includes;
<!ENTITY % developers SYSTEM "../../developers.sgml"> %developers;
@ -22,30 +22,6 @@
<tr><th>Issue</th><th>Status</th><th>Responsible</th><th>Description</th>
</tr>
<tr>
<td>nullfs deadlocks</td>
<td>--</td>
<td>--</td>
<td>&a.kris; reports deadlocks involving the use of nullfs in the bento
environment: buildworld -j4 with src and obj mounted via nullfs; the gcc
processes eventually deadlocked in the ufs state. DDB traceback
showed two different codepaths. I've just repeated this, so the bug
still exists.</td>
</tr>
<tr>
<td>SMP double fault</td>
<td>--</td>
<td>--</td>
<td>&a.kris; reports that Bento (SMP machine) is regularly crashing
with a double fault, or just locking up solidly (cannot break to DDB
on the console). This may be hardware-related, though, because
bento also panicked recently with an NMI. I'm currently running it
UP to see if the problems persist. &a.jake; also suggested increasing
the size of the kernel stack in case that is the cause of the double
faults.</td>
</tr>
<tr>
<td>Spurious alpha panics</td>
<td>--</td>
@ -181,6 +157,17 @@
libpthread.</td>
</tr>
<tr>
<td>nullfs deadlocks</td>
<td>--</td>
<td>--</td>
<td>&a.kris; reports deadlocks involving the use of nullfs in the bento
environment: buildworld -j4 with src and obj mounted via nullfs; the gcc
processes eventually deadlocked in the ufs state. DDB traceback
showed two different codepaths. I've just repeated this, so the bug
still exists.</td>
</tr>
</table>
<h3>Documentation items that must be resolved for 5.1</h3>