1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
|
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//FreeBSD//DTD XHTML 1.0 Transitional-Based Extension//EN"
"http://www.FreeBSD.org/XML/doc/share/sgml/xhtml10-freebsd.dtd" [
<!ENTITY email 'freebsd-qa'>
<!ENTITY title "FreeBSD 5.4 Open Issues">
<!-- Status levels -->
<!ENTITY status.na "<font xmlns='http://www.w3.org/1999/xhtml' color='green'>N/A</font>">
<!ENTITY status.done "<font xmlns='http://www.w3.org/1999/xhtml' color='green'>Done</font>">
<!ENTITY status.wip "<font xmlns='http://www.w3.org/1999/xhtml' color='blue'>In progress</font>">
<!ENTITY status.untested "<font xmlns='http://www.w3.org/1999/xhtml' color='orange'>Needs testing</font>">
<!ENTITY status.new "<font xmlns='http://www.w3.org/1999/xhtml' color='red'>Not done</font>">
<!ENTITY status.unknown "<font xmlns='http://www.w3.org/1999/xhtml' color='red'>Unknown</font>">
<!ENTITY url.cvsweb "http://www.freebsd.org/cgi/cvsweb.cgi">
<!ENTITY url.mid "http://docs.freebsd.org/cgi/mid.cgi?">
<!ENTITY url.pr "http://www.freebsd.org/cgi/query-pr.cgi?">
]>
<!--
Changes to this list MUST NOT be committed without approval of
Release Engineering Team (re@FreeBSD.org) (for general items) or
Documentation Engineering Team (doceng@FreeBSD.org) (for doc-related
items).
-->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>&title;</title>
<cvs:keyword xmlns:cvs="http://www.FreeBSD.org/XML/CVS">$FreeBSD$</cvs:keyword>
</head>
<body class="navinclude.download">
<h1>Open Issues</h1>
<p>This is the beginning of a list of open issues that need to be worked on
or resolved for FreeBSD 5.4. If you have any updates for this list, please
e-mail re@FreeBSD.org. The feature list for 5.4 is still a work in
progress, so items may be added, removed, or modified before we're done.
</p>
<h3>Show stopper defects for 5.4-RELEASE</h3>
<table class="tblbasic">
<tr>
<th>Issue</th>
<th>Status</th>
<th>Responsible</th>
<th>Description</th>
</tr>
</table>
<h3>Required features for 5.4-RELEASE</h3>
<table class="tblbasic">
<tr>
<th>Issue</th>
<th>Status</th>
<th>Responsible</th>
<th>Description</th>
</tr>
</table>
<h3>Desired features for 5.4-RELEASE</h3>
<table class="tblbasic">
<tr>
<th>Issue</th>
<th>Status</th>
<th>Responsible</th>
<th>Description</th>
</tr>
<tr>
<td>KAME IPSEC without the Giant Lock</td>
<td>&status.wip;</td>
<td>&a.gnn;</td>
<td>Currently, the KAME IPSEC implementation contains inadequate locking
to operate without the Giant lock over the network stack, forcing
kernels compiled with the KAME IPSEC implementation (not FAST_IPSEC)
to run the network stack with the Giant lock, reducing parallelism,
increasing lock contention, and increasing latency by preventing
preemption. For 5.4-RELEASE, it is desirable to complete the locking
work for KAME IPSEC so that it can run without the Giant lock.</td>
</tr>
<tr>
<td>All Network Interface Drivers MPSAFE</td>
<td>&status.wip;</td>
<td>--</td>
<td>Currently, some network interface drivers are not safe without the
Giant lock due to missing synchronization. These drivers are protected
by running non-INTR_MPSAFE and with the IFF_NEEDSGIANT flag set, which
cause interrupt threads to acquire the Giant lock before executing the
driver's interrupt handler, and to perform if_start (interface
transmit start) asynchronously once the Giant lock can be acquired.
This results in these drivers performing less well due to increased
lock contention, decreased ability to preempt, and latency associated
with asynchronous launching of latency-critical events. For 5.4, all
network drivers should be able to operate without the Giant lock.</td>
</tr>
<tr>
<td>NetIPX without the Giant Lock</td>
<td>&status.wip;</td>
<td>&a.rwatson;</td>
<td>Currently, the IPX/SPX (netipx) implementation contains inadequate
locking to operate without the Giant lock over the network stack,
forcing kernels compiled with IPX support to run the network stack
with the Giant lock, reducing parallelism, increasing lock contention,
and increasing latency by preventing preemption. For 5.4-RELEASE, it
is desirable to complete the locking work for IPX so that it can run
without the Giant lock.</td>
</tr>
<tr>
<td>Fix regression in file(1)</td>
<td>--</td>
<td>--</td>
<td>The new version of file(1) does not cross-build properly. If
sparc64 executables are built on i386 the compiled magic numbers
file that gets installed is wrong and file(1) doesn't work
properly.</td>
</tr>
<tr>
<td>SIGABRT under load</td>
<td>&status.wip;</td>
<td>&a.alc;</td>
<td>Under very high load (Kris sees this on the package builders) a
limitation of 16 sumultaneous exec's may be hit in exec_map().
A workaround has been implemented with a fix planned for 5.5.</td>
</tr>
<tr>
<td>DDB_UNATTENDED may not work</td>
<td>&status.new;</td>
<td>--</td>
<td>There are reports of problems getting dumps after panics.</td>
</tr>
<tr>
<td>fix for ttywakeup panic</td>
<td>&status.wip;</td>
<td>&a.dwhite;</td>
<td>There appears to be a race condition opening/closing ttys.</td>
</tr>
</table>
<h3>Documentation items that must be resolved for 5.4</h3>
<table class="tblbasic">
<tr>
<th>Issue</th>
<th>Status</th>
<th>Responsible</th>
<th>Description</th>
</tr>
</table>
<h3>Testing focuses for 5.4-RELEASE</h3>
<table class="tblbasic">
<tr>
<th>Issue</th>
<th>Status</th>
<th>Responsible</th>
<th>Description</th>
</tr>
<tr>
<td>File descriptor locking</td>
<td>&status.done;</td>
<td>&a.jeff;</td>
<td>File descriptor locking needs to be merged back from HEAD.</td>
</tr>
<tr>
<td>IPFilter mpsafe fixes</td>
<td>&status.done;</td>
<td>&a.rwatson;</td>
<td>IPFilter is currently not mpsafe but doesn't run with Giant.</td>
</tr>
<tr>
<td>Update sysinstall to handle separate packages CD</td>
<td>&status.done;</td>
<td>&a.jhb;</td>
<td>Avoid the need for a disc1-gnome/disc1-kde as was done for 4.11</td>
</tr>
<tr>
<td>busdma fixes</td>
<td>&status.done;</td>
<td>&a.scottl;</td>
<td>More work is needed on busdma to fix bounce buffer problems.</td>
</tr>
<tr>
<td>AMR driver MPSAFE</td>
<td>&status.done;</td>
<td>&a.scottl;</td>
<td>Making the AMR driver MPSAFE will greatly increase its performance.</td>
</tr>
<tr>
<td>CARP support</td>
<td>&status.done;</td>
<td>&a.glebius;</td>
<td>Common Address Redundancy Protocol allows multiple hosts on the same
local network to share a set of IP addresses.</td>
</tr>
<tr>
<td>kstack overflows in softupdates</td>
<td>&status.done;</td>
<td>--</td>
<td>There had been reports of kernel stack overflows in softupdates code
that caused filesystem problems on reboot. This was fixed during the
early stage of code freeze but should be tested.</td>
</tr>
<tr>
<td>ATAPI CDROMs in PIO mode during install</td>
<td>&status.done;</td>
<td>&a.kensmith;</td>
<td>People are having difficulties with various ATAPI CDROMs on
various architectures. We need to either do all installs
in PIO mode or provide a boot menu method of selecting it.</td>
</tr>
<tr>
<td>truss not working</td>
<td>&status.done;</td>
<td>&a.jeff;</td>
<td>See PR kern/78664.</td>
</tr>
<tr>
<td>Deadlock under heavy interrupt load on MP Opteron systems</td>
<td>&status.done;</td>
<td>&a.dwhite;</td>
<td>A deadlock related to delivering IPIs on AMD 64-bit processors has
been identified.</td>
</tr>
<tr>
<td>SCHED_ULE update</td>
<td>&status.done;</td>
<td>&a.jeff;</td>
<td>Many improvements have been made to the ULE scheduler in 6-CURRENT.
These should be merged back to 5.4. The merging is done but ULE is
still known to cause panics for some people, especially on SMP
systems. Try it with extreme caution.</td>
</tr>
</table>
</body>
</html>
|
