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.
| Issue | Status | Responsible | Description |
|---|
| iir driver fails to probe disks |
In 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. |
-
- | if_wi problems on Lucent hardware |
- In Progress |
- &a.imp;, &a.sam; |
- 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. |
-
-
-
- | lazy context switching for i386 |
- In Progress |
- &a.peter; |
- Lazy Context Switching allows for faster context switches and should
- mitigate the some of the latency introduced with interrupt threads and
- GEOM kernel threads. |
-
-
| Fresh ACPI-CA import |
- -- |
- -- |
+ &.njl;/td>
+ | In Progress |
The last ACPI-CA import happened in Oct 2002. Vendor releases since then
address various bugs that have also plagued FreeBSD 5.0 users. |
-
- | PAE support for i386 |
- In Progress |
- &a.jake; |
- PAE support allows the use of up to 64GB of RAM on Pentium Pro and above
- systems. Virtual addresses are still contrained to 32-bits. |
-
-
| 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. |
| Issue | Status | Responsible | Description |
|---|
| 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. |
| UFS2 as installation, newfs default |
In progress |
&a.rwatson; |
Change the installation and newfs(8) default format to UFS2.
In 5.0-RELEASE, UFS2 was optional to improve backward compatibility
and ease experimentation. In 5.1-RELEASE, UFS2 will be the
default due to higher performance, larger maximum capacity, and
access to features such as extended attributes. All tools will
continue to support UFS1. |
| 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. |
| Issue | Status | Responsible | Description |
|---|
+
+ | Documentation for HTT |
+ &a,jhb; |
+ In Progress |
+ 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. |
-
| Issue | Status | Responsible | Description |
|---|
+
+ | 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 contrained 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 beleived 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. |
&footer;