All the needed infrastructure updates have been made to allow
snapshots to be taken on UFS/FFS filesystems that are using journaled
soft updates. The most immediate benefit is the ability to use a
snapshot to take a consistent filesystem dump on a live filesystem
using the -L option to dump(8).
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36491
The reported bug is UFS: bad file descriptor: soft update journaling
can not be enabled on some FreeBSD-provided disk images – failed
to write updated cg.
The UFS library (libufs(3)) failed to reopen its disk descriptor
when first attempting to update a cylinder group. The error only
occurred when trying to add journaling to a filesystem whose first
cylinder group was too full to hold the journal.
PR: 259090
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
ktls_cleanup() does not free ktls session objects, it merely
cleans (and frees) members of the object.
Change callers to use ktls_free() instead.
Reviewed by: gallatin, markj
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D37352
${name}_prepend is suboptimal as it is prepended to the actual
command being run. Therefore the term "commandS to prepend"
is misleading and no clear separation takes place for setup tasks
that may be required like changing a config file permission or
generating a configuration file prior to service start.
The other reason is that {argument}_precmd is a service-side
variable and cannot be repurposed from the user-side.
Reviewed by: pauamma
Differential Revision: https://reviews.freebsd.org/D36210
TL;DR: Three ZFS tests created ZFS pools on all unmounted devices listed
in /etc/fstab, corrupting their contents. Stop that.
Imagine my surprise when the ESP on my main dev/test VM would "randomly"
become corrupted, making it unbootable. Three tests collect various devices
from the system and try to add them to a test pool. The test expects this
to fail because it _assumes_ these devices are in use and ZFS will correctly
reject the request.
My /etc/fstab has two entries for devices in /dev:
/dev/gpt/swap0 none swap sw,trimonce,late
/dev/gpt/esp0 /boot/efi msdosfs rw,noauto
Note the `noauto` on the ESP. In a remarkable example of irony, I chose
this because it should keep the ESP more protected from corruption;
in fact, mounting it would have protected it from this case.
The tests added all of these devices to a test pool in a _single command_,
expecting the command to fail. The swap device was in use, so the command
correctly failed, but the ESP was added and therefore corrupted. However,
since the command correctly failed, the test didn't notice the ESP problem.
If each device had been added with its own command, the test _might_ have
noticed that one of them incorrectly succeeded. However, two of these
tests would not have noticed:
hotspare_create_001_neg was incorrectly specified as needing the Solaris
dumpadm command, so it was skipped. _Some_ of the test needs that command,
but it checks for its presence and runs fine without it.
Due to bug 241070, zpool_add_005_pos was marked as an expected failure.
Due to the coarse level of integration with ATF, this test would still
"pass" even if it failed for the wrong reason. I wrote bug 267554 to
reconsider the use of atf_expect_fail in these tests.
Let's further consider the use of various devices found around the system.
In addition to devices in /etc/fstab, the tests also used mounted devices
listed by the `mount` command. If ZFS behaves correctly, it will refuse
to added mounted devices and swap devices to a pool. However, these are
unit tests used by developers to ensure that ZFS still works after they
modify it, so it's reasonable to expect ZFS to do the _wrong_ thing
sometimes. Using random host devices is unsafe.
Fix the root problem by using only the disks provided via the "disks"
variable in kyua.conf. Use one to create a UFS file system and mount it.
Use another as a swap device. Use a third as a dump device, but expect
it to fail due to bug 241070.
While I'm here:
Due to commit 6b6e2954dd, we can simply add a second dump device and
remove it in cleanup. We no longer need to save, replace, and restore the
pre-existing dump device.
The cleanup_devices function used `camcontrol inquiry` to distinguish disks
from other devices, such as partitions. That works fine for SCSI, but not
for ATA or VirtIO block. Use `geom disk list` instead.
PR: 241070
PR: 267554
Reviewed by: asomers
Sponsored by: Dell Inc.
Differential Revision: https://reviews.freebsd.org/D37257
On Linux, the `kmalloc()` family of functions returns a special value if
the size of the allocation is zero. This macro verifies if the pointer
is NULL (the allocation failed) or the size is 0 (the allocation was not
performed AFAIU). This special value can be passed to `kfree()`.
On FreeBSD, our `malloc(9)` functions don't return a special value for
0-size allocations. Therefore we can simply compare the result against
NULL.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D37367
They are not really used in this header. However they are included in
Linux and at least the DRM drivers unfortunately rely on this namespace
pollution.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D37365
This is used by `i915_gem.c` in the i915 DRM driver to get access to
`wbinvd_on_all_cpus()`.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D36970
The M1 has no EL3, so we're limited to a spin-table implementation if we
want to eventually use bhyve on it. Implement spin-table now, but note
that we still prefer PSCI where possible.
Reviewed by: mmel
Differential Revision: https://reviews.freebsd.org/D34661
Although intel's specification did not tell which unit for Temperature
Statistics (Log Identifier C5h), I believe it is based on Celsius
instead of Kelvin.
here is my P3700 SSDs result(before):
Intel Temperature Log
=====================
Current: 30 K, -243.15 C, -405.67 F
Overtemp Last Flags 0
Overtemp Lifetime Flags 0
Max Temperature 53 K, -220.15 C, -364.27 F
Min Temperature 17 K, -256.15 C, -429.07 F
Max Operating Temperature 63 K, -210.15 C, -346.27 F
Min Operating Temperature 0 K, -273.15 C, -459.67 F
Estimated Temperature Offset: 0 C/K
after apply the patch, result is
Intel Temperature Log
=====================
Current: 303.15 K, 30 C, 86.00 F
Overtemp Last Flags 0
Overtemp Lifetime Flags 0
Max Temperature 326.15 K, 53 C, 127.40 F
Min Temperature 290.15 K, 17 C, 62.60 F
Max Operating Temperature 336.15 K, 63 C, 145.40 F
Min Operating Temperature 273.15 K, 0 C, 32.00 F
Estimated Temperature Offset: 0 C/K
I also compare to smartctl's report. it match very well.
also tested on Intel P3600, it fixed the problem.
Signed-off-by: Wanpeng Qian <wanpengqian@gmail.com>
Reviewed by: imp (added tweak to samsung.c so it still compiles)
Differential Revision: https://reviews.freebsd.org/D32845
This command already prints a tremendous amount of output, and properly
obeys the pager. It no longer makes sense to arbitrarily limit the pages
that are printed, as the reader will not be aware that this has
happened.
Reviewed by: markj
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D37361
This is not exhaustive, just what I collected while working on
mac_ddb(4).
Reviewed by: pauamma, markj, jhb
MFC after: 1 week
Sponsored by: The FreeBSD Foundation (in part)
Differential Revision: https://reviews.freebsd.org/D37333
- Describe optional 'addr' argument to many show commands
- Remove obsolete commands (show cbstat)
- 'show jails' was renamed to 'show prison'
- Remove superfluous commentary about sleepqueues
- Fix an xref to gdb(4)
- Fix issues reported by mandoc -Tlint
- Plus a couple other inaccuracies/inconsistencies
Reviewed by: pauamma, markj, jhb
MFC after: 1 week
Sponsored by: The FreeBSD Foundation (in part)
Differential Revision: https://reviews.freebsd.org/D37332
This means INET and DEBUGNET in addition to NETDUMP.
Reviewed by: pauamma, markj
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D37331
The man page claims that netgdb will be enabled automatically with the
presence of the DDB, GDB, and INET options. Based on the logic in
conf/files, this is not the case. Update the manpage to list all
of the options required to include netgdb.
Reviewed by: pauamma, markj
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D37330
I took the implementation from OpenBSD, commit
d55ef580b1748517027c3eabdb715316ca5b1442.
The only difference is the addition of `dma_buf_map_is_equal()`.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D36963
It simply includes the same header in FreeBSD (which is located
elsewhere).
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D36960
In FreeBSD, this is a wrapper on top of `realloc()`.
V2: Check if `n * size` would overflow and return `NULL` if that's the
case. Suggested by hselasky@ and emaste@.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D36959
In Linux, this affects how the value is formatted. In FreeBSD, this
remains an unsigned integer.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D36958
The previous `llnode` field is moved inside another field `node`.
This `node` field is a `struct __call_single_node` in Linux. Here, we
simply add an anonymous struct with the `llnode` field inside. That
field's new name is `llist` now.
V2: Use an anonymous union to keep the structure backward compatible
with drivers using the previous `llnode` field. This was suggested
by wufl@ and hselasky@. Thank you!
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D36955
arm64 is the only currently supported architecture that has
${MACHINE_CPUARCH} set to a different value (aarch64) than ${MACHINE}
(arm64), as described in arch(7). However, there is no source directory
associated with arm64 that has a name set to ${MACHINE_CPUARCH}.
Remove the dead code that adds a directory with a name set to
${MACHINE_CPUARCH} to a list of directories indexed with cscope.
This change allows to use the cscope target on arm64.
Discussed with: jhb
Reviewed by: imp jhb
Approved by: oshogbo (mentor)
Differential Revision: https://reviews.freebsd.org/D36402
Silence a warning from the compiler about "const" being discarded. The
warning is correct: nvlist values are supposed to be immutable.
However, fixing this properly will require some contortions on behalf of
consumers who look up a subtree of the config and modify it. Per a
discussion on freebsd-virtualization@, the solution will probably be to
outright replace the use of nvlists for VM configuration, but until that
happens let's document the problem and silence the warning.
No functional change intended.
MFC after: 2 weeks
Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D37293
They accomplish nothing since the qualifier is casted away in calls to
memcpy() and copyin()/copyout(). No functional change intended.
MFC after: 2 weeks
Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D37292
The qualifiers are there presumably because these rings are mapped into
the guest, but they do not appear to be required for correctness, and
bhyve generally doesn't qualify accesses to guest memory this way.
Moreover, the qualifiers are discarded by snapshot code, causing clang
to emit warnings. Just stop using volatile here.
MFC after: 2 weeks
Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D37291
This fixes a warning raised by the removal of the volatile qualifier
from &trb->qwTrb0 in the following snippet:
xfer_block = usb_data_xfer_append(xfer,
(void *)(trbflags & XHCI_TRB_3_IDT_BIT ?
&trb->qwTrb0 : XHCI_GADDR(sc, trb->qwTrb0)),
trb->dwTrb2 & 0x1FFFF, (void *)addr, ccs);
The use of volatile appears to be inherited from the kernel driver's
definitions of the same structures. It makes some sense, since USB TRBs
and related structures live in guest memory, but bhyve device models
generally don't volatile-qualify accesses to guest memory and I can't
see how they are required for correctness here. Moreover, XHCI_GADDR
does not return volatile pointers so we're already being inconsistent.
Just drop the qualifiers to address the warning.
MFC after: 2 weeks
Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D37290
Use it to silence warnings about potential unaligned accesses. No
functional change intended.
MFC after: 1 week
Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D37289
fq_codel was broken due to a missing m_rcvif_serialize() in the enqueue
path.
Add a simple test case to ensure it at least passes traffic.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Serialize rcvif when enqueing packets for codel. We already tried to
restore the serialized rcvif in fq_codel_extract_head(), but that
doesn't work when we fail to serialize it first, so we ended up dropping
all packets passed through codel.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D37318
We need to explicitly list AES-128-GCM as an allowed cipher for that
mode to work. While here also add AES-192-GCM. That brings our supported
cipher list in line with other openvpn/dco platforms.
Sponsored by: Rubicon Communications, LLC ("Netgate")
similar to the same token in glibc.
Requested and reviewed by: bapt
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D37329
The pull-up/pull-down register offset was wrong on the Rockchip rk356x.
It was set such that the driver would modify the IOMUX control registers.
This seems to work with the current device tree files, but fails with
upstream files. Fix the offset so the later calculation has the correct
offset for the pull-up/pull-down control register.
Sponsored by: The FreeBSD Foundation
