that tells pmap_zero_page() and pmap_copy_page() to unconditionally invalidate
pages for r5k-class CPUs with secondary cache.
This behavior must be explicitly enabled by setting mips_sdcache_forceinv to 1.
This is the last bit of a patch that has been kicked around since 2000 between
rafal@, tsutsui@, and myself.
with aif_get_mailbox(). Make it return uint32_t instead of 'int'.
* Add an AAC_GET_MAILBOX() macro and change AAC_GET_MAILBOXSTATUS() to use
that.
* Update the Dell PERC 2QC quirk code to use AAC_GET_MAILBOX instead of the
StrongARM-specific code. While StrongARM access is correct for that card,
it's a bad example of how to access the mailbox registers.
* Add the GETINFO command and use it to get and display the card's
supported options at a verbose level during attachment.
and similar niceties both replaces what I added my name to OpenSSH
to work on (integrate the very nice but by now very outdated openssh+gssapi
patches), and works with current OpenSSH versions.
with this in mind, remove `some not-so-wise guy's' name from OpenSSH and
add elric's. :-)
The value of 50 dates back to 4.3BSD and 10Mbit interfaces.
Gigabit interfaces are 100x faster, and by observation, when heavy
interrupt mitigation is enabled, gigabit interfaces can enqueue 40 packets
or more in a single hardware interrupt. So IFQ_MAXLEN of 256 is adequate
for at least four gigabit interfaces.
Increasing IFQ_MAXLEN discussed and approved, in priniciple, circa Apr 2004.
The value is sysctl'able, so the default is no longer so critical,
but (imho) best to tune for high-performane systems by default.
NAT-T changes. Matches changes to reference non-nonexistent structs in
sys/netkey.
I have no clue if this is correct, but it matches the style in
sys/netkey, and (unlike the previous two revisions) it actually compiles...
http://www.sigusr1.org/~kurahone/tcp-sack-netbsd-02152005.diff.gz
Fixes in that patch for pre-existing TCP pcb initializations were already
committed to NetBSD-current, so are not included in this commit.
The SACK patch has been observed to correctly negotiate and respond,
to SACKs in wide-area traffic.
There are two indepenently-observed, as-yet-unresolved anomalies:
First, seeing unexplained delays between in fast retransmission
(potentially explainable by an 0.2sec RTT between adjacent
ethernet/wifi NICs); and second, peculiar and unepxlained TCP
retransmits observed over an ath0 card.
After discussion with several interested developers, I'm committing
this now, as-is, for more eyes to use and look over. Current hypothesis
is that the anomalies above may in fact be due to link/level (hardware,
driver, HAL, firmware) abberations in the test setup, affecting both
Kentaro's wired-Ethernet NIC and in my two (different) WiFi NICs.
matt