diff --git a/en/releases/5.1R/todo.sgml b/en/releases/5.1R/todo.sgml index c05c2a7590..0f458d0025 100644 --- a/en/releases/5.1R/todo.sgml +++ b/en/releases/5.1R/todo.sgml @@ -1,254 +1,255 @@ - + %includes; %developers; ]> &header;

Open Issues

This is a list of open issues that need to be resolved for FreeBSD 5.1. If you have any updates for this list, please e-mail re@FreeBSD.org.

Must Resolve Issues for 5.1-RELEASE

- - - - - - -
IssueStatusResponsibleDescription
iir driver fails to probe disksIn progress&a.scottl;During the install, the iir controller appears to correctly - probe, but finds no disk devices. The card in question is an - Intel srcu32 RAID controller with 32Mb RAM, Firmware revision - 2.33.01. Intel developers have released an update driver, which - must be adapted and imported prior to 5.1-RELEASE.
Fresh ACPI-CA import In Progress &a.njl; The last ACPI-CA import happened in Oct 2002. Vendor releases since then address various bugs that have also plagued FreeBSD 5.0 users.
nullfs deadlocks -- -- &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.
wait4 "impossible" mutex panic In progress &a.tjr; &a.kris; reports mutex panics in wait4 in the bento environment: "Impossible" mutex panic in wait4() (reported to -current a while ago). This has not recurred, but no-one could track it down. It's suspiciously similar to the other mutex panics I've been seeing more recently (see uidinfo "impossible" mutex panic).
SMP double fault -- -- &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.
Spurious alpha panics -- -- &a.kris; reports that he has seen several unique panics on the alpha machines, but since gdb -k doesn't work on alpha I haven't been able to get more than a DDB traceback. No-one has looked into them.
uidinfo "impossible" panic In progress &a.tjr; &a.kris; reports that there appears to be a resource leak of uidinfo reference counts that is causing the gohan machines to panic after about 18 days of load. &a.tjr; has given me a patch to assert against reference count overflow, which will hopefully trigger in about 18 days from now.
TIMEWAIT panic for network labeled MAC policy modules In progress &a.rwatson; Due to TCP state efficiency improvements in the TIMEWAIT state, it's now possible for the PCB socket pointer to be NULL in situations it previously wasn't. As a result, TCP responses generated in the TIMEWAIT state may lack properly initialized MAC labels, resulting in panics for network labeled MAC policies. A fix is current in testing.

Desired Features for 5.1-RELEASE

IssueStatusResponsibleDescription
NSSwitch support In progress &a.nectar; Support for pluggable directory services using NSS, including adaptations of current directory services (local databases, NIS), and support for new services (LDAP, Active Directory, etc). This change has now been tested, and requires broader testing.
a.out toolchain port -- -- A.out support in the base system was reduced; the removed build chain components should be made into a port.
Race conditions in truss Errata candidate &a.robert; Truss appears to contain a race condition during the start-up of debugging, which can result in truss failing to attach to the process before it exits. The symptom is that truss reports that it cannot open the procfs node supporting the process being debugged. A bug also appears to exist where in truss will hang if execve() returns ENOENT. A further race appears to exist in which truss will return "PIOCWAIT: Input/output error" occasionally on startup. The fix for this sufficiently changes process execution handling that we will defer the fix to post-5.0 and consider this errata.

Documentation items that must be resolved for 5.1

IssueStatusResponsibleDescription
Documentation for HTT In Progress &a.jhb;, &a.bmah; Documentation that describes HyperThreading and the sysctls to configure it needs to be written for the release notes and smp(4) manpage.
No docs for FAST IPSEC -- -- The new "fast ipsec" implementation has insufficient documentation (man pages, release notes), and this would be highly desirable to have before 5.0-RELEASE.
Documentation rottage: S/Key -- -- We now use OPIE instead of S/Key. The handbook doesn't know that yet.
Documentation wanted: gdbe -- -- 5.0 includes GDBE, supporting encryption of swap and storage. It would be nice if that was documented in the handbook.

Areas requiring immediate testing

+ + + + + + +
IssueStatusResponsibleDescription
iir driver fails to probe disks----During the install, the iir controller appears to correctly + probe, but finds no disk devices. The card in question is an + Intel srcu32 RAID controller with 32Mb RAM, Firmware revision + 2.33.01. Intel developers have released an update driver, which + has recently been adapted and imported into 5-CURRENT, and must + be tested.
PAE support for i386 -- -- PAE support allows the use of up to 64GB of RAM on Pentium Pro and above systems. Virtual addresses are still constrained to 32-bits.
lazy context switching for i386 -- -- Lazy Context Switching allows for faster context switches and should mitigate the some of the latency introduced with interrupt threads and GEOM kernel threads. Enabled with the LAZY_SWITCH option.
if_wi problems on Lucent hardware -- -- The recently upgraded if_wi driver is more tuned to Prism hardware than to Lucent hardware, resulting in system lockups and poor performance when using Lucent hardware. These problems are believed to be fixed but more testing is welcome.
No console (term) if smbus is enable in the kernel -- -- There are reports that kernels build with smbus, viapm, and smb devices may not properly probe and support the system console following boot.
UFS2 as installation, newfs default In progress &a.rwatson; For 5.1-RELEASE, the default file system type for newly created file systems is UFS2 rather than UFS1. newfs(8) and sysinstall(8) have been updated to use this new default. Testing to make sure all goes well after the change (committed on April 20, 2003) is vital.
&footer;