mav [Tue, 3 Jan 2012 13:16:47 +0000 (13:16 +0000)]
MFC r225839:
Import the rest of HID improvements from the branch:
- improve report descriptor parser in libusbhid to handle several kinds of
reports same time;
- add to the libusbhid API two functions wrapping respective kernel IOCTLs
for reading and writing reports;
- tune uhid IOCTL interface to allow reading and writing arbitrary report,
when multiple supported by the device;
- teach usbhidctl to set output and feature reports;
- make usbhidaction support all the same item names as bhidctl.
mav [Tue, 3 Jan 2012 13:13:31 +0000 (13:13 +0000)]
MFC r213920 (by hselasky):
- Add support for libusbhid in 32-bit compatibility mode.
- Add missing check for ugd_actlen being too small.
- Add missing inclusion guard to usbvar.h header file.
delphij [Tue, 3 Jan 2012 10:22:09 +0000 (10:22 +0000)]
MFC r226471 (se):
Add missing default values for daily/800.scrub-zfs for documentation
purposes. No functional change, since all parameters are set to their
default values.
MFC r226865 (delphij):
Increase default scrub threshold from 30 days to 5 weeks. Using
whole weeks makes it easier to predicate when the scrub would
happen.
hselasky [Tue, 3 Jan 2012 09:15:54 +0000 (09:15 +0000)]
MFC r228483, r228640, r228709, r228711, r228723 and r229086:
- Implement better support for USB controller suspend and resume.
- Add code to wait for USB shutdown to be executed at system shutdown.
- Add sysctl which can be used to skip this waiting.
NOTE: All USB controller drivers needs to be re-compiled after
this change due to changes in some USB controller only structures.
rmacklem [Tue, 3 Jan 2012 04:12:40 +0000 (04:12 +0000)]
MFC: r227543
Modify the new NFS client so that nfs_fsync() only calls ncl_flush()
for regular files. Since other file types don't write into the
buffer cache, calling ncl_flush() is almost a no-op. However, it does
clear the NMODIFIED flag and this shouldn't be done by nfs_fsync() for
directories.
yongari [Tue, 3 Jan 2012 00:24:44 +0000 (00:24 +0000)]
MFC r226814-226815,226820-226821,226864,226866-226867:
r226814:
Rename definition of BGE_SOFTWARE_GENCOMM_* to more readable ones.
The origin of GENCOMM seems to come from Alteon Tigon Host/NIC
interface definition where it defines general communications region
which is active when firmware is loaded and running. This region
was used in communication between the host and processor internal
to the Tigon chip.
Broadcom data sheet also defines the region as 'Software Gencomm'
in NetXtreme memory map but lacks detailed description of its
interface so it was hard to know which ones are used for which
interface.
This change shall slightly enhance readability.
No functional changes.
r226815:
Define MAC address mail box and use it instead of using
hard-coded value.
r226820:
Offset 0x6810 is RX-RISC event register. Rename BGE_CPU_EVENT with
BGE_RX_CPU_EVENT for readability.
Additionally define BGE_TX_CPU_EVENT for TX-RSIC event register(BCM570[0-4] only).
r226821:
SRAM offset 0x0C04 is used by driver to inform the IPMI/ASF firmware
about the various driver events like load, unload, reset, suspend,
restart, and ioctl operations.
Define driver's event rather than using hard-coded values. We don't
still send suspend/resume event to firmware.
Previously bge(4) used BGE_SDI_STATUS to send events. Because driver
has to access firmware mail box to inform current state, using
BGE_SDI_STATUS register was wrong. The end result was the same as
BGE_SDI_STATUS is 0x0C04.
No functional changes.
r226864:
Rename BGE_FW_DRV_ALIVE/BGE_FW_PAUSE to BGE_FW_CMD_DRV_ALIVE/BGE_FW_CMD_PAUSE.
Also add more firmware commands(not used yet).
No functional changes.
r226866:
Rename hard-coded value 1 << 14 with BGE_RX_CPU_DRV_EVENT.
This bit(SW event 7 in publicly available data sheet) is used to
make RX CPU handle a firmware command and the bit is automatically
cleared after RX CPU completed the command.
Generally firmware command takes the following steps.
1. Write BGE_SRAM_FW_CMD_MB with a command.
2. Write BGE_SRAM_FW_CMD_LEN_MB with the length of the command in bytes.
3. Write BGE_SRAM_FW_CMD_DATA_MB with actual command data.
4. Generate BGE_RX_CPU_EVENT and let firmware handle the command.
5. Wait for the ACK of the firmware command.
No functional changes.
r226867:
Define BGE_FW_HB_TIMEOUT_SEC and remove one more magic value.
bge(4) sends BGE_FW_CMD_DRV_ALIVE command to firmware every 2
seconds. BGE_FW_CMD_DRV_ALIVE command requires 4 bytes data. This
data contains timeout value in seconds until the next
BGE_FW_CMD_DRV_ALIVE command.
Broadcom recommends driver set the value 3 times longer than the
interval that it sends BGE_FW_CMD_DRV_ALIVE. Currently bge(4) uses
3 seconds so probably we have to increase it in future and use
different ALIVE command(e.g. BGE_FW_CMD_DRV_ALIVE3).
r226770:
Fix long standing bge_sysctl_debug_info() issues.
o Protect bge(4) status block access and register dump with driver lock.
o Add missing bus_dmamap_sync() before dumping status block.
o Use minimum status block size, 32 bytes, for status block dump on most
controllers except BCM5700 AX/BX.
While I'm here, make the handler show 5717 Plus in hardware flags.
r226804:
Make CPMU handle GPHY power down control on controllers that have
CPMU capability.
r226805:
It is known that all Broadcom controllers have 4GB boundary DMA
bug. Apply workaround to all controllers.
r226806:
Broadcom says BCM5755 or higher and BCM5906 have short DMA bug.
Apply workaround to these controllers.
r226807:
BCM5719 cannot handle DMA requests for DMA segments that have
larger than 4KB in size. However the maximum DMA segment size
created in DMA tag is 4KB, so we wouldn't encounter the issue here.
Just record this issue such that let developers not to create a DMA
segment that is larger than 4KB for BCM5719. It's possible to split
a DMA segment into multiple smaller ones in run time but I believe
it's not worth to implement that.
yongari [Mon, 2 Jan 2012 23:50:32 +0000 (23:50 +0000)]
MFC r226743:
Implement TX/RX checksum offloading support for ASIX AX88772B
controller.
AX88772B data sheet does not show detailed information about
checksum offloading related things. It seems the controller has
lots of options to support checksum offloading but I failed to
understand why this feature requires so much complex controller
configuration and status bits.
One of major difference between AX88772B and its predecessor is
AX88772B uses a new RX header format when RX checksum offloading is
enabled. It also requires the received length of a frame should be
multiple of 4. Controller will pad necessary bytes to make the
length of received frame to be multiple of 4. It is driver's
responsibility to offset this pad bytes.
Note, AX88772B could be configured to get partial checksum value in
in RX header. This mode uses different RX header format and
currently we don't use that fature.
This change makes axe(4) use driver specific MII attach handler to
override uether(9)'s default MII attach and announce flow-control
capability for AX88178/AX88772A/AX88772B to PHY drivers. It seems
original AX88772 also supports flow-control but I didn't enable it
due to lack of test/access to the controller. The flow-control
threshold parameter is loaded from EEPROM and there is no way to
override this value without reprogramming EEPROM. For AX88772B,
TX/RX IP/TCP/UDP checksum offloading is announced to network stack.
IPv6 and PPPoE checksum offloading is also supported by controller
but we have no way to take advantage of these features.
Driver already knows PHY address so make PHY driver know that
information and remove unnecessary PHY address check used in
miibus_readreg/miibus_writereg callbacks. Also announce AX88178,
AX88772A and AX88772B support VLAN over-sized frame.
While I'm here clean up headers and remove axe_start() in
axe_init() because the link wouldn't be available right after media
change.
yongari [Mon, 2 Jan 2012 23:47:51 +0000 (23:47 +0000)]
MFC r226709:
This change makes it possible to define driver specific attach
handler such that driver can announce interface capabilities and
can do its own MII attach. Currently all USB ethernet controllers
have no way to establish a link with pause capabilities. Lack of
checksum offloading support also was one of reason to bring this
change in.
This change adds a couple of wrappers to USB ethernet drivers
(uether_ifmedia_upd, uether_init and uether_start). All exported
functions in uether has prefix uether_ so I think it's more
consistent to have wrappers that follow the convention.
This change preserves ABI/KPI so it should be safe to merge this
change to stable/8.
While I'm here add missing __FBSDID and clean up headers.
gjb [Mon, 2 Jan 2012 23:44:07 +0000 (23:44 +0000)]
MFC r210993, r228356:
r210933 (joel):
- Fix typos and spelling mistakes
r228356: [3]
- Update du(1):
- Sort arguments alphabetically where appropriate
- '-B blocksize' is not mutually exclusive of '-h|-k|-m'
- Mention '-t' in synopsis
- Other wording improvements
- Update usage() output to reflect the new synopsis
- Other miscellaneous improvements
yongari [Mon, 2 Jan 2012 23:38:03 +0000 (23:38 +0000)]
MFC r226701:
Add support for ALi/ULi, now NVIDIA, M5261/M5263 PCI FastEthernet
controller which is found on ULi M1563 South Bridge & M1689 Bridge.
These controllers look like a tulip clone.
M5263 controller does not support MII bitbang so use DC_ROM
register to access MII registers. Like other tulip variants, ULi
controller uses a setup frame to configure RX filter and uses new
setup frame format. It's not clear to me whether the controller
supports a hash based multicast filtering so this patch uses 14
perfect multicast filter to filter multicast frames. If number of
multicast addresses is greater than 14, controller is put into a
mode that receives all multicast frames.
Due to lack of access to M5261, this change was not tested with
M5261 but it probably works. Many thanks to Marco who provided
remote access to M5263.
Tested by: Marco Steinbach <coco <> executive-computing dot de>,
Martin MATO <martin.mato <> orange dot fr>
yongari [Mon, 2 Jan 2012 23:20:22 +0000 (23:20 +0000)]
MFC r226699:
When driver is run for the first time there would be no established
link such that calling dc_setcfg() right after media change would
be meaningless unless controller in question is not Davicom DM9102.
Ideally dc_setcfg() should be called when speed/duplex is resolved
otherwise it would reprogram controller with wrong speed/duplex
information. Because MII status change callback already calls
dc_setcfg() I think calling dc_setcfg() in dc_init_locked() is
wrong. For instance, it would take some time to establish a link
after mii_mediachg(), so blindly calling dc_setcfg() right after
mii_mediachg() will always yield wrong media configuration.
Extend dc_ifmedia_upd() to handle media change and still allow
21143 and Davidcom controllers program speed/duplex regardless of
current resolved speed/duplex of link. In theory 21143 may not need
to call dc_setcfg() right after media change, but leave it as it is
because there are too many variants to test that change. Probably
dc(4) shall need a PHY reset in dc_ifmedia_upd() but it's hard to
verify correctness of the change.
This change reliably makes ULi M5263 establish a link.
While I'm here correctly report media change result. Previously it
always reported a success.
mav [Mon, 2 Jan 2012 19:27:23 +0000 (19:27 +0000)]
MFC r227464, r227471:
Major GEOM MULTIPATH class rewrite:
- Improved locking and destruction process to fix crashes.
- Improved "automatic" configuration method to make it consistent and safe
by reading metadata back from all specified paths after writing to one.
- Added provider size check to reduce chance of ordering conflict with
other GEOM classes.
- Added "manual" configuration method without using on-disk metadata.
- Added "add" and "remove" commands to allow manage paths manually.
- Failed paths are no longer dropped from geom, but only marked as FAIL
and excluded from I/O operations.
- Automatically restore failed paths when all others paths are marked
as failed, for example, because of device-caused (not transport) errors.
- Added "fail" and "restore" commands to manually control FAIL flag.
- geom is now destroyed on last path disconnection.
- Added optional Active/Active mode support. Unlike Active/Passive
mode, load evenly distributed between all working paths. If supported by
the device, it allows to significantly improve performance, utilizing
bandwidth of all paths. It is controlled by -A option during creation.
Disabled by default now.
- Improved `status` and `list` commands output.
mav [Mon, 2 Jan 2012 17:58:07 +0000 (17:58 +0000)]
MFC r226816:
Clarify disks/volumes above 2TiB support in geom_raid:
- add support for volumes above 2TiB with Promise metadata format;
- enforse and document other limitations:
- Intel and Promise metadata formats do not support disks above 2TiB;
- NVIDIA metadata format does not support volumes above 2TiB.
mav [Mon, 2 Jan 2012 17:38:06 +0000 (17:38 +0000)]
MFC r227637:
Introduce CAM_SIM_POLLED SIM flag, indicating that it works in polling mode.
It blocks CAM SWI usage on requests completion, unneeded because of polling
and denied during kernel dumping because of blocked scheduler.
Before r198899 there was periph flag CAM_PERIPH_POLLED, but that was wrong,
because there is whole SIM is polled or handled by SWI, not a single periph.
mav [Mon, 2 Jan 2012 17:28:14 +0000 (17:28 +0000)]
MFC r226680:
Some dmesg cosmetics:
- for the legacy PCI ATA channels move channel number out of the device
description, same as it is for ahci(4), siis(4) and mvs(4);
- add device description for the ISA ATA channels.
mav [Mon, 2 Jan 2012 17:21:41 +0000 (17:21 +0000)]
MFC r228200:
Add hw.ahci.force tunable to control whether AHCI drivers should attach
to known AHCI-capable chips (AMD/NVIDIA), configured for legacy emulation.
Enabled by default to get additional performance and functionality of AHCI
when it can't be enabled by BIOS. Can be disabled to honor BIOS settings if
needed for some reason.
mav [Mon, 2 Jan 2012 17:16:08 +0000 (17:16 +0000)]
MFC r227635:
Change the way how "not implemented" AHCI channels handled. Instead of
completely skipping them, create ahcich devices for them to allocate unit
numbers, but mark them as disabled to prevent driver probe and attach.
Last time some BIOSes tend to report unused channels as "not implemented".
This change makes ahcichX devices numbering consistent, independently of
connected disks. It makes per-channel driver hints usable and CAM devices
wiring possible on such systems.
rmacklem [Mon, 2 Jan 2012 04:47:38 +0000 (04:47 +0000)]
MFC: r227517
Move the setting of the default value for nm_wcommitsize to
before the nfs_decode_args() call in the new NFS client, so
that a specfied command line value won't be overwritten.
Also, modify the calculation for small values of desiredvnodes
to avoid an unusually large value or a divide by zero crash.
It seems that the default value for nm_wcommitsize is very
conservative and may need to change at some time.
kib [Sun, 1 Jan 2012 23:12:56 +0000 (23:12 +0000)]
MFC r227696:
Do not use NULLVPTOLOWERVP() in the null_print(). If diagnostic is compiled
in, and show vnode is used from ddb on the faulty nullfs vnode, we get
panic instead of vnode dump.
dougb [Sun, 1 Jan 2012 22:33:29 +0000 (22:33 +0000)]
MFC r228909:
1. Remove a bunch of duplicates. Usually this means removing them from
fortunes, but occasionally remove them from the other 2 files when
they are not offensive, or not murphy'ish enough.
Where the version in fortunes had better attribution and/or formatting,
copy it over.
2. Fix a few typos
3. Use the full name of François De La Rochefoucauld, fix one of his
quotes, and remove the duplicate of it.
MFC r228934:
Prefer ASCII apostrophes over Unicode ones like the rest of the file.
MFC r228938:
1. Correct capitalization of the nobility particle for
Francois de La Rochefoucauld introduced in r228909
2. Change c-cedilla introduced in the same commit to ASCII c since
non-UTF-8 terminals will choke on the non-ASCII text.
rmacklem [Sun, 1 Jan 2012 17:05:24 +0000 (17:05 +0000)]
MFC: r227493
Move the assignment of default values for some mount options
to before the nfs_decode_args() call in the new NFS client,
so they don't overwrite the value specified on the command line.
mdf [Sat, 31 Dec 2011 20:15:46 +0000 (20:15 +0000)]
MFC r228440:
Consistently use types in ixgbe driver code:
- {ixgbe,ixv}_header_split is passed to TUNABLE_INT, so delcare it
int, not bool.
- {ixgbe,ixv}_tx_ctx_setup() returns a boolean value, so declare it
bool, not int.
- {ixgbe,ixv}_tso_setup() returns a bool, so declare it bool, not boolean_t.
- {ixgbe,ixv}_txeof() returns a bool, so declare it bool, not boolean_t.
- Do not re-define bool if the symbol already exists.
mdf [Sat, 31 Dec 2011 19:55:19 +0000 (19:55 +0000)]
MFC r228441:
Consistently use types in e1000 driver code:
- Two struct members eee_disable are used in a function that expects
an int *, so declare them int, not bool.
- igb_tx_ctx_setup() returns a boolean value, so declare it bool, not int.
- igb_header_split is passed to TUNABLE_INT, so delcare it int, not bool.
- igb_tso_setup() returns a bool, so declare it bool, not boolean_t.
- Do not re-define bool/true/false if the symbols already exist.
yongari [Sat, 31 Dec 2011 01:08:31 +0000 (01:08 +0000)]
MFC r226478:
Close a race where SIOCGIFMEDIA ioctl get inconsistent link status.
Because driver is accessing a common MII structure in
mii_pollstat(), updating user supplied structure should be done
before dropping a driver lock.
yongari [Sat, 31 Dec 2011 00:46:06 +0000 (00:46 +0000)]
MFC r226123:
BCE_MISC_ID register of BCM5716 returns the same id of BCM5709 so
remove explicit checks for BCM5716.
The BCM5709 and BCM5716 chips are virtually indistinguishable by
software except for the PCI device ID. The two chips differ in
that BCM5709 supports TCP/IP and iSCSI offload in Windows while
the BCM5716 doesn't.
While I'm here remove now unused definition of BCE_CHIP_NUM_5716
and BCE_CHIP_ID_5716_C0.
kib [Fri, 30 Dec 2011 21:02:32 +0000 (21:02 +0000)]
MFC r227816:
Remove the wrong comment about ufs not being loadable.
Note that only root filesystem module needs to be available
before root is mounted.
kib [Fri, 30 Dec 2011 20:24:52 +0000 (20:24 +0000)]
MFC r227393:
Lock the thread lock around block that retrieves td_wmesg. Otherwise,
procfs could see a thread with assigned td_wchan but still NULL td_wmesg.
kib [Fri, 30 Dec 2011 18:29:09 +0000 (18:29 +0000)]
MFC r227024:
Despite official i386 ABI does not mandate any stack alignment besides
the word alignment, some versions of gcc do require 16-byte alignment.
Make sure the stack is 16-byte aligned before calling a subroutine.
kib [Fri, 30 Dec 2011 18:22:34 +0000 (18:22 +0000)]
MFC r227023:
Make sure that stack is 16-byte aligned before calling a function,
as it is required by amd64 ABI. Add a comment for the places were
the stack is accidentally properly aligned already.
pho [Fri, 16 Dec 2011 12:53:15 +0000 (12:53 +0000)]
MFC: r228360
Move cpu_set_upcall(newtd, td) up before the first call of
thread_free(newtd). This to avoid a possible page fault in
cpu_thread_clean() as seen on amd64 with syscall fuzzing.
jhb [Thu, 15 Dec 2011 16:39:48 +0000 (16:39 +0000)]
MFC 225168:
If a drive is not part of the array (i.e. missing) we need to print the
new line after the pd state information as well, so move it to the outside
of the block.
des [Tue, 13 Dec 2011 13:02:52 +0000 (13:02 +0000)]
MFH r228384: validate the service name
Security: some poorly thought out programs allow the user to specify
the service name; this patch makes it harder to trick these
programs into loading and executing arbitrary code.
pho [Mon, 12 Dec 2011 17:33:38 +0000 (17:33 +0000)]
MFC: r228218, r228219, 228220, 228221
Rename copyin_timeout32 to umtx_copyin_timeout32 and move parameter
check here. Include check for negative seconds value.
Add umtx_copyin_timeout() and move parameter checks here.
Add declaration of umtx_copyin_timeout()
Use umtx_copyin_timeout() to copy and check timeout parameteri in
kern_thr_suspend().
des [Sun, 11 Dec 2011 20:38:36 +0000 (20:38 +0000)]
MFH r227757: check for null passphrases, since openssl doesn't
Security: prevents users with unencrypted ssh keys (prohibited
unless the nullok option is specified) from logging in
by providing a bogus non-null passphrase.
gonzo [Thu, 8 Dec 2011 00:47:22 +0000 (00:47 +0000)]
MFC r208737 (required by OCTEON* kernels):
Add/improve mips64r2, Octeon, n32 and n64 support in the toolchain.
o) Add TARGET_ABI to the MIPS toolchain build process. This sets the default
ABI to one of o32, n32 or n64. If it is not set, o32 is assumed as that is
the current default.
o) Set the default GCC cpu type to any specified TARGET_CPUTYPE. This is
necessary to have a working "cc" if e.g. mips64 is specified, as binutils
will refuse to link objects using different ISAs in some cases.
o) Add support for n32 and n64 ABIs to binutils and GCC.
o) Add additional required libgcc2 stubs for n32 and n64.
o) Add support for the "mips64r2" architecture to GCC. Add the "octeon"
o) When static linking, wrap default libraries in --start-group and
--end-group. This is required for static linking to work on n64 with the
interdependencies between libraries there. This is what other OSes that
support n64 seem to do, as well.
o) Fix our GCC spec to define __mips64 for 64-bit targets, not __mips64__, the
former being what libgcc, etc., check and the latter seemingly being a
misspelling of a hand merge from a Linux spec.
o) When no TARGET_CPUTYPE is specified at build time, make GCC take the default
ISA from the ABI. Our old defaults were too liberal and assumed that 64-bit
ABIs should default to the MIPS64 ISA and that 32-bit ABIs should default to
the MIPS32 ISA, when we are supporting or will support some systems based on
earlier 32-bit and 64-bit ISAs, most notably MIPS-III.
o) Merge a new opcode file (and support code) from a later version of binutils
and add flags and code necessary to support Octeon-specific instructions.
This should also make merging opcodes for other modern architectures easier.
No objections from: imp, jmallet, jchandra
MFC after: 18 months
alc [Sun, 4 Dec 2011 18:55:19 +0000 (18:55 +0000)]
MFC r219157
Make a change to the implementation of the direct map to improve
performance on processors that support 1 GB pages. Specifically, if the
end of physical memory is not aligned to a 1 GB page boundary, then map
the residual physical memory with multiple 2 MB page mappings rather than
a single 1 GB page mapping. When a 1 GB page mapping is used for this
residual memory, access to the memory is slower than when multiple 2 MB
page mappings are used. (I suspect that the reason for this slowdown is
that the TLB is actually being loaded with 4 KB page mappings for the
residual memory.)
alc [Sun, 4 Dec 2011 07:28:50 +0000 (07:28 +0000)]
MFC r223732
When iterating over a paging queue, explicitly check for PG_MARKER,
instead of relying on zeroed memory being interpreted as an empty
PV list.
alc [Sun, 4 Dec 2011 07:18:54 +0000 (07:18 +0000)]
MFC r213897
Update pmap_extract() to handle 1GB page mappings. Some device drivers
use pmap_extract() rather than pmap_kextract() on direct map addresses.
Thus, pmap_extract() needs to be able to deal with 1GB page mappings if
we are to use 1GB page mappings for the direct map. (See r197580.)
alc [Sun, 4 Dec 2011 06:09:02 +0000 (06:09 +0000)]
MFC r214425,214954
[1] According to the x86 architectural specifications, no virtual-to-
physical page mapping should span two or more MTRRs of different types.
Add a pmap function, pmap_demote_DMAP(), by which the MTRR module can
ensure that the direct map region doesn't have such a mapping.
[2] Fix a couple of nearby style errors in amd64_mrset().
[3] Re-enable the use of 1GB page mappings for implementing the direct
map. (See also r197580 and r213897.)
hselasky [Sat, 3 Dec 2011 14:38:54 +0000 (14:38 +0000)]
MFC r227461:
Style change.
- Make it easier to port the USB code to other platforms by only using
one set of memory functions for clearing and copying memory. None of
the memory copies are overlapping. This means using bcopy() is not
required.
- Fix a compile warning when USB_HAVE_BUSDMA=0
- Add missing semicolon in avr32dci.
- Update some comments.
dougb [Thu, 1 Dec 2011 05:48:50 +0000 (05:48 +0000)]
MFC r227482:
The default setting, daily_accounting_compress="NO", was causing
only 1 old file to be saved, so fix this.
While I'm here, fix a very old off-by-one error causing 1 more
file than specified in daily_accounting_save to be saved because
acct.0 was not taken into account (pun intended). Change that, and
use a more thorough method of finding old files to delete. Partly
just because this is the right thing to do, but also to silently
fix the extra log that would have been left behind forever with the
previous method.
bz [Wed, 30 Nov 2011 12:47:36 +0000 (12:47 +0000)]
MFC r224638,224640,224642 (by brooks):
Add support for dynamically adjusted buffers to allow the full use of
the bandwidth of long fat pipes (i.e. 100Mbps+ trans-oceanic or
trans-continental links). Bandwidth-delay products up to 64MB are
supported.
Also add support (not compiled by default) for the None cypher. The
None cypher can only be enabled on non-interactive sessions (those
without a pty where -T was not used) and must be enabled in both
the client and server configuration files and on the client command
line. Additionally, the None cypher will only be activated after
authentication is complete. To enable the None cypher you must add
-DNONE_CIPHER_ENABLED to CFLAGS via the make command line or in
/etc/make.conf.
This code is a style(9) compliant version of these features extracted
from the patches published at:
http://www.psc.edu/networking/projects/hpn-ssh/
Enable keyword expansion for $FreeBSD$ on files.
MFC r225852 (by des):
Regenerate (ssh_namespace.h) after application of the HPN patch.
marius [Tue, 29 Nov 2011 19:49:09 +0000 (19:49 +0000)]
MFC: r227960
Increase the CDMA sync timeout for Schizo bridges to 15 seconds as used by
OpenSolaris. One second turned out to be not enough for certain loads while
10 seconds were sufficient.
Reported by: Peter Jeremy
marius [Tue, 29 Nov 2011 19:45:58 +0000 (19:45 +0000)]
MFC: r228028
- Based on a report on sparc64@ move V245 to the list of known working
machines.
- Mention that V480 with broken centerplanes have a chance of working with
the WAR in the upcoming 8.3-RELEASE and 9.0-RELEASE.
qingli [Mon, 28 Nov 2011 19:53:16 +0000 (19:53 +0000)]
MFC 227460
A default route learned from the RAs could be deleted manually
after its installation. This removal may be accidental and can
prevent the default route from being installed in the future if
the associated default router has the best preference. The cause
is the lack of status update in the default router on the state
of its route installation in the kernel FIB. This patch fixes
the described problem.
projects / FreeBSD / stable / 8.git / log