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
The original ARC paper called for an initial 50/50 MRU/MFU split
and this is accounted in various places where arc_p = arc_c >> 1,
with further adjustment based on ghost lists size/hit. However, in
current code both arc_adapt() and arc_get_data_impl() aggressively
grow arc_p until arc_c is reached, causing unneeded pressure on
MFU and greatly reducing its scan-resistance until ghost list
adjustments kick in.
This patch restores the original behavior of initially having arc_p
as 1/2 of total ARC, without preventing MRU to use up to 100% total
ARC when MFU is empty.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Gionatan Danti <g.danti@assyoma.it>
Closes#14137Closes#14120
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
As new compression algorithms are added to ZFS, it could be useful for
people to recompress data with new algorithms. There is currently no
mechanism to do this aside from copying the data manually into a new
filesystem with the new algorithm enabled. This tool allows the
transformation to happen through zfs send, allowing it to be done
efficiently to remote systems and in an incremental fashion.
A new zstream command is added that decompresses WRITE records and
then recompresses them with a provided algorithm, and then re-emits
the modified send stream. It may also be possible to re-compress
embedded block pointers, but that was not attempted for the initial
version.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Paul Dagnelie <pcd@delphix.com>
Closes#14106
This test uses fio's bssplit mechanism to choose io sizes for the test,
leaving the PERF_IOSIZES variable empty. Because that variable is
empty, the innermost loop in do_fio_run_impl is never executed, and as
a result, this test does the setup but collects no data. Setting the
variable to "bssplit" allows performance data to be gathered.
Reviewed-by: Tony Nguyen <tony.nguyen@delphix.com>
Signed-off-by: John Wren Kennedy <john.kennedy@delphix.com>
Closes#14163
f224eddf92 began dereferencing a NULL
checked pointer in zpl_vap_init(), which made Coverity complain because
either the dereference is unsafe or the NULL check is unnecessary. Upon
inspection, this pointer is guaranteed to never be NULL because it is
from the Linux kernel VFS. The calls into ZFS simply would not make
sense if this pointer were NULL, so the NULL check is unnecessary.
Reported-by: Coverity (CID 1527260)
Reported-by: Coverity (CID 1527262)
Reviewed-by: Mariusz Zaborski <mariusz.zaborski@klarasystems.com>
Reviewed-by: Youzhong Yang <yyang@mathworks.com>
Signed-off-by: Richard Yao <richard.yao@alumni.stonybrook.edu>
Closes#14170
945b407486 neglected to `NULL` check
`tx->tx_objset`, which is already done in the function. This upset
Coverity, which complained about a "dereference after null check".
Upon inspection, it was found that whenever `dmu_tx_create_dd()` is
called followed by `dmu_tx_assign()`, such as in
`dsl_sync_task_common()`, `tx->tx_objset` will be `NULL`.
Reported-by: Coverity (CID 1527261)
Reviewed-by: Mariusz Zaborski <mariusz.zaborski@klarasystems.com>
Reviewed-by: Youzhong Yang <yyang@mathworks.com>
Signed-off-by: Richard Yao <richard.yao@alumni.stonybrook.edu>
Closes#14170
Linux defaults to setting "failfast" on BIOs, so that the OS will not
retry IOs that fail, and instead report the error to ZFS.
In some cases, such as errors reported by the HBA driver, not
the device itself, we would wish to retry rather than generating
vdev errors in ZFS. This new property allows that.
This introduces a per vdev option to disable the failfast option.
This also introduces a global module parameter to define the failfast
mask value.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Mariusz Zaborski <mariusz.zaborski@klarasystems.com>
Sponsored-by: Seagate Technology LLC
Submitted-by: Klara, Inc.
Closes#14056
Have tcpstats (netstat -s) differentiate between received and sent
ECN-marked packets. Also account for IP ECN bits (on TCP packets)
even when the tcp session has not negotiated ECN support.
Event: IETF 115 Hackathon
Reviewed By: glebius, tuexen, #transport
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D37314
Intel 82599 has errata related to IPv4 UDP frames with zero checksum.
It reports such datagrams with L4 integrity errors in IXGBE_XEC
register. And after afb1aa4e6d commit such errors are reported
via IFCOUNTER_IERRORS. This confuses users, since actually all frames
are handled correctly by the system.
To workaround the problem, let's ignore the XEC register value for
82599 cards for now.
PR: 266048
Discussed with: erj
MFC after: 1 week
Sponsored by: Yandex LLC