(1) in pmap_enter_pv(), we would always mark the header entry wired, even if
the new entry wasn't put there. noticed by Juergen Hannken-Illjes.
(2) in pmap_unwire(), we would never examine the header entry.
noticed by me.
while I'm here, move the counter increment in the pmap_enter() path to be
next to the corresponding PV_WIRE() call so it's more obvious they match.
Fix the work-around for the NIC bug where it skips to rx
descriptor 0. The driver used to skip to rx descriptor 1.
Hopefully this stops the out-of-order packet reception that
Charles Hannum saw.
When debugging is enabled, print rx-descriptor status flags
before printing the rx bit rate.
Add a debug message for when a beacon tx buffer reclamation.
Reset IFF_OACTIVE when we reset the transmitter.
Pass the consolidated LED state, a struct rtw_led_state,
to rtw_led_attach.
Choose the bit-rate for management frames (1Mb/s) at the
same place we choose for all other frames.
Do not use the NIC's short preamble or RTS options for
management frames. Label beacons for the NIC.
Following a Linux driver, take care not to zero arbitrary
bits in the TPPOLL register.
Use the new idiom for IBSS merges: disable transmitter,
kick the state machine.
Add a second descriptor to the beacon ring. The NIC seems
to like this much better.
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.
itojun