devel/electron42: Bump port revision for expiration notice
Fixes: 24b2edf893f6 (devel/electron42: Deprecate and set to expire on 2026-12-31)
MFH: 2026Q4
(cherry picked from commit 4ac6636c3ad446da17471011dddf5bb4dba7cfe9)
Pull up following revision(s) (requested by riastradh in ticket #1420):
sys/external/bsd/drm2/dist/drm/nouveau/nouveau_fence.c: revision 1.18
nouveau(4): Fix return value of fence wait.
kpause(9) returns EAGAIN/EWOULDBLOCK when it times out, which is
perfectly normal and expected here with an internal one-tick timeout
which should just go through another loop iteration. This function
is expected to return the number of ticks left to wait when done, so
it reports timeout by returning zero, and is forbidden to fail with
EAGAIN/EWOULDBLOCK.
This is also forbidden to fail with EINTR -- on interruption it must
fail with the Linux ERESTARTSYS instead. So map EINTR to that too
while here.
PR kern/59772: i386 11.0_BETA system crash (Xorg nouveau ?)
devel/electron42: Bump port revision for expiration notice
Fixes: 24b2edf893f6 (devel/electron42: Deprecate and set to expire on 2026-12-31)
MFH: 2026Q4
Pull up following revision(s) (requested by riastradh in ticket #1419):
sys/arch/x86/x86/efi_machdep.c: revision 1.7
sys/arch/x86/x86/efi_machdep.c: revision 1.8
x86/efi: Bypass kASAN memcpy when copying the efi runtime.
Fixes crash at boot with `options KASAN' enabled on EFI systems.
We could try to find some way to exclude the EFI runtime mappings
from kASAN, e.g. by hacking kasan_md_unsupported. But there's a lot
of detailed exclusions to pass through to that (every entry in the
EFI memory map), and this is the only memcpy in the whole kernel that
all those details are likely to be applicable.
PR kern/60391: kernel panic in efi_init() with "options KASAN"
x86/efi_machdep.c: Nix extra blank line.
[2 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #576):
sys/arch/x86/x86/efi_machdep.c: revision 1.7
sys/arch/x86/x86/efi_machdep.c: revision 1.8
x86/efi: Bypass kASAN memcpy when copying the efi runtime.
Fixes crash at boot with `options KASAN' enabled on EFI systems.
We could try to find some way to exclude the EFI runtime mappings
from kASAN, e.g. by hacking kasan_md_unsupported. But there's a lot
of detailed exclusions to pass through to that (every entry in the
EFI memory map), and this is the only memcpy in the whole kernel that
all those details are likely to be applicable.
PR kern/60391: kernel panic in efi_init() with "options KASAN"
x86/efi_machdep.c: Nix extra blank line.
[2 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #1418):
sys/kern/exec_elf.c: revision 1.108
sys/kern/exec_elf.c: revision 1.109
sys/sys/exec_elf.h: revision 1.187
sys/sys/exec_elf.h: revision 1.188
exec_elf: Ignore freedesktop.org dlopen ELF notes.
PR kern/60901: Unknown elf note type 1081871370
exec_elf: Nix diagnostic messages for all (unknown) fd.o notes.
Same as for unknown GNU notes. Shaves off a tiny bit of code in
non-DIAGNOSTIC builds, saves us some trouble when fd.o invariably
adds more metadata not relevant to execution semantics.
PR kern/60901: Unknown elf note type 1081871370
Pull up following revision(s) (requested by riastradh in ticket #575):
sys/kern/exec_elf.c: revision 1.108
sys/kern/exec_elf.c: revision 1.109
sys/sys/exec_elf.h: revision 1.187
sys/sys/exec_elf.h: revision 1.188
exec_elf: Ignore freedesktop.org dlopen ELF notes.
PR kern/60901: Unknown elf note type 1081871370
exec_elf: Nix diagnostic messages for all (unknown) fd.o notes.
Same as for unknown GNU notes. Shaves off a tiny bit of code in
non-DIAGNOSTIC builds, saves us some trouble when fd.o invariably
adds more metadata not relevant to execution semantics.
PR kern/60901: Unknown elf note type 1081871370
Pull up following revision(s) (requested by riastradh in ticket #1417):
sys/dev/i2c/i2c.c: revision 1.109
i2c(4): Avoid leaking kernel heap memory to userland.
PR kern/60913: iic(4): I2C_IOCTL_EXEC can copy out an uninitialised
buffer
Pull up following revision(s) (requested by riastradh in ticket #574):
sys/dev/i2c/i2c.c: revision 1.109
i2c(4): Avoid leaking kernel heap memory to userland.
PR kern/60913: iic(4): I2C_IOCTL_EXEC can copy out an uninitialised
buffer
Pull up following revision(s) (requested by riastradh in ticket #1416):
etc/rc.d/network: revision 1.86
PR misc/60836 - Be more careful with /etc/ifconfig.* cloner configs
Only config cloner interfaces when an /etc/ifconfig.${cloner}N file
exists, if N is completely numeric.
Pull up following revision(s) (requested by riastradh in ticket #573):
etc/rc.d/network: revision 1.86
PR misc/60836 - Be more careful with /etc/ifconfig.* cloner configs
Only config cloner interfaces when an /etc/ifconfig.${cloner}N file
exists, if N is completely numeric.
Pull up following revision(s) (requested by riastradh in ticket #1415):
sys/external/bsd/common/include/linux/rcupdate.h: revision 1.9
drm: Fix rcu_replace_pointer.
This Linux API macro takes an _lvalue_ expression for an object, not
a pointer to the object -- unlike, e.g., the atomic_load/store
functions. So we can't copy its value into a local variable (to
avoid duplicate macro argument expansion) and then assign the local
variable with rcu_assign_pointer because that will only modify the
local copy, not the caller's lvalue!
Rename the macro parameters to make this clearer so it doesn't trip
me up again next time I read this.
Probably fixes dozens of graphics problems on a generation of Intel
hardware. Derp!
PR kern/60980: rcu_replace_pointer() fails to update the original pointer
Pull up following revision(s) (requested by riastradh in ticket #572):
sys/external/bsd/common/include/linux/rcupdate.h: revision 1.9
drm: Fix rcu_replace_pointer.
This Linux API macro takes an _lvalue_ expression for an object, not
a pointer to the object -- unlike, e.g., the atomic_load/store
functions. So we can't copy its value into a local variable (to
avoid duplicate macro argument expansion) and then assign the local
variable with rcu_assign_pointer because that will only modify the
local copy, not the caller's lvalue!
Rename the macro parameters to make this clearer so it doesn't trip
me up again next time I read this.
Probably fixes dozens of graphics problems on a generation of Intel
hardware. Derp!
PR kern/60980: rcu_replace_pointer() fails to update the original pointer
textproc/p5-Jq: new port had been added (+)
Jq.pm is a Perl module binding to Jq which inputs and
outputs are Perl data objects that can be represented
as JSON.
ubldr: Pass the whole loaderdev name to disk_parsedev()
p - 4 is one byte before the string for 3-letter types, so whether
loaderdev=mmc0p2 parsed depended on that byte. disk_parsedev() now skips any
name prefix itself.
Reported by: llm-postcr
Reviewed by: imp
Approved by: imp
Fixes: d18ed8e19c3c ("stand: Try to parse vdisk correctly")
Sponsored by: Netfix
Differential Revision: https://ron-dev.freebsd.org/FreeBSD/src/pulls/105
Pull up following revision(s) (requested by riastradh in ticket #1414):
sys/external/bsd/drm2/linux/linux_ww_mutex.c: revision 1.18
linux ww_mutex: Nix another assertion that trips in sketchy path.
Under the premise (explained in the comment above) that it is
legitimate for the upstream Linux code to do ww_mutex_trylock on a
mutex already held by the current thread, we can't assert
mutex->wwm_state != WW_WANTOWN ||
mutex->wwm_u.ctx->wwx_owner != curlwp
any more than we can assert
mutex->wwm_state != WW_CTX ||
mutex->wwm_u.ctx->wwx_owner != curlwp
because if the latter condition is possible, then any concurrent
[7 lines not shown]
Pull up following revision(s) (requested by riastradh in ticket #571):
sys/external/bsd/drm2/linux/linux_ww_mutex.c: revision 1.18
linux ww_mutex: Nix another assertion that trips in sketchy path.
Under the premise (explained in the comment above) that it is
legitimate for the upstream Linux code to do ww_mutex_trylock on a
mutex already held by the current thread, we can't assert
mutex->wwm_state != WW_WANTOWN ||
mutex->wwm_u.ctx->wwx_owner != curlwp
any more than we can assert
mutex->wwm_state != WW_CTX ||
mutex->wwm_u.ctx->wwx_owner != curlwp
because if the latter condition is possible, then any concurrent
[7 lines not shown]
[X86] Add WritePack scheduler classes (#240819)
Split off PACKSSUS DW/WB instructions from WriteShuffle class to remove
need for most custom overrides
znver4 - fixes failure to override rm variants to correctly use FPU1/2
pipes like the rr variants
SapphireRapids and C864GM7/8 - still have overrides for their predicated
instructions - best to leave them until #240761 is finalized.
Fixes #240425
editors/xwpe: update to 1.6.9
Switch to the new maintained branch of xwpe.
The project has been (relatively) recently resumed elsewhere by Juan
Manuel Mendez Rey. Most distributions packaging xwpe have already
switched to this repo.
Thanks to zakinko at snowrabbit.org for providing diffs. See pkg/#60821
# CHANGES (since 1.5.30a)
Bugs fixed in 1.6.x:
* Options > Editor: checkboxes and radio buttons could not be ticked in xwpe
(X11) -- fixed (1.6.3). Space, mouse-click and the Alt-<letter> hotkey all
flipped the option's value, but in X11 nothing was drawn, so the box looked
unchanged ("I can't mark it"). Root cause: with NEWSTYLE the dialog redrew
the marks via e_make_xrect_abs -- a 3D bevel in the extbyte overlay whose
checked vs unchecked states differ only by one highlight bit, visually
[1622 lines not shown]
[InstCombine][JumpTableToSwitch] Make a helper for iterating globals elements
Currently there are at least two folds/passes that read elements of a constant
global:
- instcombine's `foldCmpLoadFromIndexedGlobal`
- jump-table-to-switch, when reading the functions from a jump table
and a third one is being written for simplifycfg in PR #229035.
The code to do that is not trivial, especially in its most general form. The
two implementation above currently have different limitations, and PR #229035
has yet another buggy and limited implementation of it.
This PR adds a helper class `ConstGlobalIterator` that analyzes a load from a
global and allows iterating the accessed elements. Current implementation is a
copy of the instcombine's: that's the most general version we have today
(though even that has limitations, e.g. it gives up when the stride is smaller
than the load size).
[11 lines not shown]
