kensmith [Mon, 14 Nov 2011 00:45:25 +0000 (00:45 +0000)]
The releng/9.0 release branch has been created so convert stable/9 over
to our standard "Politically Correct" name for the balance of the 9.0-RELEASE
release cycle.
trociny [Thu, 10 Nov 2011 20:28:30 +0000 (20:28 +0000)]
MFC r227204, 227206, 227207:
r227204:
Fix the typo made in r157474.
r227206:
Before dereferencing intotw() check for NULL, the same way as it is
done for in_pcb (see r157474).
r227207:
Cache SO_REUSEPORT socket option in inpcb-layer in order to avoid
inp_socket->so_options dereference when we may not acquire the lock on
the inpcb.
This fixes the crash due to NULL pointer dereference in
in_pcbbind_setup() when inp_socket->so_options in a pcb returned by
in_pcblookup_local() was checked.
Reported by: dave jones <s.dave.jones@gmail.com>, Arnaud Lacombe <lacombar@gmail.com>
Suggested by: rwatson
Glanced by: rwatson
Tested by: dave jones <s.dave.jones@gmail.com>
andre [Thu, 10 Nov 2011 19:10:53 +0000 (19:10 +0000)]
Back out r226299 (MFC of r226105) which caused a number of ports
that depend on the incorrect IP length field. The fix stays in
HEAD and ports should test for it.
jhb [Wed, 9 Nov 2011 18:26:19 +0000 (18:26 +0000)]
MFC 226748:
- Add a new header for the x86 boot code that defines various structures
and constants related to the BIOS Enhanced Disk Drive Specification.
- Use this header instead of magic numbers and various duplicate structure
definitions for doing I/O.
- Use an actual structure for the request to fetch drive parameters in
drvsize() rather than a gross hack of a char array with some magic
size. While here, change drvsize() to only pass the 1.1 version of
the structure and not request device path information. If we want
device path information you have to set the length of the device
path information as an input (along with probably checking the actual
EDD version to see which size one should use as the device path
information is variable-length). This fixes data smashing problems
from passing an EDD 3 structure to BIOSes supporting EDD 4.
jhb [Wed, 9 Nov 2011 18:12:42 +0000 (18:12 +0000)]
MFC 226302:
If an allocation for a specific resource range fails because it is not in
a decoded range for an ACPI Host-PCI bridge, try to allocate it from the
ACPI system resource range. If that works, permit the resource allocation
regardless.
marius [Mon, 7 Nov 2011 13:40:54 +0000 (13:40 +0000)]
MFC: r227006, r227281, r227282
Add a PCI front-end to esp(4) allowing it to support AMD Am53C974 and
replace amd(4) with the former in the amd64, i386 and pc98 GENERIC kernel
configuration files. Besides duplicating functionality, amd(4), which
previously also supported the AMD Am53C974, unlike esp(4) is no longer
maintained and has accumulated enough bit rot over time to always cause
a panic during boot as long as at least one target is attached to it
(see PR 124667).
marius [Mon, 7 Nov 2011 13:16:51 +0000 (13:16 +0000)]
MFC: r226947, r226949, r227284
- Use device_t rather than the NetBSDish struct device.
- Move esp_devclass to ncr53c9x.c in order to allow different bus front-ends
to use it.
- Use KOBJMETHOD_END.
- Remove the gl_clear_latched_intr hook as it's not needed for any of the
chips nor the front-ends supported in FreeBSD and likely never will be.
- Correct the DMA constraints and only limit the tag used for the transfer
buffers to 32-bit DMA as that address is written into a 32-bit register.
- The ESP200 also only supports up to 64k transfers.
- Don't let the DMA and SBus front-end supply a maximum transfer size larger
than MAXPHYS as that's the maximum the upper layers use and we otherwise
just waste resources unnecessarily.
- Initialize the ECB callout and don't zero the handle when returning ECBs
to the free list so that ncr53c9x_callout() actually is called with the
driver lock held.
- On detach the driver lock should be held across cam_sim_free() according
to isp(4) and a panic received.
- Check the return value of NCRDMA_SETUP(), i.e. bus_dmamap_load(9), and try
to handle failures gracefully.
- In ncr53c9x_action() replace N calls to xpt_done() in a switch with just
one at the end.
- On XPT_PATH_INQ report "NCR" rather than "Sun" as the vendor as the former
is somewhat more correct as well as the maximum supported transfer size via
maxio in order to take advantage of controllers that that can handle more
than DFLTPHYS.
- Freeze the device queue if a request didn't complete without error and
isn't already frozen.
- Print the number of MESSAGE (EXTENDED) rejected.
- Fix the path encoded in the multiple inclusion protection of ncr53c9xvar.h.
- Correct the DMA constraints used in the LSI64854 core to not exceed the
maximum supported transfer size and include the boundary so we don't need
to check on every setup of a DMA transfer.
- Let the bus DMA map callbacks do nothing in case of an error.
- Correctly handle > 64k transfers for FAS366 in the LSI64854. A new feature
flag NCR_F_LARGEXFER was introduced so we just need to check for this one
and not for individual controllers supporting large transfers in several
places.
- Let the LSI64854 core load transfer buffers using BUS_DMA_NOWAIT as the
NCR53C9x core can't handle EINPROGRESS. Due to lack of bounce buffers
support, sparc64 doesn't actually use EINPROGRESS and likely never will,
as an example for writing additional front-ends for the NCR53C9x core it
makes sense to set BUS_DMA_NOWAIT anyway though.
- Some minor cleanup.
marius [Sun, 6 Nov 2011 21:09:10 +0000 (21:09 +0000)]
MFC: r226995, r227042
- Import the common MII bitbang'ing code from NetBSD and convert drivers to
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 8k. The only potential in-tree users left
unconverted are ed(4) and xe(4). Xe(4) generally should be changed to use
miibus(4) instead of implementing PHY handling on its own, as otherwise it
makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to it
just for the MII bitbang'ing code. Ed(4) has some chip specific things
interwinded with the MII bitbang'ing code and it's unclear whether it can
be converted to common code, at least not without thorough testing of all
the various chips supported by ed(4).
The common MII bitbang'ing code also is useful in the embedded space for
using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.
Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).
Reviewed by: yongari (subset of drivers)
Approved by: re (kib)
Obtained from: NetBSD (partially)
Always use the opt_*.h options for ipfw.ko, not just when
compiled into the kernel.
Do not try to build the module in case of no INET support but
keep #error calls for now in case we would compile it into the
kernel.
This should fix an issue where the module would fail to enable
IPv6 support from the rc framework, but also other INET and INET6
parts being silently compiled out without giving a warning in the
module case.
While here garbage collect unneeded opt_*.h includes.
opt_ipdn.h is not used anywhere but we need to leave the DUMMYNET
entry in options for conditional inclusion in kernel so keep the
file with the same name.
marius [Sun, 6 Nov 2011 17:25:22 +0000 (17:25 +0000)]
MFC: r227001
Increase the IOC port initialization timeouts by ten times to what the
corresponding Linux driver uses. This allows mpt(4) to still recognize
all good SATA devices in presence of a defective one, which takes about
45 seconds.
In the long term we probably should implement the logic used by mpt2sas(4)
allowing IOC port initialization to complete at a later time.
marius [Sun, 6 Nov 2011 17:23:49 +0000 (17:23 +0000)]
MFC: r226154, r226165
- Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY
drivers that only ever attach to a particular MAC driver, i.e. inphy(4),
ruephy(4) and xlphy(4), to the directory where the respective MAC driver
lives and only compile it into the kernel when the latter is also there,
also removing it from miibus.ko and moving it into the module of the
respective MAC driver.
- While at it, rename exphy.c, which comes from NetBSD where the MAC driver
it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD
actually identifies itself as xlphy(4), and its function names accordingly
for consistency.
- Additionally while at it, fix some minor style issues like whitespace
in the register headers and add multi-inclusion protection to inphyreg.h.
mav [Sun, 6 Nov 2011 16:54:23 +0000 (16:54 +0000)]
MFC r226985:
Workaround the problem introduced by combination of r162200 and r215687.
r162200 delays provider orphanization until all running requests complete,
to workaround broken orphan() method implementation in some classes.
r215687 removes persistent periodic (10Hz) event thread wake ups.
Together these changes can indefinitely delay orphanization until some
other event wake up the event thread. One consequence of this is inability
of CAM to destroy device disconnected when busy and, as consequence, create
new one after reconnection.
While the best solution would be to revert r162200, it is not easy, as
some classes still broken in that way. Instead conditionally wake up event
thread if there are some providers waiting for orphanization.
nwhitehorn [Sun, 6 Nov 2011 16:37:50 +0000 (16:37 +0000)]
MFC r226666,226739,226741:
Avoid showing the user some spurious error messages from GEOM [1] and do
provide error messages instead of silent failure if there are no disks
or no network interfaces in the system [2].
PR: bin/161926 [1], bin/161926 [2]
Approved by: re (kib)
dougb [Sun, 6 Nov 2011 07:47:38 +0000 (07:47 +0000)]
MFC r227013:
1. Add a new option, --run-updates, to always or never run the newalises,
pwd_mkdb, etc. updates at the end of the comparison.
2. Add an update to the end to handle /etc/localtime, if it exists.
If /var/db/zoneinfo exists, automatically update /etc/localtime,
which should (hopefully) be safe to do. If not, prompt the user
to run tzsetup.
3. Update run_it_now(), the function that handles input for the updates,
to make sure that we got a valid answer, and to handle the --run-updates
option if supplied.
dougb [Sun, 6 Nov 2011 07:35:08 +0000 (07:35 +0000)]
MFC r227011:
If the user is moving from any other time zone to UTC we need
to delete any old /var/db/zoneinfo file that may exist so that
tzsetup -r does the right thing.
dougb [Sun, 6 Nov 2011 07:02:13 +0000 (07:02 +0000)]
MFC r226898:
Fix the text and attribution of the poem "Youth" by Samuel Ullman.
Our copy was a bastardization of the "older" (probably original?) and
shorter version of the poem; and the "newer" version that is better
known, and arguably more popular. Standardize on the latter.
obrien [Sun, 6 Nov 2011 02:10:40 +0000 (02:10 +0000)]
MFC: r226702
* Don't give the impression that this compiler is GPLv3.
(It is "well known" that GCC 4.2.2 is GPLv3.)
* Don't give the impression that this compiler isn't "trustable".
* Fix dependency nit.
kib [Sat, 5 Nov 2011 18:27:47 +0000 (18:27 +0000)]
MFC r226896:
Fix an implicit dependency between the MFI driver and CAM that had grown due
to an API change in CAM. It's once again possible to link a static kernel
with 'mfi' without requiring 'scbus' as well. Ditto for KLD loading.
MFC r226880:
Our geom withering function could take some time before geom with its
providers and consumers will be destroyed. Before take some actions
with a geom, check that it is not destroyed at the moment.
dim [Wed, 2 Nov 2011 18:55:26 +0000 (18:55 +0000)]
MFC r226951:
Pull in r143305 and r143312 from upstream clang trunk, so using "clang
-march=native" on AMD K10 family processors no longer errors out with
"unknown target CPU 'amdfam10'". This also enables use of SSE4A.
Reported by: David Marec <david.marec@davenulle.org>
Approved by: re (kib)
gavin [Wed, 2 Nov 2011 13:51:29 +0000 (13:51 +0000)]
Merge r226860 from head:
Update the example rules in devfs.conf to reflect the changes since
ATA_CAM. While here, add another example rule, as many applications
these days expect to find /dev/dvd instead.
qingli [Tue, 1 Nov 2011 22:22:46 +0000 (22:22 +0000)]
MFC 226710
The host-id/interface-id can have a specific value and is properly
masked out when adding a prefix route through the "route" command.
However, when deleting the route, simply changing the command keyword
from "add" to "delete" does not work. The failoure is observed in
both IPv4 and IPv6 route insertion. The patch makes the route command
behavior consistent between the "add" and the "delete" operation.
qingli [Tue, 1 Nov 2011 21:21:36 +0000 (21:21 +0000)]
MFC 226451
The IPv6 code was influx at the time of r196865 due to the L2/L3
separation rewrite changes. r196865 was committed to fix a scope
violation problem in the following test scenario:
qingli [Tue, 1 Nov 2011 18:29:06 +0000 (18:29 +0000)]
MFC 226713
Exclude host routes when checking for prefix coverage on multiple
interfaces. A host route has a NULL mask so check for that condition.
I have also been told by developers who customize the packet output
path with direct manipulation of the route entry (or the outgoing
interface to be specific). This patch checks for the route mask
explicitly to make sure custom code will not panic.
kib [Tue, 1 Nov 2011 15:41:55 +0000 (15:41 +0000)]
MFC r226688:
The use of VOP_ISLOCKED() without a check for the return values can cause
false positives. Replace the #ifdef block with the proper
ASSERT_VOP_UNLOCKED() assert.
kib [Tue, 1 Nov 2011 15:38:41 +0000 (15:38 +0000)]
MFC r226687:
The only possible error return from null_nodeget() is due to insmntque1
failure (the getnewvnode cannot return an error). In this case, the
null_insmntque_dtr() already unlocked the reclaimed vnode, so VOP_UNLOCK()
in the nullfs_mount() after null_nodeget() failure is wrong.
kib [Tue, 1 Nov 2011 15:34:52 +0000 (15:34 +0000)]
MFC r226686:
The covered vnode must be reloced if it was unlocked. Remove VOP_ISLOCKED
test because of this and also because it can lead to false positives.
marcel [Mon, 31 Oct 2011 03:47:23 +0000 (03:47 +0000)]
MFC r226647:
Add support for Boot Camp. The support is defined as follows:
o Detect when Boot Camp is enabled (i.e. the MBR mirrors the GPT).
o When Boot Camp is enabled, update the MBR whenever we write the GPT.
o Creation of a Boot Camp enabled GPT is not supported.
o Automatically disable Boot Camp when the GPT has been changed so that
there's either no EFI partition or no HFS+ partition.
o The first 4 partitions (by index) get mirrored in the MBR.
Requested by, discussed with and tested by: kris@pcbsd.org
Approved by: re (bz@, kib@)
mm [Sun, 30 Oct 2011 20:56:54 +0000 (20:56 +0000)]
MFC r226724, r226732:
MFC r226724:
Update copyright information in several ZFS files, as the clause 3.3
of the CDDL licence explicitly requires every Contributor to add
a copyright notice.
This also reflects the copyright notices for the changes recently
added by Illumos.
MFC r226732: [1]
Fix typo in copyright notice introduced in r226724
(missing character in e-mail adress)
marcel [Sat, 29 Oct 2011 16:38:04 +0000 (16:38 +0000)]
MFC r226673:
Don't terminate the interactive root mount prompt on mount failure.
This restores the previous behaviour. While here, match '?' and '.'
inputs exactly and improve the error message.
Requested by: avg@
Derived from a patch by: Arnaud Lacombe <lacombar@gmail.com>
Approved by: re (kib@)
hselasky [Sat, 29 Oct 2011 12:39:05 +0000 (12:39 +0000)]
MFC r226803:
Fix suspend and resume of non-super-speed USB devices
in the generic XHCI driver. There appears to be some minor
logic missing for this feature to work.
dim [Fri, 28 Oct 2011 21:08:39 +0000 (21:08 +0000)]
MFC r226633:
Upgrade our copy of llvm/clang to r142614, from upstream's release_30
branch. This brings us very close to the 3.0 release, which is expected
November 16, 2011.
kensmith [Wed, 26 Oct 2011 19:45:20 +0000 (19:45 +0000)]
MFC r226510,r226547:
Comment out sbp(4) because it appears to cause boot failure on some
systems. Add comment explaining why sbp(4) is commented out.
It was a mistake on my part to omit powerpc's GENERIC for r226510.
But when I noticed the mistake I checked with the powerpc maintainer
to see if I should correct the mistake Marcel said he'd prefer it be
left as-is.
Pseudo interfaces should go at SI_SUB_PSEUDO. However at least
pfsync also depends on pf to be initialized already so pf goes at
FIRST and the interfaces go at ANY.
Then the (VNET_)SYSINIT startups for pf stays at SI_SUB_PROTO_BEGIN
and for pfsync we move to the later SI_SUB_PROTO_IF.
This is not ideal either but at least an order that should work for
the moment and can be re-fined with the VIMAGE merge, once this will
actually work with more than one network stack.
Fix recursive pf locking leading to panics. Splatter PF_LOCK_ASSERT()s
to document where we are expecting to be called with a lock held to
more easily catch unnoticed code paths.
This does not neccessarily improve locking in pfsync, it just tries
to avoid the panics reported.
PR: kern/159390, kern/158873
Submitted by: pluknet (at least something that partly resembles
my patch ignoring other cleanup, which I only saw
too late on the 2nd PR)
Fix a race: we should update sc_len before dropping the pf lock, otherwise a
number of packets can be queued on sc, while we are in ip_output(), and then
we wipe the accumulated sc_len. On next pfsync_sendout() that would lead to
writing beyond our mbuf cluster.
Fix from r226623 is not sufficient to close all races in pfsync(4).
The root of problem is re-locking at the end of pfsync_sendout().
Several functions are calling pfsync_sendout() holding pointers
to pf data on stack, and these functions expect this data to be
consistent.
To fix this, the following approach was taken:
- The pfsync_sendout() doesn't call ip_output() directly, but
enqueues the mbuf on sc->sc_ifp's interfaces queue, that
is currently unused. Then pfsync netisr is scheduled. PF_LOCK
isn't dropped in pfsync_sendout().
- The netisr runs through queue and ip_output()s packets
on it.
Apart from fixing race, this also decouples stack, fixing
potential issues, that may happen, when sending pfsync(4)
packets on input path.
- Fix a bad typo (FreeBSD specific) in pfsync_bulk_update(). Instead
of scheduling next run pfsync_bulk_update(), pfsync_bulk_fail()
was scheduled.
This lead to instant 100% state leak after first bulk update
request.
- After above fix, it appeared that pfsync_bulk_update() lacks
locking. To fix this, sc_bulk_tmo callout was converted to an
mtx one. Eventually, all pf/pfsync callouts should be converted
to mtx version, since it isn't possible to stop or drain a
non-mtx callout without risk of race.
- Add comment that callout_stop() in pfsync_clone_destroy() lacks
locking. Since pfsync0 can't be destroyed (yet), let it be here.
Merge several fixes to bulk update processing from OpenBSD. Merged
revisions: 1.148, 1.149, 1.150. This makes number of states on
master/slave to be of a sane value.
rodrigc [Wed, 26 Oct 2011 17:04:26 +0000 (17:04 +0000)]
Add a "kern.features.ata_cam" sysctl in the kernel when the ATA_CAM kernel
option is defined. This sysctl can be queried by feature_present(3).
Query for this feature in /sbin/atacontrol and /usr/sbin/burncd.
If these utilities detect that ATA_CAM is enabled, then these utilities
will error out. These utilities are compatible with the old ATA
driver, but are incomptible with the new ATA_CAM driver. By erroring out,
we give end-users an idea as to what remedies to use, and reduce the need for them
to file PR's. For atacontrol, camcontrol must be used instead,
and for burncd, alternative utilties from the ports collection must be used
such as sysutils/cdrtools.
In future, maybe someone can re-write burncd to work with ATA_CAM,
but at least for now, we give a somewhat useful error message to end users.
PR: 160979
Reviewed by: jh, Arnaud Lacombe <lacombar at gmail dot com>
Approved by: re (kib)
Reported by: Joe Barbish <fbsd8 at a1poweruser dot com>
edwin [Wed, 26 Oct 2011 06:50:40 +0000 (06:50 +0000)]
MFC of r226752, r226771, tzdata2011m
Europe:
- Pridnestrovian Moldavian Republic (PMR, also known as
"Pridnestrovie") has abolished seasonal clock change (no transition
to the Winter Time).
- The recent change to the Ukranian time zone (Europe/Kiev) to
introduce permanent daylight saving time (similar to Russia) was
reverted.
South America:
- Bahia: The President signed a decree that includes Bahia in summer
time.
zone.tab:
- Add Europe/Tiraspol Pridnestrovie
Obtained from: ftp://ftp.iana.org/tz/releases/
Approved by: re (Kostik Belousov)
mckusick [Fri, 21 Oct 2011 22:12:24 +0000 (22:12 +0000)]
MFC: 226265
When unmounting a filesystem always wait for the vfs_busy lock to clear
so that if no vnodes in the filesystem are actively in use the unmount
will succeed rather than failing with EBUSY.
Reported by: Garrett Cooper
Reviewed by: Attilio Rao and Kostik Belousov
Tested by: Garrett Cooper
Approved by: re (kib)
PR: kern/161016
mckusick [Fri, 21 Oct 2011 22:07:52 +0000 (22:07 +0000)]
MFC 226266:
After creating a filesystem using newfs -j the time stamps are all
zero and thus report as having been made in January 1970. Apart
from looking a bit silly, it also triggers alarms from scripts
that detect weird time stamps. This update sets all 4 (or 3, in
the case of UFS1) time stamps to the current time when enabling
journaling during newfs or later when enabling it with tunefs.
Reported by: Hans Ottevanger <hans@beastielabs.net>
Approved by: re (kib)
trociny [Fri, 21 Oct 2011 05:37:40 +0000 (05:37 +0000)]
MFC r226403:
In r225809 the intention was to send VEOF only once if STDIN was not a
terminal. Unfortunately the fix was incorrect and for flushtime > 0 it
keept sending VEOF.
Sent VEOF generates ^D\b\b echoed by the terminal, which was reported
in bin/161526. Note, we still send VEOF at least once. Otherwise
commands like below would hang forever:
echo 1 |script /tmp/script.out cat
PR: bin/161526
Reported by: Adrian Wontroba <aw1@stade.co.uk>, Stefan Bethke <stb@lassitu.de>
Tested by: Stefan Bethke <stb@lassitu.de>
Approved by: re (kib)
delphij [Thu, 20 Oct 2011 20:31:09 +0000 (20:31 +0000)]
MFC r226483:
Fix a bug in sa_find_sizes() which could lead to panic:
When calculating space needed for SA_BONUS buffers,
hdrsize is always rounded up to next 8-aligned boundary.
However, in two places the round up was done against
sum of 'total' plus hdrsize. On the other hand,
hdrsize increments by 4 each time, which means in
certain conditions, we would end up returning with
will_spill == 0 and (total + hdrsize) larger than
full_space, leading to a failed assertion because
it's invalid for dmu_set_bonus.
Sponsored by: iXsystems, Inc.
Reviewed by: mm
Approved by: re (kib)
gabor [Thu, 20 Oct 2011 16:08:11 +0000 (16:08 +0000)]
MFC r226432, r226273:
- Use getprogname() instead of __progname
- Allow disabling bzip2 support with WITHOUT_BZIP2
- Fix handling patterns that start with a dot
- Remove superfluous semicolon
- Fix counting of match limit (-m)
glebius [Thu, 20 Oct 2011 15:58:05 +0000 (15:58 +0000)]
MFhead 226401,226402:
Remove last remnants of classful addressing:
- Remove ia_net, ia_netmask, ia_netbroadcast from struct in_ifaddr.
- Remove net.inet.ip.subnetsarelocal, I bet no one need it in 2011.
- fix bug when we were not forwarding to a host which matches classful
net address. For example router having 192.168.x.y/16 network attached,
would not forward traffic to 192.168.*.0, which are legal IPs in
CIDR world.
- For compatibility, leave autoguessing of mask based on class.
Reviewed by: andre, bz, rwatson
Add support for IPv4 /31 prefixes, as described in RFC3021.
To run a /31 network, participating hosts MUST drop support
for directed broadcasts, and treat the first and last addresses
on subnet as unicast. The broadcast address for the prefix
should be the link local broadcast address, INADDR_BROADCAST.
glebius [Thu, 20 Oct 2011 15:53:26 +0000 (15:53 +0000)]
MFhead r226338:
Restore functions in6_ifaddloop() and in6_ifremloop() that were
inlined by Qing Li in his big new-ARP commit. I am going to utilize
them in my newcarp work, and also these functions left declared
in in6_var.h for all the time they were absent.
kensmith [Tue, 18 Oct 2011 13:48:31 +0000 (13:48 +0000)]
MFC r226507:
> Escape the newline so we get a proper line continuation. Without this
> the text of the menu selections doesn't get displayed properly and it
> makes the installer appear to lock up for no obvious reason.
>
> Reviewed by: nwhitehorn
Insta-MFC being done because 9.0-RC1 builds are being held for this.
qingli [Mon, 17 Oct 2011 03:35:24 +0000 (03:35 +0000)]
MFC 226453
The code change made in r226040 was incomplete and resulted in
routes such as fe80::1%lo0 no being installed. This patch completes
the original intended fix.