r264935 (gjb):
Add a separate script to build the memstick.img and the
mini-memstick.img with UEFI support.
As the comments in the file suggest, 1) there must
be existing ${.OBJDIR}/usr/src/release/{release,bootonly};
2) TARGET/TARGET_ARCH must be amd64; and 3) it must be
a vt(4)-enabled kernel with vt_efifb (*not* vt_vga).
This script is not hooked into release/Makefile in any way
until further testing is complete.
r264992 (nwhitehorn):
Make a dual-boot BIOS/UEFI memstick image. Testing required before
this gets renamed make-memstick.sh.
r265017 (nwhitehorn):
loader's GPT support on BIOS does not seem to like the root
filesystem being the last filesystem on the disk for some reason
when made by this script. Add a vestigial swap partition to allow
this to boot with QEMU BIOS.
Approved by: re
Sponsored by: The FreeBSD Foundation
Phabric: https://reviews.freebsd.org/D706
Approved by: rpaulo (mentor)
Approved by: re (gjb)
Reviewed by: jmmv
Sponsored by: EMC / Isilon Storage Division
r267176:
Add the *_TESTS_SH_SED_* functionality to atf.test.mk.
This exists already in plain.test.mk and tap.test.mk and should have been
added to atf.test.mk too when the feature was first introduced.
(It is probably time to address the related TODOs but I will do that
separately.)
r267181:
Move atf-sh from /usr/bin/ to /usr/libexec/
In r266650, we made libatf-c and libatf-c++ private libraries so that no
components outside of the source tree could unintendedly depend on them.
This change does the same for the "atf-sh library" by moving the atf-sh
interpreter from its public location in /usr/bin/ to the private location
in /usr/libexec/. Our build system will ensure that our own test programs
use the right binary, but users won't be able to depend on atf-sh by
"mistake".
Committing this now to ride the UPDATING notice added with r267172 today.
r268445:
Fix atf-sh's integration_test
With the move of atf-sh into /usr/libexec in r267181, some of the
tests in the integration_test program broke because they could not
execute atf-sh from the path any longer.
This slipped through because I do have a local atf installation in
my home directory that appears in my path, hence the tests could
still execute my own version.
Fix this by forcing /usr/libexec to appear at the beginning of the
path when attempting to execute atf-sh.
To make upgrading easy (and to avoid an unnecessary entry in UPDATING),
make integration_test depend on the Makefile so that a rebuild of the
shell script is triggered. This requires a hack in the *.test.mk files
to ensure the Makefile is not treated as a source to the generated
program. Ugly, I know, but I don't have a better way of doing this at
the moment. Will think of one once I address the TODO in the *.test.mk
files that suggests generalizing the file generation functionality.
PR: 191052
Reviewed by: Garrett Cooper
Use of "find ." resulted in METALOG entries with an extra ./ -- e.g.,
./usr/share/zoneinfo/./America/Toronto. Avoid this by using globbing
via "find *" instead.
Approved by: re
Sponsored by: DARPA, AFRL
This allows WITH_DEBUG_FILES to produce standalone debug for the ELF
runtime linker.
We previously disabled standalone debug files for bsd.prog.mk consumers
that included a non-default ${PROG} target, but this is not required.
Consumers that do not support standalone debug are still handled by
disabling it for statically linked binaries, and for those that specify
a non-default binary format.
Sponsored by: DARPA, AFRL
Approved by: re
Always seek back to the beginning of a regular directory, even if the
previous seek location was 0. Without this, readdir() would see
dd_loc of zero and call getdirentries() which would start reading
entries at the current seek location of the directory ignoring the
first batch of entries. Also, rewinddir() should always seek so that
it reads the directory from the beginning to get updated entries.
PR: 192935
Approved by: re (gjb)
r270973
Fix for WITNESS warning while doing xpt_rescan.
This happen when converting any JBOD to RAID or creating
any new RAID from Unconfigured Drives.
Without this fix, user may see call trace if WITNESS is enabled.
System may panic when reconfiguring the RAID.
Reviewed by: ambrisko
Approved by: re (gleb)
---
Improve ZFS N-way mirror read performance by using load and locality
information.
MFC r260713:
Fix ZFS mirror code for handling multiple DVA's
Also make the addition of the d_rotation_rate binary compatible. This allows
storage drivers compiled for 10.0 to work by preserving the ABI for disks.
Approved by: re (gjb)
Sponsored by: Multiplay
Remove KASSERT from in6p_lookup_mcast_ifp().
When the devel/jenkins port, version 1.551 was started,
the kernel would panic if INVARIANTS was enabled in the kernel config.
Suggested by: bms
Approved by: re (gjb)
Set the si_code appropriately for exception-caused signals.
LLDB checks the si_code, and aborts if a code isn't known.
Approved by: re (gjb)
Relnotes: yes
held in register r13, is used outside the bounds of critical_enter()
and critical_exit() by virtue of optimizations performed by the
compiler. The net effect being that address computations of fields
in the PCPU structure could be relative to the PCPU structure of the
CPU on which the address computation was performed and not related
to the CPU that executes the actual load or store operation.
The typical failure mode being that the per-CPU cache of UMA got
corrupted due to accesses from other CPUs.
Adding more volatile decorating to the register expression does not
help. The thinking being that volatile is assumed to work on memory
references and not register references. Thus, the fix is to perform
the address computation using a volatile inline assembly statement.
Additionally, since the reference is fundamentally non-atomic on ia64
by virtue of have a distinct address computation followed by the
actual load or store operation, it is required to wrap the entire
PCPU access in a critical section.
With PCPU_GET and friends requiring curthread now that they're in a
critical section, low-level use of these macros in functions like
cpu_switch() is not possible anymore. Consequently, a second order
set of changes is needed to avoid using PCPU_GET and friends where
curthread is either not set yet, or in the process of being changed.
In those cases, explicit dereferencing of pcpup is needed. In those
cases it is also possible to do that.
This is a direct commit to stable/10.
Approved by: re@ (marius)
r259657:
Add suspend/resume capabilities to the ATI backlight ppc driver.
With this, also shut off the display (DPMS-style) and disable the
clocking when the backlight level is set to 0. This is taken from the
radeonkms driver (radeon_legacy_encoders.c) which doesn't yet support
PowerPC.
r264205,r264207:
Fix the ATI backlight driver off/on handling. Now this driver works
correctly with the ATI Radeon 9700 in the PowerBook G4 1.67GHz.
Code shamelessly taken in spirit from the radeonkms driver, which I
hope will make this driver redundant in the future.
Approved by: re (marius)
Relnotes: yes (not suspend/resume, but the rest)
Restore pre-r239157 handling of sched_yield(), when thread time slice
was aborted, allowing other threads to run. Without this change thread
is just rescheduled again, that was illustrated by provided test tool.
PR: 192926
Submitted by: eric@vangyzen.net
Approved by: re (marius)
MFamd64: Add a machdep.bootmethod sysctl to inform the installer which
firmware method was used for booting. This is hardcoded to BIOS on i386.
PR: 192962
Approved by: re (gjb)
Add some missing checks for unsupported interfaces (e.g. pflog(4)) when
handling ioctls. While here, remove duplicated checks for a NULL ifp in
in6_control(): this check is already done near the beginning of the
function.
MFC r270349:
Suppress warnings when retrieving protocol stats from interfaces that
don't support IPv6 (e.g. pflog(4)).
PR: 189117
Approved by: re (gjb)
Bump the default size of cpuset_t masks in userland from 128 bits to 256.
This should not be an ABI change since the various public APIs that use
cpusets all include an explicit size parameter in addition to the cpuset
parameter.
Approved by: re (gjb)
r263464,r263752,r275189:
Mask out SRR1 bits that aren't exported to the MSR.
This appears to fix a strange condition with X on 32-bit PowerBooks I
observed, caused by one of these bits getting set in the mcontext, but
not set in the thread, which is a symptom of another problem, more
difficult to diagnose. Since these bits aren't exported anyway, this
change makes it more explicit that the bits aren't MSR-related in SRR1.
r261095:
Fix 32-bit signal handling on ppc64. This was broken when the
PSL_USERSTATIC macro was changed. Since copying 64-bit srr1 into
32-bit srr1 drops the upper 32 bits, any bits set in the context were
dropped, meaning the context check fails. Since 32-bit set_context()
can't change those bits anyway, copy the ones from the current context
(td->td_frame) before calling set_context().
Approved by: re
Relnotes: yes (Affects 10-stable, but not 10.0-release)
Direct access to the quota files, in particular, lookup, causes lock
conflict with the quota metadata access. Mark quota vnode lock as
recursive and always exclusive to avoid the problem.
Approved by: re (gjb)
Increase the stack size for ppc64 from 4 pages to 8.
I found a stack overflow when a coredump was taken onto a ZFS volume with
heavy network activity. 2 DSI traps, plus one DECR trap, along with several
function calls in the stack, overflowed the 4 pages. 8 page stack fixes this.
Discussed with: nwhitehorn
Approved by: re
Relnotes: yes
r264391 (nwhitehorn):
Add a simple EFI stub loader. This is a quick and dirty of boot1.chrp
from the PowerPC port with all the Open Firmware bits removed and
replaced by their EFI counterparts. On the whole, I think I prefer
Open Firmware.
This code is supposed to be an immutable shim that sits on the EFI
system partition, loads /boot/loader.efi from UFS and tells the real
loader what disk/partition to look at. It finds the UFS root partition
by the somewhat braindead approach of picking the first UFS partition
it can find. Better approaches are called for, but this works for now.
This shim loader will also be useful for secure boot in the future,
which will require some rearchitecture.
r264403 (nwhitehorn):
Fix buildworld. I had some local bits in my build tree that caused
this to work by accident.
r264404 (nwhitehorn):
Add my copyright here. Most of this is unmodified from the original
sparc64 version, but at least some indication of changes that postdate
the actual invention of EFI is probably a good idea.
r264414 (nwhitehorn):
Apparently some of the i386 boot blocks are so close to full that
adding single lines to ufsread.c spills them over. Duplicate a whole
bunch of code to get file sizes into boot1.efi/boot1.c rather than
modifying ufsread.c.
r264975 (nwhitehorn):
Add generation of an EFI filesystem to hold boot1.efi. This is a near-
exact copy of the code from boot1.chrp again.
The resulting image is installed to /boot/boot1.efifat. If dd'ed to an
800K "efi" partition, it should result in a bootable system.
r268975 (sbruno): Remove boot1.efi during clean target.
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
This MFC consists of the following SVN revisions:
258741 261568 261603 261668 263115 263117 263968 264078 264087 264088
264092 264095 264115 264132 264208 264261 264262 264263 264319 265028
265057 268974
Detailed commit messages:
r258741: Note that libstand is 32-bit on amd64 and powerpc64
r261568: Build libstand as a 64-bit library on amd64
The 32-bit bootloaders now link against libstand.a in
sys/boot/libstand32, so there is no need to force /usr/lib/libstand.a
to be 32-bit.
r261603: Don't force efi to a 32-bit build on amd64
r261668: Build libstand as a 64-bit library on ppc64
The 32-bit bootloaders now link against libstand.a in
sys/boot/libstand32, so there is no need to force /usr/lib/libstand.a
to be 32-bit.
This is equivalent to r261568 for amd64.
r263115: Add amd64 EFI headers
r263117: Connect 64-bit boot ficl to the build
It is not yet used, but this will ensure it doesn't get broken.
r263968: Use EFI types for EFI values (silences warnings).
EFI UINTN is actually a 64-bit type on 64-bit processors.
r264078: Put each source file on a separate line
This will simplify rebasing the amd64 UEFI patch set.
r264087: Build boot/ficl as 64-bit library on amd64
The 32-bit bootloaders on amd64 now use the 32-bit version in ficl32,
as is done with libstand32. The native 64-bit ficl will be used by the
upcoming UEFI loader.
r264088: Merge efilib changes from projects/uefi
r247216: Add the ability for a device to have an "alias" handle.
r247379: Fix network device registration.
r247380: Adjust our load device when we boot from CD under UEFI.
The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points
at the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition".
The existing EFI partition code only looks for logical partitions and
so the CD filesystem was rendered invisible.
To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.
Something similar to this will be required for booting from other media
as well as the loader will live in the EFI system partition, not on the
partition containing the kernel.
r247381: Remove a scatalogical debug printf that crept in.
r264092: Add -fPIC for amd64
r264095: Support UEFI booting on amd64 via loader.efi
This is largely the work from the projects/uefi branch, with some
additional refinements. This is derived from (and replaces) the
original i386 efi implementation; i386 support will be restored later.
Specific revisions of note from projects/uefi:
r247380:
Adjust our load device when we boot from CD under UEFI.
The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points at
the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition". The
existing EFI partition code only looks for logical partitions and so
the CD filesystem was rendered invisible.
To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.
Something similar to this will be required for booting from other
media as well as the loader will live in the EFI system partition, not
on the partition containing the kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r247216:
Use the UEFI Graphics Output Protocol to get the parameters of the
framebuffer.
r264115: Fix printf format mismatches
r264132: Connect sys/boot/amd64 to the build
r264208: Do not build the amd64 UEFI loader with GCC
The UEFI loader causes buildworld to fail when building with (in-tree)
GCC, due to a typedef redefinition. As it happens the in-tree GCC
cannot successfully build the UEFI loader anyhow, as it does not support
__attribute__((ms_abi)). Thus, just avoid trying to build it with GCC,
rather than disconnecting it from the build until the underlying issue
is fixed.
r264261: Correct a variable's type for 64-bit Ficl
FICL_INT is long.
r264262: Fix printf args for 64-bit archs
r264263: Add explicit casts to quiet warnings in libefi
r264319: Fix EFI loader object tree creation on 9.x build hosts
Previously ${COMPILER_TYPE} was checked in sys/boot/amd64, and the efi
subdirectory was skipped altogether for gcc (since GCC does not support
a required attribute). However, during the early buildworld stages
${COMPILER_TYPE} is the existing system compiler (i.e., gcc on 9.x build
hosts), not the compiler that will eventually be used. This caused
"make obj" to skip the efi subdirectory. In later build stages
${COMPILER_TYPE} is "clang", and then the efi loader would attempt to
build in the source directory.
r265028 (dteske): Disable the beastie menu for EFI console ...
which doesn't support ANSI codes (so things like `at-xy', `clear', and
other commands don't work making it impossible to generate a living
menu).
r265057 (nwhitehorn): Turn off various fancy instruction sets...
as well as deduplicate some options. This makes the EFI loader build
work with CPUTYPE=native in make.conf on my Core i5.
r268974 (sbruno): Supress clang warning for FreeBSD printf %b and %D formats
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
libstand's qdivrem.c assumes that sizeof(int) == sizeof(long), this is not
true on amd64 I'm not quite positive this is the "correct" solution for
this but it does seem to compile and shut up the spew of warnings when
compiling libstand for userboot.
Add two _Static_asserts() so that in the future somebody will get a compile
failure if an architecture develops that violates the assumptions of this
code. (strongly suggested by jmg)
Change commetns to indicate int types instead of long. (noted by ian in
phabric review)
Phabric: https://phabric.freebsd.org/D443
r269029 (sbruno):
Update so that clean target in sys/boot will delete the symlink
created for machine
r269036 (sbruno):
Delete the entire cleandepend/cleanmachine target thing now that its
been cleared out in r269029
A 32-bit libstand is needed on 64-bit platforms for use by various
bootloaders. Previously only the 32-bit version was built, installed
as /usr/lib/libstand.a.
A new 64-bit libstand consumer will arrive in the near future, so move
the bootloader-specific 32-bit version to sys/boot/libstand32/.
Explicitly link against this version in the 32-bit loaders.
r261614: Build a 32-bit libstand under sys/boot/ for ppc64
This change is equivalent to r261567 for i386/amd64.
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
