imp [Sun, 22 Dec 2013 22:31:39 +0000 (22:31 +0000)]
Direct commit: not relevant to other branches.
Fix mountroot> prompt eating most of the characters by not enabling
RXRDY interrupts in the attach routine. Instead, defer this until the
first interrupt we see after the device is opened. Given the console
use case, we're guaranteed to get a TXRDY interrupt before any reads
are posted due to boot messages, which makes this work.
The real fix is to use cngrab/cnungrab function pointers to disable
RXRDY interrupts while grabbed. However, that touches the MI uart
code, so was disallowed for 10.0 due to the lateness of the hour this
fix was proposed. It works for mountroot, the most common atmel kernel
prompt use cases, but wouldn't work for GELI since it prompts later in
the boot process.
imp [Sun, 22 Dec 2013 22:24:17 +0000 (22:24 +0000)]
Merge from stable/10 r259381:
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.
imp [Sun, 22 Dec 2013 22:20:17 +0000 (22:20 +0000)]
Merge from stable/10 r259380:
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...
dteske [Fri, 20 Dec 2013 15:46:24 +0000 (15:46 +0000)]
MFS10 SVN r259621:
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 13:44:07 +0000 (13:44 +0000)]
MFS r259613:
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"]
gjb [Wed, 18 Dec 2013 01:27:30 +0000 (01:27 +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.
Approved by: re (delphij, glebius)
Sponsored by: The FreeBSD Foundation
nwhitehorn [Tue, 17 Dec 2013 14:55:23 +0000 (14:55 +0000)]
MF10 259465:
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.
gjb [Sun, 15 Dec 2013 03:20:01 +0000 (03:20 +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).
Approved by: re (glebius)
Sponsored by: The FreeBSD Foundation
dumbbell [Sat, 14 Dec 2013 00:40:47 +0000 (00:40 +0000)]
MFC r259236:
drm/radeon: radeon_dp_i2c_aux_ch() must return 0 on FreeBSD
The code was unmodified compared to Linux and returned the amount of
received bytes from the i2c bus. This led to non-working i2c bus and
failure to eg. read monitor's EDID, if connected to DisplayPort.
Tested by: Mikaƫl Urankar <mikael.urankar@gmail.com>
Approved by: re (gjb)
dumbbell [Sat, 14 Dec 2013 00:25:25 +0000 (00:25 +0000)]
MFC r259234:
drm/radeon: agp_info->ai_aperture_size is in bytes, not Mbytes
This fixes radeon_agp_init() and gtt_size is now correct. However, this
is not enough to make Radeon AGP cards work: ttm_agp_backend.c isn't
implemented yet.
trasz [Fri, 13 Dec 2013 21:27:16 +0000 (21:27 +0000)]
MFC r259182:
Fix handling for empty auth-groups. Without it, ctld child process
would either exit on assertion, or, if assertions are not enabled,
fail to authenticate the target.
Approved by: re (gjb)
Sponsored by: The FreeBSD Foundation
dim [Thu, 12 Dec 2013 22:04:47 +0000 (22:04 +0000)]
Merge r259216 from stable/10 (head r259111):
Use correct casts in gcc's emmintrin.h for the first arguments of the
following builtin functions:
* __builtin_ia32_pslldi128() takes __v4si instead of __v8hi
* __builtin_ia32_psllqi128() takes __v2di instead of __v8hi
* __builtin_ia32_psradi128() takes __v4si instead of __v8hi
This should fix the following errors when building the LINT kernel with
gcc:
sys/crypto/aesni/aesni_wrap.c:191: error: incompatible type for argument 1 of
'__builtin_ia32_psradi128'
sys/crypto/aesni/aesni_wrap.c:195: error: incompatible type for argument 1 of
'__builtin_ia32_pslldi128'
dim [Thu, 12 Dec 2013 22:01:42 +0000 (22:01 +0000)]
Merge r259214 from stable/10 (head r259100):
Pull in r196658 from upstream clang trunk:
CodeGen: Don't emit linkage on thunks that aren't emitted because they're
vararg.
This can happen when we're trying to emit a thunk with available_externally
linkage with optimization enabled but bail because it doesn't make sense for
vararg functions.
[LLVM] PR18098.
This should fix clang "Broken module found, compilation aborted" errors when
building the qt4-based dvbcut port.
gjb [Sat, 7 Dec 2013 12:57:38 +0000 (12:57 +0000)]
When stable/10 was branched from head/, __FreeBSD_version was bumped
to 1000500 from 1000055 when it should not have been bumped yet.
At the risk of having non-standard '5XX' __FreeBSD_version suffix
in a -RELEASE, bump __FreeBSD_version in releng/10.0 from 1000100
to 1000510 to prevent the value from going backwards as part of the
stable/10 -> releng/10.0 branch.
A commit to bump __FreeBSD_version in stable/10 will follow.
Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation