Instead of pretending to successfully mount them while not actually
mounting anything, we'll now actually mount them *and* claim we mounted them
successfully.
Reported by: ler
MFC after: 3 days
The DTS for this board is already present in sys/gnu/dts/arm64/rockchip/
and just needs to be enabled.
Submitted by: alex@wied.io
Differential Revision: https://reviews.freebsd.org/D19823
Small mis-merge from multiple WIP resulted in block io media handles getting
double-initialized. This resulted in some installations oddly landing at the
mountroot prompt.
Reported by: ler
Reviewed by: imp
r345519 rewrote parts of how we build .dtb, but mistakenly dropped the
vendor dir for aarch64. Simply drop the :T for building ${DTB} in the
aarch64 case- it'll get applied at install-time as-needed, with :H:T for
determining the vendor dir.
Reported by: manu
Tested by: manu
Reviewed by: manu
MFC after: 3 days
- Remove dead and most likely rotten MALLOC_DEBUG, MSTAT, and RCHECK options.
- Remove unused headers.
- Remove one case of undefined behavior where left shift could overflow.
It is impossible on practice for rtld and libthr consumer.
PR: 237577
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
That makes Linux lscpu(1) work.
Reviewed by: dchagin
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D20131
It's possible for a Hypervisor Maintenance Interrupt (HMI) to occur while in
the pmap code, holding locks. This can cause WITNESS to panic due to lock
errors in calling pmap_kextract(). Since we don't yet handle the flags
returned by OPAL_HANDLE_HMI2, just stop using it, so that we don't call into
pmap_kextract().
Reported by: pkubaj
Some UEFI implementations trash this register and, as we use it as a
platform register, the kernel doesn't save it before calling into the UEFI
runtime services. As we have a copy in tpidr_el1 restore from there when
exiting the EFI environment.
PR: 237234, 237055
Reviewed by: manu
Tested On: Ampere eMAG
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
Sponsored by: Ampere Computing (hardware)
Differential Revision: https://reviews.freebsd.org/D20127
vm_map_wire() increments entry->wire_count, after that it drops the
map lock both for faulting in the entry' pages, and for marking next
entry in the requested region as IN_TRANSITION. Only after all entries
are faulted in, MAP_ENTRY_USER_WIRE flag is set.
This makes it possible for vm_map_protect() to run while other entry'
MAP_ENTRY_IN_TRANSITION flag is handled, and vm_map_busy() lock does
not prevent it. In particular, if the call to vm_map_protect() adds
VM_PROT_WRITE to CoW entry, it would fail to call
vm_fault_copy_entry(). There are at least two consequences of the
race: the top object in the shadow chain is not populated with
writeable pages, and second, the entry eventually get contradictory
flags MAP_ENTRY_NEEDS_COPY | MAP_ENTRY_USER_WIRED with VM_PROT_WRITE
set.
Handle it by waiting for all MAP_ENTRY_IN_TRANSITION flags to go away
in vm_map_protect(), which does not drop map lock afterwards. Note
that vm_map_busy_wait() is left as is.
Reported and tested by: pho (previous version)
Reviewed by: Doug Moore <dougm@rice.edu>, markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D20091
These three cases dovetail with other places in the code where we use
or set D_PARTISGPT when we mean that the partitioning scheme is
GPT. Use this #define to make the code easier to undertand.
Reviewed by: tsoome@
Differential Revision: https://reviews.freebsd.org/D20122
If we do have GPT on disk, read the disk size from it and do not
call int13.
Since int13 does report bogus informatiopn too often, rather trust the
partition table. We are using the same strategy with loader.
MFC after: 1 month
It seems to be incompatible with the OVMF.fd (of unknown provenance)
in use by the Cirrus-CI config. We will soon have a known OVMF build
via a port/package (see review D19869) and we can switch back to q35
once packages are available.
Discussed with: bcran
Port the logic used by getifaddrs(3) to handle the case where
NET_RT_IFLIST returns ENOMEM, which can occur if the list size changes
between the buffer allocation and sysctl read.
PR: 195191
Submitted by: Guy Yur <guyyur@gmail.com> (original version)
MFC after: 1 week
30GB to 3GB. The raw images can be resized using truncate(1), and
other formats can be resized with tools included with other tools
included with other hypervisors.
Enable the growfs(8) rc(8) at firstboot if the disk was resized
prior to booting the virtual machine for the first time.
Discussed with: several
PR: 232313 (requested in other context)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Make function macro wrappers for locking and unlocking to ease readability.
No functional change.
Discussed with: kib@, tychon@ and zeising@
Sponsored by: Mellanox Technologies
Unconditional writing to MAS7, which doesn't exist on the e500v1 core, in a
TLB miss handler has been in the code for several years now. Since this has
gone unnoticed for so long, it's easily concluded that e500v1 is not in use
with FreeBSD. Simplify the code path a bit, by unconditionally zeroing MAS7
instead of calling a subroutine to do it.
r18 is used to hold the old PCB flags, but cpu_throw doesn't populate r18
with PCB flags, since the old thread is gone. This can lead to panics on
cores that don't have the registers guarded by these flags.
This version fixes the problems identified in r345244.
Reviewed by: kib
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19598
* Replace all instances of freebsd-testing with `#test`. `#test` is the
Phabricator group that focuses on test-related reviews.
* Replace `atf` with contrib/atf, as that's the actual location for the test
framework.
* Remove jmmv@ from the maintainers list for atf. He is the upstream project
owner, but was moved to alumni status after r345787.
* Fix a typo accidentally introduced in r346899 (inpact -> impact).
Add a note to MAINTAINERS requesting pre-commit review from the graphics
team, using phabricator, for changes to the lkpi subsystem. This is done in
order to give us a chance to test the graphics drivers (drm drivers) for
regressions, and to try to avoid breakage, errors and issues with the
graphics drivers.
The review is done via the #x11 group on phabricator.
Please note that hselasky also want to review changes.
Discussed with: hselasky, imp
Approved by: imp
Turning on multicast debug made multicast failure worse
because the strings and #define values no longer matched
up. Fix them, and make sure they stay matched-up.
Submitted by: torek
MFC after: 1 week
Sponsored by: iXsystems, Inc.
This change makes it easier to enable/disable the inclusion of
OPAL flash in the kernel.
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D20098
so it does not require a bounce buffer. The only need for this was
to align the buffer address. Implement unaligned access and we don't
need to copy data twice.
o Remove contigmalloc-based bounce buffer from xDMA code since it is
not suitable for arbitrary memory provided by platform, which is
sometimes a dedicated piece of memory that is not managed by OS at all.
Sponsored by: DARPA, AFRL
cursor from 16x16 (with 6 columns unused) to 10x16 and rename it to
the "small" cursor. Add a "large" 19x32 cursor and use it for screen
widths larger than 800 pixels. Use libvgl's too-small indentation for
the large data declarations.
MOUSE_IMG_SIZE = 16 is still part of the API. If an application supplies
invalid bitmaps for the cursor, then the results may be different from
before.
complications in the previous methods.
r346761 broke showing the mouse cursor after changing its state from
off to on (including initially), since showing the cursor uses the
state to decide whether to actually show and the state variable was
not changed until after null showing. Moving the mouse or copying
under the cursor fixed the problem. Fix this and similar problems for
the on to off transition by changing the state variable before drawing
the cursor.
r346641 failed to turn off the mouse cursor on exit from vgl. It hid
the cursor only temporarily for clearing. This doesn't change the state
variable, so unhiding the cursor after clearing restored the cursor if its
state was on. Fix this by changing its state to VGL_MOUSEHIDE using the
application API for changing the state.
Remove the VGLMouseVisible state variable and the extra states given by it.
This was an optimization that was just an obfuscation in at least the
previous version.
Staticize VGLMouseAction(). Remove VGLMousePointerShow/Hide() except as
internals in __VGLMouseMode(). __VGLMouseMouseMode() is the same as the
application API VGLMouseMouseMode() except it returns the previous mode
which callers need to know to restore it after hiding the cursor.
Use the refactoring to make minor improvements in a simpler way than was
possible:
- in VGLMouseAction(), only hide and and unhide the mouse cursor if the
mouse moved
- in VGLClear(), only hide and and unhide the mouse cursor if the clearing
method would otherwise clear the cursor.
These predicates are vestigal and cannot be true today. For example,
idle threads are not allowed to acquire locks.
Also cache curthread in breada().
No functional change intended.
Reviewed by: kib, mckusick
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D20066
opcodes when it is needed.
This should fix the problem, when printed by `ipfw show` rule could not
be added due to missing "proto" keyword.
MFC after: 2 weeks
When set, we ignore all the hints that the UEFI boot manager has set
for us. We also always fail back to the OK prompt when we can't find
the right thing to boot rather than failing back to the UEFI boot
manager. This has the side effect of also expanding the cases where we
fail back to the OK prompt to include when we're booted under UEFI,
but UEFI::BootCurrent isn't set in the environment and we can't find a
proper place to boot from.
Reviewed by: bcran
Differential Revision: https://reviews.freebsd.org/D20016
If uefi_rootdev is set in the environment, then treat it like a device
path. Convert the string to a device path and see if we can find a
device that matches. If so, use that device at our root dev no matter
what. If it's bad in any way, the boot will fail.
Reviewed by: bcran
Differential Revision: https://reviews.freebsd.org/D20016
