Trimm the priority, as the upper layers won't do it and will drop the packet
if priority is not 0.
While there, print the revision in the "unsupported chip revision" printf.
such that we don't actually hold a simplelock while we are doing
a pool_get(), but that we still effectively protecting critical code.
This should fix all of the outstanding LOCKDEBUG warnings related to
rebuilding RAID sets.
Provide rf_AllocDAGNode() and rf_FreeDAGNode() to handle
allocation/freeing.
- Introduce a "nodes" linked list of RF_DagNode_t's into the DAG header.
Initialize nodes in InitHdrNode(). Arrange for nodes cleanup in rf_FreeDAG().
- Add a "list_next" to RF_DagNode_t to keep track of nodes on the
above "nodes" list. (This is distinct from the "next" field of
RF_DagNode_t, which keeps track of the firing order of nodes.)
"list_next" gets used in the cleanup routines, and in traversing
through a set of nodes that belong to a particular set of nodes
(e.g. those belonging to xorNodes for a given DAG).
- use rf_AllocDAGNode() instead of mallocs of variable-sized arrays of
RF_DagNode_t's. Mostly mechanical changes to convert the DAG construction
from "access nodes via an array index" to "access nodes via a 'nextnode'
pointer".
- rework a couple of tricky spots where assumptions about the node order
was being abused.
- performance remains consistent with performance before these changes.
[Thanks to Simon Burge (simonb at you.know.where) for looking over
the mechanical changes to make sure I didn't biff anything.]
This is an incompatible change, and will break all existing cgd images
encrypted with blowfish. Users will need to dump their data before
booting a kernel with this change, and recreate cgd's and restore data
afterwards.
I believe this affects a very small number of users other than myself;
indeed after several alert mails in an attempt to find them, only 2
such users have come forward. They have both agreed the requirement
for backwards compatibility does not warrant the effort nor the mess
in the code. This code does exist, if it should later prove to be
needed, but will not be in the tree.
Further, by the nature of the issue, I have strong reasons to believe
that, even if they missed these mails, there would be few other users
of blowfish who update their systems with any regularity; any such
users would have tripped over the problem in the same way I did when
it was first found over a year ago.
The problem stems from two issues with the underlying blowfish
encryption routines used by cgd:
- they take key length arguments counted in bytes, rather than bits
like all the opther ciphers.
- they silently truncate any keys longer than an internal limit,
rather than returning an error (which would have exposed the
previous discrepancy immediately).
As a result, the kernel reads too much data as the key from cgdconfig,
and then truncates most of it. This can easily be demonstrated/tested.
Currently, Blowfish users will find that if they mis-enter the cgd
passphrase on the first attempt, when validation fails and cgdconfig
prompts for the passphrase again, the cgd will not correctly configure
even when given a correct passphrase.
driver. Still some issues:
* framebuffer setup seems incomplete. Some drawing primitives work 100%
of the time, while others fail one in ten tries. Perhaps my board is
slightly broken, as the exact model as probed by ARCS seems to shift
between Elan and XS24 from time to time.
* characters are drawn bottom-up rather than top-down (as the wsfont
definitions expect).
it either is sitting in contiguous physical RAM or split the mbuf
into two Tx descriptors. Not the prettiest patch, but works well in
practice - gets about an 8% decrease on CPU time for a simple ttcp TCP
Tx benchmark. Thanks to Chris Demetriou for some debugging help.
Add some event counters.
Remove some #if 0'd debug code.
Figure out whether the shared memory region is word-accessible in the same
place we figure out its size, and store this in the softc, rather than using a
series of comparisons later.
we start calling into C code. Previously we called memset() in our
C code. Unfortunately the compiler would sometimes store local variables
on the statck, which got killed by the memset(). Oops!
