gjb [Wed, 25 Dec 2013 06:09:07 +0000 (06:09 +0000)]
MFC r259729:
Bootstrap etcupdate(8) as part of the release build, similar
to what is done for mergemaster(8). This allows etcupdate(8)
to work out-of-box after the first upgrade of a system.
dim [Wed, 25 Dec 2013 00:53:48 +0000 (00:53 +0000)]
MFC r259740:
In usr.bin/sort/radixsort.c, pop_ls_mt() is only referenced if
SORT_THREADS is defined, so make the whole function conditional, instead
of just the pthread calls in it.
jhb [Tue, 24 Dec 2013 19:10:56 +0000 (19:10 +0000)]
MFC 259013:
Fix the processor table entry structure to use a fixed-width type for
32-bit fields so it is the correct size on amd64. Remove a workaround
for the broken structure from bhyve(8).
jhb [Tue, 24 Dec 2013 19:01:08 +0000 (19:01 +0000)]
MFC 258869:
Fix an off-by-one error in r228960. The maximum priority delta provided
by SCHED_PRI_TICKS should be SCHED_PRI_RANGE - 1 so that the resulting
priority value (before nice adjustment) is between SCHED_PRI_MIN and
SCHED_PRI_MAX, inclusive.
kib [Tue, 24 Dec 2013 07:32:06 +0000 (07:32 +0000)]
MFC r259522:
If vn_open_vnode() succeeded in opening the vnode, but subsequent
advisory lock cannot be obtained, prevent double-close of the vnode in
vn_close() called from the fdrop(), by resetting file' f_ops methods.
np [Tue, 24 Dec 2013 02:10:12 +0000 (02:10 +0000)]
MFC r259527:
Do not create a hardware IPv6 server if the listen address is not
in6addr_any and is not in the CLIP table either. This fixes a reported
TOE+IPv6 NULL-dereference panic in do_pass_open_rpl().
While here, stop creating hardware servers for any loopback address.
It's just a waste of server tids.
imp [Mon, 23 Dec 2013 01:24:32 +0000 (01:24 +0000)]
MFC r259685:
Plumb the cn_grab and cn_ungrab routines down into the uart
clients. Mask RX interrupts while grabbed on the atmel serial
driver. This UART interrupts every character. When interrupts are
enabled at the mountroot> prompt, this means the ISR eats the
characters. Rather than try to create a cooperative buffering system
for the low level kernel console, instead just mask out the ISR. For
NS8250 and decsendents this isn't needed, since interrupts only happen
after 14 or more characters (depending on the fifo settings). Plumb
such that these are optional so there's no change in behavior for all
the other UART clients. ddb worked on this platform because all
interrupts were disabled while it was running, so this problem wasn't
noticed. The mountroot> issue has been around for a very very long
time.
dumbbell [Sun, 22 Dec 2013 21:53:08 +0000 (21:53 +0000)]
MFC r259717:
drm: Lower priority of "EDID checksum is invalid" message
The priority goes from "error" to "debug".
Connectors are polled every 10 seconds. Reading EDID is part of this
polling. However, when an invalid EDID is returned, this error message
is logged. When using Newcons for instance, having a kernel message
every 10 seconds is getting annoying.
Now that it's a debug message, it'll be logged only if hw.dri.debug is
enabled. This fix console spamming for some users.
dumbbell [Sun, 22 Dec 2013 21:18:21 +0000 (21:18 +0000)]
MFC r259684:
drm/ttm, drm/radeon: Replace EINTR/ERESTART by ERESTARTSYS...
... for msleep/cv_*wait() return values, where wait_event*() is used
on Linux. ERESTARTSYS is the return code expected by callers when the
operation was interrupted.
For instance, this is the case of radeon_cs_ioctl() (radeon_cs.c): if
an error occurs, and the code isn't ERESTARTSYS (eg. EINTR), it logs an
error.
Note that ERESTARTSYS is defined as ERESTART, but this keeps callers'
code close to Linux.
dumbbell [Sun, 22 Dec 2013 21:09:43 +0000 (21:09 +0000)]
MFC r259679:
vga_pci: Improve boot display detection
The previous code was checking the "VGA Enable" bit on the video card's
parent PCI-to-PCI bridge only. This didn't work for the case where the
video card is attached to the root PCI bus (ie. the card has no parent
PCI-to-PCI bridge).
Now, the new code:
1. checks the "VGA Enable" bit on the parent bridge only if it's a
PCI-to-PCI bridge;
2. always checks the "I/O" and "Memory address space decoding" bits
on the video card itself.
However, vendor-specific bits are not used.
This fixes the use of many integrated Radeon cards: without this patch,
we fail to detect them as the boot display and, when radeonkms looks for
the Video BIOS, it skips the shadow copy made by the System BIOS. It
then fails to fully initialize the card, because the shadow copy is the
only way to read the Video BIOS in these situations. A workaround was to
force the boot display selection using the "hw.pci.default_vgapci_unit"
tunable.
A previous version of this patch added a new function doing the checks.
Now, the vga_pci_is_boot_display() function is used to perform the
checks (only until the boot display is found) and return if the given
device is the boot display or not.
Furthermore, vga_pci_attach() logs "Boot video device" if the card being
attached it the Chosen One:
vgapci0: <VGA-compatible display> [...]
vgapci0: Boot video device
mav [Sun, 22 Dec 2013 13:02:34 +0000 (13:02 +0000)]
MFC r259108:
When comparing device IDs, make sure that they have the same type
(like NAA assigned) and identify the same entity (like device or port).
Otherwise there can be false positives since at least some models of
Seagate disks use same IDs for the whole device and one of its ports.
dteske [Thu, 19 Dec 2013 18:52:41 +0000 (18:52 +0000)]
MFC r259276,259468-259470,259472,259474,259476-259478,259480-259481,259570,
259572, and 259597-259598...
r259276: Fix bug in `services' script in adding dumpdev comment to rc.conf
r259468: Ignore spurious escape generated by VMware's Ctrl-Cmd combination
r259469: Mask errors in `config' script from newaliases(1) about non-FQHN
r259470: Set atime=on for /var/mail zfsboot dataset to support mail server
r259472: Accept NULL input for zfsboot SWAP to indicate SWAP of zero bytes
r259474: Multiple changes, including bug-fixes and debugging improvements
r259476: Change default ZFS disk layout, making it easier to resize
r259477: fletcher4 is now the default (zfsboot related)
r259478: De-uglify the geli(8)-setup infobox (zfsboot related)
r259480: Fix ghosted zroot issue by always performing labelclear on swap
r259481: Auto-enable 4k sector alignmet when geli(8) is enabled (zfsboot)
r259570: Fix numerical comparison error (zfsboot)
r259572: Mask spurious rm error in bsdinstall_log from `auto' script
r259597: Fix zfsboot regression when installing to 3+ disks
r259598: Set cachefile property of bootpool so it imports to new system
bdrewery [Thu, 19 Dec 2013 12:33:24 +0000 (12:33 +0000)]
MFC r259266:
Fix multi-repository support by properly respecting 'enabled' flag.
This will read the REPOS_DIR env/config setting (default is /etc/pkg
and /usr/local/etc/pkg/repos) and use the last enabled repository.
This can be changed in the environment using a comma-separated list,
or in /usr/local/etc/pkg.conf with JSON array syntax of:
REPOS_DIR: ["/etc/pkg", "/usr/local/etc/pkg/repos"]
hselasky [Thu, 19 Dec 2013 07:20:37 +0000 (07:20 +0000)]
MFC r259248 and r259462:
Set chain bit correctly. This will fix some problems sending and
receiving Zero Length Packets, ZLPs. See comment in code for more
information.
truckman [Thu, 19 Dec 2013 07:12:34 +0000 (07:12 +0000)]
MFC r258629, 258662:
r258629:
Mention that devd will kldload the driver when the device is connected.
Mention that the automatic mode switch from umass to u3g needed by some
devices does not work unless the driver is loaded before the device is
connected.
pfg [Wed, 18 Dec 2013 19:07:29 +0000 (19:07 +0000)]
MFC r258428, r258445
gcc: another round of merges from the gcc pre-43 branch.
Bring The following revisions from the gcc43 branch[1]:
118360, 118361, 118363, 118576, 119820,
123906, 125246, and 125721.
They all have in common that the were merged long ago
into Apple's gcc and should help improve the general
quality of the compiler and make it easier to bring
new features from Apple's gcc42.
For details please review the additions to the files:
gcc/ChangeLog.gcc43
gcc/cp/ChangeLog.gcc43 (new, adds previous revisions)
Fix crosscompilation (r258445 by andreast)
Reference:
[1] http://gcc.gnu.org/viewcvs/gcc/trunk/?pathrev=126700
gjb [Wed, 18 Dec 2013 01:14:25 +0000 (01:14 +0000)]
MFC r259426, r259427:
r259426:
Add a pkg(8) repository configuration file for cdrom-based package
installation.
As part of the 'pkg-stage' target, copy the configuration file
to the 'packages/repos/' directory on the DVD filesystem.
r259427:
Export 'REPOS_DIR' when the selected source medium for package
installation is cdrom. This enables bsdconfig(8) to make use
of the on-disc pkg(8) repository configuration, which fixes
package selection and installation from the dvd installer.
gjb [Tue, 17 Dec 2013 03:46:44 +0000 (03:46 +0000)]
MFC r259246:
Prevent release build errors found during snapshot builds where if
NOPORTS=1, pkg-stage.sh cannot build the ports-mgmt/pkg port if
WITH_DVD=1.
asomers [Mon, 16 Dec 2013 19:59:34 +0000 (19:59 +0000)]
MFC r258311
opensolaris/uts/common/dtrace/fasttrap.c
Fix several problems that can cause panics on kldload and kldunload.
* kproc_create(fasttrap_pid_cleanup_cb, ...) gets called before
fasttrap_provs.fth_table gets allocated. This can lead to a panic
on module load, because fasttrap_pid_cleanup_cb references
fasttrap_provs.fth_table. Move kproc_create down after the point
that fasttrap_provs.fth_table gets allocated, and modify the error
handling accordingly.
* dtrace_fasttrap_{fork,exec,exit} weren't getting NULLed until
after fasttrap_provs.fth_table got freed. That caused panics on
module unload because fasttrap_exec_exit calls
fasttrap_provider_retire, which references
fasttrap_provs.fth_table. NULL those function pointers earlier.
* There wasn't any code to destroy the
fasttrap_{tpoints,provs,procs}.fth_table mutexes on module unload,
leading to a resource leak when WITNESS is enabled. Destroy those
mutexes during fasttrap_unload().
nwhitehorn [Mon, 16 Dec 2013 15:00:06 +0000 (15:00 +0000)]
MFC r258819,258928:
Add new sysctl, kern.supported_archs, containing the list of FreeBSD
MACHINE_ARCH values whose binaries this kernel can run. This patch provides
a feature requested for implementing pkgng ABI identifiers in a robust
way.
The list is designed to indicate whether, say, an i386 package can be run on
the current system. If kern.supported_abis contains "i386", then the answer
is yes. Otherwise, the answer is no.
At the moment, this only supports MACHINE_ARCH and MACHINE_ARCH32. As we
gain support for more interesting combinations, this needs to become more
flexible, possibily through the sysent framework, along with the
hw.machine_arch emulation immediately preceding this code in kern_mib.c.
hselasky [Mon, 16 Dec 2013 09:48:08 +0000 (09:48 +0000)]
MFC r256718, r257410 and r257411:
- Fix RF registers for RT3070.
- Initialize BBP68 to improve RX sensitivity.
- Add RT2860_BCN_OFFSET1 and RT2860_MAX_LEN_CFG register initialization to
match with the vendor driver. While here, remove unused RT2860_DEF_MAC
definition.
bjk [Mon, 16 Dec 2013 02:04:28 +0000 (02:04 +0000)]
MFC r259286,259424,259425:
Apply patch from upstream Heimdal for encoding fix
RFC 4402 specifies the implementation of the gss_pseudo_random()
function for the krb5 mechanism (and the C bindings therein).
The implementation uses a PRF+ function that concatenates the output
of individual krb5 pseudo-random operations produced with a counter
and seed. The original implementation of this function in Heimdal
incorrectly encoded the counter as a little-endian integer, but the
RFC specifies the counter encoding as big-endian. The implementation
initializes the counter to zero, so the first block of output (16 octets,
for the modern AES enctypes 17 and 18) is unchanged. (RFC 4402 specifies
that the counter should begin at 1, but both existing implementations
begin with zero and it looks like the standard will be re-issued, with
test vectors, to begin at zero.)
This is upstream's commit f85652af868e64811f2b32b815d4198e7f9017f6,
from 13 October, 2013:
% Fix krb5's gss_pseudo_random() (n is big-endian)
%
% The first enctype RFC3961 prf output length's bytes are correct because
% the little- and big-endian representations of unsigned zero are the
% same. The second block of output was wrong because the counter was not
% being encoded as big-endian.
%
% This change could break applications. But those applications would not
% have been interoperating with other implementations anyways (in
% particular: MIT's).
Bump __FreeBSD_version accordingly and add a note in UPDATING.
pfg [Sun, 15 Dec 2013 03:47:31 +0000 (03:47 +0000)]
MFC rr258501, r258507;
gcc: Bring updates from Google's enhanced gcc-4.2.1.
Google released and enhanced version of gcc-4.2.1 plus their local
patches for Android[1].
The patches are owned by Google and the license hasn't been changed
from the original GPLv2. We are only bringing a subset of the
available patches that may be helpful in FreeBSD, in other words,
changes specific to android are not included.
From the README.google file[1].
Patches applied to google_vendor_src_branch/gcc/gcc-4.2.1:
Backport of -Wstrict-aliasing from mainline.
Silvius Rus <rus@google.com>
gcc/coverage.c:
Patch coverage_checksum_string for PR 25351.
Seongbae Park <spark@google.com>
Not yet submitted to FSF.
gcc/c-opts.c
gcc/c-ppoutput.c
gcc/c.opt
gcc/doc/cppopts.texi
libcpp/Makefile.in
libcpp/directives-only.c
libcpp/directives.c
libcpp/files.c
libcpp/include/cpplib.h
libcpp/init.c
libcpp/internal.h
libcpp/macro.c
Support for -fdirectives-only.
Ollie Wild <aaw@google.com>.
Submitted to FSF but not yet approved.
libstdc++-v3/include/ext/hashtable.h
http://b/742065
http://b/629994
Reduce min size of hashtable for hash_map, hash_set from 53 to 5
libstdc++-v3/include/ext/hashtable.h
http://b/629994
Do not iterate over buckets if hashtable is empty.
gcc/common.opt
gcc/doc/invoke.texi
gcc/final.c
gcc/flags.h
gcc/opts.c
gcc/testsuite/gcc.dg/Wframe-larger-than.c
Add a new flag -Wframe-larger-than- which enables a new warning
when a frame size of a function is larger than specified.
This patch hasn't been integrated into gcc mainline yet.
gcc/tree-vrp.c
Add a hack to avoid using ivopts information for pointers starting
at constant values.
gjb [Sat, 14 Dec 2013 20:55:53 +0000 (20:55 +0000)]
MFC r259113, r259115, r259144, r259148:
r259113 (dteske):
Fix failed attempt to send pkg(8) stderr to /dev/null
r259115 (dteske):
Prevent truncating /tmp/bsdinstall_log each time we
exec a module.
r259144 (dteske):
Fix a regression after successfully installing to encrypted
ZFS root, the passphrase is not accepted and a message about
"incorrect key" is displayed.
r259148 (dteske):
Fix a regression resulting in mountroot prompt after attempting
to install to encrypted ZFS root (caused by a typo in a
variable name -- ZFSBOOT_BOOT_FSNAME -> ZFSBOOT_BOOTFS_NAME).
ian [Sat, 14 Dec 2013 01:35:57 +0000 (01:35 +0000)]
MFC r259212, r259220:
Fix one race and one fence post error. When the TX buffer was
completely full, we'd not complete any of the mbufs due to the fence
post error (this creates a large leak). When this is fixed, we still
leak, but at a much smaller rate due to a race between ateintr and
atestart_locked as well as an asymmetry where atestart_locked is
called from elsewhere. Ensure that we free in-flight packets that
have completed there as well. Also remove needless check for NULL on
mb, checked earlier in the loop and simplify a redundant if.
ian [Sat, 14 Dec 2013 01:34:24 +0000 (01:34 +0000)]
MFC r259038, r259039:
Bump the maximum VM space from 3 * memory size to a fixed
256MB. That's all we have room for since we map the hardware registers
starting at 0xd0000000. This allows my 64MB AT91SAM9G20 to boot again
after the unmmaped I/O changes were MFC'd at r251897. Other
subplatforms may need similar treatment.
Although not strictly required to boot a 64MB board, bump
vm_max_virtual_address to be KERNVIRTADDR + 256MB. This allows some
future shock protection since the KVA requirements have gone up since
the unmapped changes have gone in, as well as preventing us from
overlapping with the hardware devices, which we map at 0xd0000000,
which we'd hit with anything more than 85MB...
ian [Sat, 14 Dec 2013 01:12:13 +0000 (01:12 +0000)]
MFC r258392, r258412:
Call cpu_setup() immediately after the page tables are installed. This
enables data cache and other chip-specific features. It was previously
done via an early SYSINIT, but it was being done after pmap and vm setup,
and those setups need to use mutexes. On some modern ARM platforms,
the ldrex/strex instructions that implement mutexes require the data cache
to be enabled.
Call cpu_setup() from the initarm() routine on platforms that don't use
the common FDT-aware initarm() in arm/machdep.c.
ian [Sat, 14 Dec 2013 00:58:13 +0000 (00:58 +0000)]
MFC r258356:
Bugfixes... the host capabilties from FDT data are stored in host.caps, not
host.host_ocr, examine the correct field when setting up the hardware. Also,
the offset for the capabilties register should be 0x140, not 0x240.
ian [Sat, 14 Dec 2013 00:55:34 +0000 (00:55 +0000)]
MFC r258740:
Look up a nand chip by id in the static table before trying to obtain
ONFI parameters. This allows a static table entry to provide valid data
for chips known to provide invalid ONFI data.
Add Micron chip found in Freescale Vybrid Family Phytec COSMIC board.
The vendor specified field is 88 bytes, not 8 bytes.
Update the onfi_params struct to ONFI revision 3.2 (06 12 2013).
Search for and validate the ONFI params as specified in the standard.
ONFI parameters are little-endian, hence we must take care to convert them
to native endianness. We must also pay attention to unaligned accesses.
Rework the routine that returns a pointer to the table of software ECC
byte positions within the OOB area to support chips with unusual OOB
sizes such as 218 or 224 bytes.
ian [Sat, 14 Dec 2013 00:25:57 +0000 (00:25 +0000)]
MFC r258076, r258077:
This fixes 3 problems in syslogd related to sizing receive buffers...
- A call was misplaced at the wrong level of nested if blocks, so that
the buffers for unix domain sockets (/dev/log, /dev/klog) were never
increased at all; they remained at a way-too-small default size of 4096.
- The function that was supposed to double the size of the buffer
sometimes did nothing, and sometimes installed a wildly-wrong buffer
size (either too large or too small) due to an unitialized 'slen'
variable passed to getsockopt(). Most often it doubled the UDP buffers
from 40k to 80k because accidentally there would be harmless stack
garbage in the unitialized variables.
- The whole concept of blindly doubling a socket's buffer size without
knowing what size it started at is a design flaw that has to be called a
bug. If the double_rbuf() function had worked at all (I.E., if the
other two bugs didn't exist) this would lead to UDP sockets having an
80k buffer while unix dgram sockets get an 8k buffer. There's nothing
about the problem being solved that requires larger buffers for UDP than
for unix dgram sockets -- the buffering requirements are the same
regardless of socket type.
This change renames the double_rbuf() function to increase_rbuf() and
increases the buffer size on all types of sockets to 80k. 80k was
chosen only because it appears to be the size the original change was
shooting for, and it certainly seems to be reasonably large (I might
have picked 64k in the absence of any historical guidance).
Add ENETUNREACH and EADDRNOTAVAIL to the list of errors that are potentially
transient and shouldn't result in closing the socket and giving up forever.
ian [Sat, 14 Dec 2013 00:16:08 +0000 (00:16 +0000)]
MFC r257669, r257672, r257673, r257676, r257678:
Call initarm_lastaddr() later in the init sequence, after establishing
static device mappings, rather than as the first of the initializations
that a platform can hook into. This allows a platform to allocate KVA
from the top of the address space downwards for things like static device
mapping, and return the final "last usable address" result after that and
other early init work is done.
Because some platforms were doing work in initarm_lastaddr() that needs to
be done early, add a new initarm_early_init() routine and move the early
init code to that routine on those platforms.
Make PTE_DEVICE a synonym for PTE_NOCACHE on armv4, to make it easier to
share the same code on both architectures.
Add new helper routines for arm static device mapping. The new code
allocates kva space from the top down for the device mappings and builds
entries in an internal table which is automatically used later by
arm_devmap_bootstrap(). The platform code just calls the new
arm_devmap_add_entry() function as many times as it needs to (up to 32
entries allowed; most platforms use 2 or 3 at most).
Remove imx local devmap code and use the essentially identical common
code that got moved from imx_machdep.c to arm/devmap.c.
ian [Fri, 13 Dec 2013 23:56:53 +0000 (23:56 +0000)]
MFC r257648, r257649, r257660:
Begin reducing code duplication in arm pmap.c and pmap-v6.c by factoring
out common code related to mapping device memory into a new devmap.c file.
Remove the growing duplication of code that used pmap_devmap_find_pa() and
then did some math with the returned results to generate a virtual address,
and likewise in reverse to get a physical address. Now there are a pair
of functions, arm_devmap_vtop() and arm_devmap_ptov(), to do that. The
bus_space_map() implementations are rewritten in terms of these.
Move remaining code and data related to static device mapping into the
new devmap.[ch] files. Emphasize the MD nature of these things by using
the prefix arm_devmap_ on the function and type names (already a few of
these things found their way into MI code, hopefully it will be harder to
do by accident in the future).
ian [Fri, 13 Dec 2013 23:07:22 +0000 (23:07 +0000)]
MFC r257639:
Remove the duplicated implementations of some bus_space functions and use
the essentially identical generic implementations instead. The generic
implementations differ only in the spelling of a couple variable names
and some formatting differences.
ian [Fri, 13 Dec 2013 22:52:59 +0000 (22:52 +0000)]
MFC r257603, r257604:
Rename WANDBOARD-COMMON to WANDBOARD.common and adjust the configs that
include it accordingly. The build machinery for universe and tinderbox
tries to build every kernel config whose name begins and ends with [A-Z0-9]
and the common include file that has most of the options isn't buildable
by itself, so the new lowercase .common will avoid building it.
ian [Fri, 13 Dec 2013 22:46:10 +0000 (22:46 +0000)]
MFC r257518, r257519:
TI sdhci driver improvements, mostly related to fdt data...
Use the published compatible strings (our own invention, "ti,mmchs" is
still accepted as well, for now).
Don't blindly turn on 8-bit bus mode, because even though the controller
supports it, the board has to be wired appropriately as well. Use the
published property (bus-width=<n>) and honor all the valid values (1,4,8).
The eMMC device on a Beaglebone Black is wired for 8-bit, update the dts.
The mmchs controller can inherently do both 1.8v and 3.0v on the first
device and 1.8v only on other devices, unless an external transceiver is
used. Set the voltage automatically for the first device and honor
the published fdt property (ti,dualvolt) for other devices.
projects / FreeBSD / stable / 10.git / log