ice(4): Fix link speed after changing cable type
When interface was connected to a link partner with a cable
type limitting maximum supported speed, e.g. SFP+ cable
in 25G port, driver incorrectly saved a supported speed
as the user configured speed. This prevented interface
from using all supported speeds after switching cable to SFP28.
Link was established at 10G as supported by previously used
SFP+ cable. Don't set user requested speed unless actually
configured by an user, to allow automatic selection of highest
available speed. Only when user sets custom config
using advertise_speed sysctl save it and try
to apply after cable is changed.
Also don't save initial supported speeds if FW supports
reporting default PHY config.
Signed-off-by: Krzysztof Galazka <krzysztof.galazka at intel.com>
[5 lines not shown]
ice(4): Add support for new E810-XXV-2 adapters
Add two new subdevice IDs for E810-XXV-2 and E810-XXV-2 for OCP 3.0.
Signed-off-by: Krzysztof Galazka <krzysztof.galazka at intel.com>
Reviewed by: kbowling, erj, mateusz.moga_intel.com
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D54069
(cherry picked from commit bea6f7d02dfbef8f8209f0ca5f1d76877d549f46)
ice(4): Add support for 40G maximal PMD speed
E823 backplane devices may support 40G as maximal PMD speed.
Extend port topology reading logic to handle this case.
While at that fix indentation according to FreeBSD style(9).
Signed-off-by: Krzysztof Galazka <krzysztof.galazka at intel.com>
Tested by: gowtham.kumar.ks_intel.com
Approved by: kbowling (mentor), erj (mentor)
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D53587
(cherry picked from commit c6212b7da110d82b1d0086ec525deb216993021e)
tools/build: Don't set RANLIB for non-FreeBSD builds
RANLIB is not used by our build, so there is no need to set it.
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58156
tests: Fix build if TIOCSTI is not defined
Some downstream projects (e.g. ElectroBSD) have removed the TIOCSTI
We already have some components (such as mail and tcsh) that build
without TIOCSTI defined. This is (existing portability support in those
projects.
Simplify things for downstreams by extending this approach to this
additional TIOCSTI user.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D50614
(cherry picked from commit 52a2b4bc5da21d7a54cb16b9450196244b59b8c0)
OptionalObsoleteFiles: Add missing headers
The header files for dialog, figpar, dpv were never listed.
Fixes: bc6c827078b7 ("OptionalObsoleteFiles: Add figpar to dialog section")
(cherry picked from commit acf6518a2d6f33fb56c861861cbad0c0cb56817e)
riscv/pmap.c: Handle spurious kernel page faults in critical sections
The Privileged ISA specification permits caching of invalid PTEs
12.2.1. Supervisor Memory-Management Fence Instruction), which may
result in a spurious page fault. Such faults are handled by 'pmap_fault'
which locks the kernel pmap before inspecting and possibly updating the
offending L2 entry.
Unfortunately, spurious faults may also occur when we're already holding
the kernel_pmap lock or running in a critical section, where any attempt
to grab the pmap lock will result in a kernel panic.
Fix this avoidable panic by performing a lockless lookup to determine
whether a valid kernel mapping exits and flushing appropriate TLB entry.
Differential Revision: https://reviews.freebsd.org/D56925
Reviewed by: jrtc27, mhorne, markj
riscv/mp_machdep.c: Flush the TLB after releasing APs
Spurious page faults caused by cached invalid entries may occur when
starting APs and potentially panic the kernel if we're running in
a non-sleepable context.
Fix this avoidable panic by flushing the TLB after the AP is released.
Differential Revision: https://reviews.freebsd.org/D57003
Reviewed by: markj
riscv/pmap.c: Add a ddb command for inspecting PTEs
This change implements the equivalent of the amd64-specific
'show pte' ddb command used to dump the page table entries
associated with a specific virtual address.
Differential Revision: https://reviews.freebsd.org/D56924
Reviewed by: mhorne
build: Stop testing LINKER_FEATURES for ifunc and build-id
These features are available in all supported linkers, and we can expect
that they'll be supported by any GNU-compatible linker that we'd use to
link FreeBSD.
Reviewed by: imp, kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55676
(cherry picked from commit 96294c22f7e54a48df44c86a4ee5848e71ac4470)
sched_shim: Drop the no-ifunc case
Now all architectures support kernel ifunc resolvers. Therefore, the
alternate implementation can be removed.
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55114
(cherry picked from commit 0d3652f67d246348e2c017205c6782caf4484449)
riscv: implement kernel ifunc resolution
This completes the set of architectures implementing this feature.
Move the calls to sched_instance_select() and link_elf_ireloc() later in
initriscv(), after identify_cpu(0). There will be more information
available to any resolver functions at this time.
Reviewed by: imp, kib
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55082
(cherry picked from commit cf41d1113377c44be5aad20c2f7ff2c5324ca89f)
x86/local_apic.c: Fiddle with thermal LVT slot only if supported
The thermal LVT slot does not necessarily exist.
According to Intel's Software Developers Manual, for Intel processors
supporting 64-bit operation (amd64), probably even the earliest ones
should have a local APIC with such a slot (the slot was introduced with
Pentium 4 and Xeon processors according to the manual, and the 64-bit
implementation in some later versions of them). AMD's Architecture
Programmer's Manual also seems to imply that all AMD processors
supporting amd64 should have the slot too. So this change may not be
needed when i386's code is dropped, but it does not hurt to have it, and
it might ease possible MFCs.
Change the signature of lapic_enable_thermal() so that it can report
failure (if there is no local APIC or if there is no thermal LVT slot).
Reviewed by: bnovkov, kib
MFC after: 2 weeks
[2 lines not shown]
x86/local_apic.c: Factor out version read and max LVT slot computation
This makes the code slightly more compact and easier to read.
No functional change intended.
Reviewed by: bnovkov
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58110
linux: Add TCP_INFO support
Implement the getsockopt for TCP_INFO by mapping FreeBSD's version to
what Linux expects.
(cherry picked from commit 925ca9b8355d10a0dc85175dc865095c9b3370c4)
rk_gpio: implement PIC masking methods and mask unhandled IRQs
The Rockchip GPIO controller implements PIC operations for the INTRNG
framework but is missing four masking methods that INTRNG calls during
the filter/ithread handoff: pic_disable_intr, pic_enable_intr,
pic_pre_ithread, pic_post_ithread.
Without them, level-sensitive interrupt sources connected to a
Rockchip GPIO pin re-fire continuously while their ithread runs. On
a RockPro64 with a FUSB302B Type-C controller (i2c) attached to
gpio1 INT_N, the system enters a ~210 kHz interrupt storm the moment
the fusb302 driver attaches and INT_N goes low.
Two complementary changes:
1. Add the four pic_disable_intr/pic_enable_intr/pic_pre_ithread/
pic_post_ithread method bodies. Each toggles the pin's
RK_GPIO_INTMASK bit so the source is masked during the in-flight
ithread window and unmasked on return, honouring the generic
[19 lines not shown]
crashinfo: Create core.txt.last symlink
When saving a coredump, savecore(8) maintains .last symlinks for the
info and vmcore artifacts, but not for the crashinfo text report.
Make crashinfo(8) create the link, pointing at the current
core.txt.<bounds> file.
This makes /var/crash/core.txt.last track the same core dump as
info.last and vmcore.last.
[mhorne: I tweaked the submission, such that the link will be created as
soon as the core.txt.X file is generated; not only after a successful
report has been written.]
Signed-off-by: Ricardo Branco <rbranco at suse.de>
Reviewed by: mhorne
MFC after: 1 week
Pull Request: https://github.com/freebsd/freebsd-src/pull/2199
[2 lines not shown]
hwpmc_amd: Avoid using PMCs if in use by firmware
Some firmwares use the PMCs to monitor OS performance. We can't be
certain that the BIOS would detect any change to the counters if we
reprogram them. In cases where the firmware is using the PMCs to
control power management this could have dangerous side effects or
unexpected performance effects.
During initialization, detect if any of the counters are enabled and
fail if so.
Reported by: Sandipan Das
Reviewed by: mhorne
MFC after: 1 week
Sponsored by: Netflix
Pull Request: https://github.com/freebsd/freebsd-src/pull/2277
(cherry picked from commit cf469ab83012ee47d06bc89874b6c109f49446e0)
hwpmc: Disable AMD PMCs if in an unsupported VM
AMD does not have a CPUID bit to indicate the lack of K8 PMCs. If all
other PMC features are not present we should test an event selector to
see if it stores and returns a value. If the VM is implemented
correctly, this should result in a #GP on the initial wrmsr_safe. Bhyve
and a few other VMs ignore writes, so I got one step further and test
that it retains the OS and USR bits.
Tested on Zen 5 native and a Zen 5 Bhyve virtual machine. This code
should not run on any recent hardware, except in a VM, as it checks that
the core counter extension is missing.
PR: 268943
Reported by: Sandipan Das, John F. Carr <jfc at mit.edu>
Reviewed by: mhorne, imp
Sponsored by: Netflix
MFC after: 1 week
Pull Request: https://github.com/freebsd/freebsd-src/pull/2272/changes
[2 lines not shown]
