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

Add a bunch of items from Kris. For now listing them as desired

Browse source 
but we might shift the categories around for some of these later.
This commit is contained in:
Ken Smith 2005-07-07 17:29:12 +00:00
parent b9ffc129fb
commit 0ca4f7e04d
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/www/; revision=25038
1 changed files with 65 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

72
en/releases/6.0R/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.0R/todo.sgml,v 1.6 2005/06/23 01:00:25 keramida Exp $">
<!ENTITY date "$FreeBSD: www/en/releases/6.0R/todo.sgml,v 1.7 2005/07/07 05:45:00 murray Exp $">
<!ENTITY title "FreeBSD 6.0 Open Issues">
<!ENTITY % includes SYSTEM "../../includes.sgml"> %includes;
<!ENTITY % developers SYSTEM "../../developers.sgml"> %developers;
@ -53,7 +53,6 @@
<tr class="heading">
<th>Issue</th><th>Status</th><th>Responsible</th><th>Description</th>
</tr>
</table>
<h3>Desired features for 6.0-RELEASE</h3>
@ -62,7 +61,71 @@
<tr class="heading">
<th>Issue</th><th>Status</th><th>Responsible</th><th>Description</th>
</tr>
<tr>
<td>devfs umount panic</td><td>&status.new;</td><td></td>
<td>There is a race condition between device removal and devfs
umounts that causes "Memory modified after free" panics. Can
be reproduced by doing 'mdconfig -u' concurrently with unmounting
a devfs instance.</td>
</tr>
<tr>
<td>nullfs hash size</td><td>&status.new;</td><td></td>
<td>Nullfs (and perhaps other filesystems) use an absurdly small
hash size that causes significant performance penalties.</td>
</tr>
<tr>
<td>/dev/kmem panic</td><td>&status.new;</td><td></td>
<td>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>
</tr>
<tr>
<td>KLDs on sparc64</td><td>&status.new;</td><td></td>
<td>On sparc64 machines with more than 4Gb memory KLDs are not usable
and will panic the system. The problem is reportedly with how the
KLDs are compiled, it only works if the code ends up below 4G.</td>
</tr>
<tr>
<td>Max RAM on sparc64</td><td>&status.new;</td><td></td>
<td>Maximum RAM on sparc64 appears to be limited to 16Gb.</td>
</tr>
<tr>
<td>make -jN</td><td>&status.new;</td><td></td>
<td>Doing 'make -jN', then suspending/resuming it may result in make
reporting it lost child process(es).</td>
</tr>
<tr>
<td>kgdb on sparc64</td><td>&status.new;</td><td></td>
<td>It looks like kgdb is still broken on sparc64. It is better
than it used to be but still can't obtain a traceback.</td>
</tr>
<tr>
<td>ULE</td><td>&status.new;</td><td></td>
<td>ULE is reported to still be broken on SMP machines.</td>
</tr>
<tr>
<td>M_SAVEDINO</td><td>&status.new;</td><td></td>
<td>A 'memory modified after free' bug affecting M_SAVEDINO. Possibly
a softupdates bug.</td>
</tr>
</table>
<h3>Documentation items that must be resolved for 6.0</h3>
@ -86,8 +149,6 @@
should be updated to describe how to connect to networks with
WPA keys, setup host access points, etc.</td>
</tr>
</table>
@ -120,9 +181,6 @@
has not seen a wider audience yet, further testing would be
appreciated. See if_bridge(4) for configuration details.</td>
</tr>
<!-- Woo hoo, none yet! -->
</table>
&footer;