with FAST_IPSEC rather than the KAME IPSEC stack.
Note that the output of "netstat -s -p ipsec" differs depending on which
stack is compiled into the kernel since they each keep different stats.
This delta also adds the "esp", "ah", and "ipcomp" protocol stats, which
are also available when the kernel is compiled with the FAST_IPSEC stack
(e.g. "netstat -s -p esp").
Submitted by: Matt Titus <titus at nttmcl dot com>
MFC after: 3 days
perform varying number of small IPC operations. It runs using a single
process and one thread, a single process and two threads, and using
multiple processes. Critical to its performance measure are the cost and
frequency of context switches, locking overhead, and threading
performance. The benchmark generates .csv output appropriate for reading
into a spreadsheet to generate summary statistics and perform statistical
tests easily.
cardbus_cis.c to this file, some code was not merged and thus resource
list entries were invalid. They didn't have a resources attached to
them.
However, the problem was masked for some time later, because newer
resources list entries were added to the head of the list, and
resource_list_find() always returned the first matching resource list
entry. Usually the underlying driver allocated a valid resource and
added it to the head of the list, and invalid one wasn't used.
In rev. 1.174 of subr_bus.c the sorting of resource list entries was
reversed demasking the problem in cardbus_alloc_resources().
This commit fixes the problem returning back some code from
cardbus_cis.c, pre-1.49 revisions.
PR: kern/87114
PR: kern/90441
Hardware provided by: Vasily Olekhov <olekhov yandex.ru>
Reviewed by: imp
. remove unnecessay header files after Scott's bus_dma(9) commit.
. remove global variable tis which was introduced at the time of
zero_copy(9) changes. The variable tis was not used at all. The
same applyes to ti_links in softc so axe it.
. deregister variables.
. axe ti_vhandle and switch to use explicit register access for
accessing NIC local memory. Creates three variants of ti_mem to
read/write NIC local memory(ti_mem_read, ti_mem_write) and clearing
NIC local memory(ti_mem_zero). This greatly enhances code
readability and have ti(4) drop using shared memory scheme for
Tigon 1. As Tigon 1 switched to use explicit register access for Tx,
axe ti_tx_ring_nic/ti_cmd_ring in softc.(Tigon 2 used to host ring
scheme which means there is no need to access NIC local memory via
register access for Tx and NIC would DMA the modified Tx rings into
its local memory.) [1]
. introduce new macro TI_EVENT_*/TI_CMD_* to handle NIC envent/command.
Instead of using bit fields assginment for accessing the event, use
shift operations to set/get it. [1]
. add additional check for valid DMA tags in ti_free_dmamaps().
. add missing bus_dmamap_sync/bus_dmamap_unload in ti_free_*_ring_*.
. fix locking nits(MTX_RECURSE mutex) and make ti(4) MPSAFE.
. change data type of ti_rdata_phys to bus_addr_t and don't blindly
cast to uint32_t.
. rearrange detach path and make ti(4) survive during device detach.
. for Tigon 1, use explicit register access for checking Tx descriptors
in ti_encap()/ti_txeof(). [1]
. properly call bus_dmamap_sync(9) for updating statistics.
. remove extra semicolon in ti_encap()
. rewrite loading MAC address to work on strict-alignment architectures.
. move TI_RD_OFF macro to if_tireg.h
. axe ETHER_ALIGN as it's already defined in <net/ethernet.h>.
. make macros immuine from expansion by adding parenthesis and do-while.
. remove alpha specific hack as vtophys(9) is no longer used in ti(4)
after Scott's bus_dma(9) fix.
Reviewed by: scottl
Obtained from: OpenBSD [1]
UMA_SLAB_MALLOC flag.
In some circumstances (I observed it when I was doing a lot of reallocs)
UMA_SLAB_MALLOC can be set even if us_keg != NULL.
If this is the case we have wonderful, silent data corruption, because less
data is copied to the newly allocated region than should be.
I'm not sure when this bug was introduced, it could be there undetected
for years now, as we don't have a lot of realloc(9) consumers and it was
hard to reproduce it...
...but what I know for sure, is that I don't want to know who introduce
the bug:) It took me two/three days to track it down (of course most of
the time I was looking for the bug in my own code).
amd64_set_watch() as 'unsigned int' and 'unsigned int' is 32bit long on amd64.
Even with that fix hardware watchpoint don't work for me on amd64, ie. when
I set the watchpoint and write a byte there, nothing happens.
2005 when another one comes out. This one, even ADO hopes will be the
last of the year.
Obtained from: Arthur Olson, ftp://elsie.nci.nih.gov/pub/tzdata2005r.tar.gz
