e1000: Disable autonomous PCH power gating after reset
Panther Point changed the reset value of CTRL_EXT.DPG_EN to enable
autonomous power gating. Clear it after hardware reset on Panther Point
and Nova Point controllers to prevent unexpected Tx/Rx hangs, packet
loss, or corruption.
MFC after: 1 week
ice(4): Add support for E835 CNSA 2.0 adapters
Added support for E835 adapters with post-quantum cryptographic (PQC)
algorithms in firmware/software signage and in SPDM attestation.
Signed-off-by: Pawel Sobczyk <pawel.sobczyk at intel.com>
Reviewed by: Miłosz Linkiewicz <milosz.linkiewicz at intel.com>
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D57868
SYSINIT: add SI_SUB_NUMA
This allows to parse ACPI tables and initialize VM domains before
SI_SUB_VM w/o a hack.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D58713
SYSINIT: add SI_SUB_FIRST
This allows to initialize mp_maxid, mp_ncpus and register APICs at the
most early stage, guaranteeing that those values will already be available
at SI_SUB_TUNABLES.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D58712
SYSINIT: add explicit SI_ORDER_LAST
Working on cleansing use of (SI_SUB_FOO + 1) construct through the kernel
I found a repeating pattern. Often a developer adds a module that depends
on certain subsystem to be fully instantiated and they want to put their
module SYSINIT right at the end of the SI_SUB_FOO. Such module usually
expects that nothing else within this subsystem shall depend on the
module.
The problem with SI_ORDER_ANY which practically was "the last" until this
change is that it is used very widely and people treat it literally as
"any", well, because this is what the name says. This lead to many parts
that could have dependencies later to be added as SI_ORDER_ANY.
So, our developer with the new subsystem that depends on SI_SUB_FOO has
three options:
1) Use SI_ORDER_ANY, but grep around ther kernel for other SI_SUB_FOO
entries to make sure that no dependencies are set to SI_ORDER_ANY. And in
[16 lines not shown]
bhyve: namescope virtio_msix to virtio.msix
The bhyve_config(5) variable `virtio_msix` is namescoped to
`virtio.msix`. Configurations that have the old variable will
automatically be mapped to the new one, with a warning message printed
out.
Relnotes: yes
Reviewed by: ziaee, markj
Differential Revision: https://reviews.freebsd.org/D58390
vm_object: Augment an assertion in vm_object_split()
In some private discussion it was pointed out that vm_object_split()'s
pattern of dropping the source object lock looks dangerous in that the
initial assumption that OBJ_ONEMAPPING is set may become false. In
practice I believe that the map lock holds this flag stable, but let's
assert that.
Reviewed by: alc, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D58766
pf: attempt to handle overlapping group and interface names
pf assumes that network groups and network interfaces share a namespace
(that is, a name is unused, a group or an interface, never both a the
same time). Unfortunately this assumption was broken when interface
renaming was introduced.
Attempt to cope with this rather than panicking. Note that this is a
band-aid, not a full solution. The correct fix is for the network stack
to go back to enforcing a single namespace for groups and interfaces.
PR: 297220
Reported by: Robert Morris
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit d2a5b5a86a92e86f77737273ab4b2e99da63c21d)
pf: check if a group has a kif before dereferencing it
It's possible for interface groups to not have had a pfi_kkif assigned to
them, so before we pass that pointer to pfi_kkif_update() we must check if it's
actually set.
We've seen panics such as this, where we get an address update for an interface
that belongs to a group without associated pfi_kkif:
Tracing pid 12 tid 100034 td 0xfffff80100d2a000
kdb_enter() at kdb_enter+0x33/frame 0xfffffe0067eed340
panic() at panic+0x43/frame 0xfffffe0067eed3a0
trap_pfault() at trap_pfault+0x3c9/frame 0xfffffe0067eed3f0
calltrap() at calltrap+0x8/frame 0xfffffe0067eed3f0
--- trap 0xc, rip = 0xffffffff8102ebd5, rsp = 0xfffffe0067eed4c0, rbp = 0xfffffe0067eed500 ---
pfi_kkif_update() at pfi_kkif_update+0x15/frame 0xfffffe0067eed500
pfi_kkif_update() at pfi_kkif_update+0x1fc/frame 0xfffffe0067eed550
pfi_ifaddr_event() at pfi_ifaddr_event+0x82/frame 0xfffffe0067eed5a0
srcaddr_change_event() at srcaddr_change_event+0xa7/frame 0xfffffe0067eed610
[20 lines not shown]
pf: attempt to handle overlapping group and interface names
pf assumes that network groups and network interfaces share a namespace
(that is, a name is unused, a group or an interface, never both a the
same time). Unfortunately this assumption was broken when interface
renaming was introduced.
Attempt to cope with this rather than panicking. Note that this is a
band-aid, not a full solution. The correct fix is for the network stack
to go back to enforcing a single namespace for groups and interfaces.
PR: 297220
Reported by: Robert Morris
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit d2a5b5a86a92e86f77737273ab4b2e99da63c21d)
pf: check if a group has a kif before dereferencing it
It's possible for interface groups to not have had a pfi_kkif assigned to
them, so before we pass that pointer to pfi_kkif_update() we must check if it's
actually set.
We've seen panics such as this, where we get an address update for an interface
that belongs to a group without associated pfi_kkif:
Tracing pid 12 tid 100034 td 0xfffff80100d2a000
kdb_enter() at kdb_enter+0x33/frame 0xfffffe0067eed340
panic() at panic+0x43/frame 0xfffffe0067eed3a0
trap_pfault() at trap_pfault+0x3c9/frame 0xfffffe0067eed3f0
calltrap() at calltrap+0x8/frame 0xfffffe0067eed3f0
--- trap 0xc, rip = 0xffffffff8102ebd5, rsp = 0xfffffe0067eed4c0, rbp = 0xfffffe0067eed500 ---
pfi_kkif_update() at pfi_kkif_update+0x15/frame 0xfffffe0067eed500
pfi_kkif_update() at pfi_kkif_update+0x1fc/frame 0xfffffe0067eed550
pfi_ifaddr_event() at pfi_ifaddr_event+0x82/frame 0xfffffe0067eed5a0
srcaddr_change_event() at srcaddr_change_event+0xa7/frame 0xfffffe0067eed610
[20 lines not shown]
ipfw: rework 32-bit KBI detection
When we run 14.X jail on 15.X host system previous implementation could
not correctly detect 32-bit KBI due to jails can overwrite osreldate.
Add special handling for this case and use detection using
IP_FW_DUMP_SOPTCODES and IP_FW_XGET sockopts version.
Reported by: Vova Grebenschikov
Fixes: 704ec5e68c44
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D56616
wpa: Update to 2.12
Fixes and new features include:
hostapd:
* support RSN overriding (e.g., WPA3-Personal Compatibility Mode)
* EHT/IEEE 802.11be/Wi-Fi 7
- more complete support
- fix message validation issues that could enable DoS attacks
- fix group key rekeying
* enable SAE group 20 by default if SAE-EXT-KEY is enabled
* reject unexpected SAE password identifier to avoid DoS attack against
a specific STA
* mandate use of SAE H2E when using password identifiers
* assign VLAN when using SAE with PMKSA caching
* support SPP A-MSDU negotiation
* support IEEE 802.11bi functionality
- changing SAE password identifiers
- EPPKE
[50 lines not shown]
release/Makefile.gce: migrate gsutil usages to gcloud CLI
Google Cloud recommends migrating from gsutil to gcloud storage CLI.
Update gce-do-upload target to use `gcloud storage buckets create` and
`gcloud storage cp` instead of `gsutil mb` and `gsutil cp` commands.
PR: conf/297016
(cherry picked from commit 4174cc2f69d36105a735b19fadc9c18497b02b1a)
release/Makefile.gce: migrate gsutil usages to gcloud CLI
Google Cloud recommends migrating from gsutil to gcloud storage CLI.
Update gce-do-upload target to use `gcloud storage buckets create` and
`gcloud storage cp` instead of `gsutil mb` and `gsutil cp` commands.
PR: conf/297016
(cherry picked from commit 4174cc2f69d36105a735b19fadc9c18497b02b1a)
usb: xhci: allow up to 1s for SET_ADDRESS
Some devices take a little longer, and the spec doesn't really seem to
mandate a maximum. The common path in usbd_req_set_address() has
already been bumped to 1s and I have a headset (Logitech H390) that does
need a little bit longer, so let's match it in xhci.
Reviewed by: aokblast
Differential Revision: https://reviews.freebsd.org/D58717
