framework. There is no need to waste the space if you are only using
algoritms provided by hardware accelerators. To get the software
implementations, add "pseudo-device swcr" to your kernel config.
- Lazily initialize the opencrypto framework when crypto drivers
(either hardware or swcr) register themselves with the framework.
* remove all references to $ip6sitelocal and output a warning
message if the variable is defined.
* introduce $ip6uniquelocal (defaults to 'NO') that will control the
behaviour of the system when $ip6mode is ``router'' (i.e. fc00::/7
will not be routed if the variable is ``NO'') as per RFC 4193.
Thanks to Jonathan A. Kollasch for pointing this out in PR 32152.
an overflow occurs.
. Make this error a fatal build time error
. Move the support for dbsym into the MI Makefile.kern.inc,
conditional upon the SYMTAB_SPACE option being defined in
the kernel config file.
shipped from the factory with TSO-capable firmware. The TSO support
here may also work on 5705 chips, but that is (so far) untested.
TSO support written after careful reading of the Linux tg3 driver,
and (after attempting to deconstruct the cut-and-paste mess therein)
very close reading of the Broadcom-supplied Linux driver, particularly
the building of Tx-DMA buffer descriptors (bds). The TSO code herein was
then rewritten from scratch, circa 4am local time, October 27 2005.
(In other words: this is 4am software; caveat emptor.)
Other magic register settings in this patch are required; without
them, attepmting to use TSO locks up the chip. The required register
settings were extracted from the cited Linux drivers.
Note that TSO-capable firmware for the 5703/5704 is distributed in
non-GPL form with the aforementioned Linux drivers. Once the 5705 case
is debugged, (particularly the pseudo-header checksum precalculation
flagged with an XXX) downloading that TSO-capable firmware to the
5703/5704 should, in principle, enable TSO support on all but the
original bcm5700 (I forget if the 5701 can support TSO, or not).
Note also that the ``hard case '' of IP/TCP headers spanning more than
one mbuf is not handled; I haven't been able to trigger it. In any
case, since TSO applies only to packets generated by the local TCP,
and our TCP always leaves space for TCP headers and a normal IP
header, TSO on an IP/TCP header spanning multiple headers can only
arise due to insertion of IP options. I beleive that we are clearly
better off outlawing that case, and requiring ip_insertoptions()
to pull-up TCP headers on any packets with M_CSUM_TSOv4 set.
As far as I know, bge hardwar does not support TSO for IPv6.
