rf_dagutils.h... missed this one from yesterday. sorry folks :( ]
Change signature of rf_AllocBuffer() to take a dag_h and buffer size
instead of an PDA and an alloclist. This lets us do the vple dance
inside of rf_AllocBuffer().
Cleanup usage of rf_AllocIOBuffer() and use rf_AllocBuffer() instead.
Fix all uses of rf_AllocBuffer() to conform to the new way of doing
things.
not being at 8k - causes all sorts of problems, in particular with
ffsv1 filessytems with 64k blocks, and disks that are reformatted from
ffsv1 to ffsv2 (and v.v.). see also PR kern/24809
instead of an PDA and an alloclist. This lets us do the vple dance
inside of rf_AllocBuffer().
Cleanup usage of rf_AllocIOBuffer() and use rf_AllocBuffer() instead.
Fix all uses of rf_AllocBuffer() to conform to the new way of doing
things.
used in the event that we can't malloc a buffer of the appropriate
size in the traditional way. rf_AllocIOBuffer() and rf_FreeIOBuffer()
deal with allocating/freeing these structures. These buffers are
stored in a list on the 'iobuf' list. iobuf_count keeps track of how
many buffers are available, and numEmergencyBuffers is the effective
"high-water" mark for the freelist. The buffers allocated by
rf_AllocIOBuffer() are stripe-unit sized, which is the maximum
size requested by any of the callers.
Add an iobufs entry to RF_DagHeader_s. Use it for keeping track of
buffers that get allocated from the free-list.
Add a "generic list" pool (VoidPointerListElement Pool) for elements
used to maintain a list of allocated memory. [It is somewhat less
than ideal to add another little pool to handle this...]
Teach rf_AllocBuffer() to use the new rf_AllocIOBuffer(). Modify
other Mallocs to use rf_AllocIOBuffer(), and to update dag_h->iobufs as
appropriate.
Update rf_FreeDAG() to handle cleanup of dag_h->iobufs.
While here, add some missing pool_destroy() calls for a number of pools.
With these changes, it should (in theory) be possible to swap on
RAID 5 sets again. That said, I've not had any success there yet --
but the last issue I saw at least wasn't in RAIDframe. :-}
[There is room for this code to become a bit more consise, but I
wanted to do a checkpoint here with something known to work :) ]
Add 'XXX FIXME' comments to ah4_ctlinput(), esp4_ctlinput()
ipcode-paths merely cast away local variables ip, ah/esp, sav; the
fast-ipsec IPv4 code appears to work even so.
In espv6_ctlinput(), call the fast-ipsec KEY_ALLOCSA()/KEY_FREESA()
macros, not the KAME-native key_allocsa()/key_freesa() functions.
Cast sa6_src/sa6_dst to void; the fast-ipsec API does not (yet) pass
both src and dst addrs to KEY_d-ALLOCSA/KEY_FREESA.
Make sure 'off' is set to 0 on the branch where it was formerly
used-before-set.
Will now compile with ``options INET6'' (as in
sys/arch/i386/conf/GENERIC.FAST_IPSEC), but is not yet
expected to acutally work with IPv6.
Rx interrupts, functions to post a request for new table entries, and
code to apply pending Rx-interrupt control values at the next hardware
interrupt.
As used in a third-party proprietary tree since at least March 2003.
As discussed on tech-kern/tech-net in January 2004 (in the context of
NetBSD for packet capture, bpf, and FreeBSD-sylte IFF_POLL), and as
posted to tech-net for comments in mid-March 2004.
Still missing sysctl or other knobs to acutally change the config-time
values, due to my ignorance of any accepted per-device sysctl namespace.
(e.g., polling for a half-second or more at splnet(), blocking most
interrupts, durin an ifconfig down/ifconfig up).
Appears to help for a 5704C rev A3, which is the only chip I've
ever seen that had even a mild version of the reported problem.
get properly probed and initialized. This also fixes the problem of the
keyboard getting the console output and the keyboard port getting the wrong
serial baud rate. The lcg driver is not currently present, but should be
"real soon now".
already mapped in the early console startup.
The software cursor isn't going to blink if we don't start it - set up the
callout when attaching.
Now that the cursor blink routine is actually called, blink the entire cursor
line rather than just the first pixel.
Don't try to clear the current cursor if the pointer to it hasn't been
initialized. This seems to happen when using the display as console, but
not when using a serial console.
On early console startup, use the framebuffer sizes, not the character cell
size to compute how much to clear.
The lcspx display will now initialize when booting with the display console,
but the dz device is not detected and the keyboard will not work yet. I
haven't tracked down why the dz device isn't found (it works fine when
using a serial console).
for RF_DagNode_t's. Scale the structure size based on RF_MAXCOL.
Use the new allocation method in InitNode(). Note that we can't get
rid of the mallocs in there until we can prove that this new
allocation method is a strict upper bound. Unless someone tries
running a RAID set with 40 components, the mallocs here shouldn't
shouldn't be an issue. (and if someone does make a set with 40 components
they will run into other issues with other constants long before
then)
- Pull rf_FreePhysDiskAddr() out from under a #ifdef, since we're now
going to use it.
- Add a pda_cleanup_list into the DAG header. Use it in rf_FreeDAG() to
cleanup any PDA's that get allocated but have no "easy" way of being
located and freed when the DAG completes.
- numStripeUnitsAccessed is a per-stripe value, and has a maximum
value equal to the number of colums (thus limited by RF_MAXCOL).
Use this knowledge to set a high-bound on overlappingPDAs, and stuff
it on the stack instead of malloc'ing it all the time! This costs us
a whopping 40 bytes on the stack, but saves a malloc() and a free().
elements from the pools.
Re-work rf_SelectAlgorithm() to get rid of all the 8 malloc's, and to
use the new functions to get/put these 'support structures'. I'm not
overly happy with some of the variable names, but them's the breaks.
In the process of changing things, fix a bug:
- in the case where we can't create a dag, free asmh_b and blockFuncs
too!!
[if you were able to look at the source code related to these changes,
and comprehend what was going on without having your eyes bleed or
getting dizzy, please contact me... I'm sure I'll have more code
which would benefit by you having a look at it before I commit it :) ]
As we turn the chip to big-endian mode on big-endian systems, we should
never byte-swap the data read/written from/to registers. Tested on sparc64.
Finally fix kern/13341 by Jason R. Thorpe (really, the hard work of putting
bus_dmamap_sync() calls at the right places has been done my Jason mid-2001 :)
- factor out common code.
- don't stop searching before the target.
- touch the correct object.
- validate the argument before the loop otherwise we need to roll back.
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!
I have pulled that code into the function ieee80211_rssadapt_choose
so that I can re-use it in ath(4), atw(4), and in other drivers.
In rssadapt(9), I have also created a struct ieee80211_rssadapt_expavgctl
that contains parameters for rate adaptation. When IEEE80211_RSSADAPT_DEBUG
is enabled, I will using sysctl to expose an ieee80211_rssadapt_expavgctl
for each wireless device.
Also in rssadapt(9), I have introduced an interpolate() macro which
makes the exponential-averaging code more compact.
