ixgbe: Fix incomplete speed coverage in link status logging
Originally ixgbe_if_update_admin_status() only handled 1G and 10G speeds,
causing any other speeds to display as "1 Gbps" in link status logs.
This issue is fixed by adding link speed to string conversion logic through
the introduction of a helper function, ixgbe_link_speed_to_str(), which
corrects the misleading logs to reflect accurate link speeds.
Signed-off-by: Yogesh Bhosale yogesh.bhosale at intel.com
PR: 288960
Reported by: Mike Belanger - QNX
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D52442
loader/efi: return error from efi_find_framebuffer
Also return actual errno values in other code paths.
(suggested by tsoome)
Reviewed by: tsoome, imp
Differential Revision: https://reviews.freebsd.org/D52432
editors/vim: Update to 9.1.1744 and handle wayland properly
Add --without-wayland for everything except the gtk3 FLAVOR. That
flavor now has a hard dep on wayland (it's already present from the
default gtk30 and libxkbcommon configurations).
This is a NOOP for everybody except gtk3 users who explicitly disabled
wayland in both gtk30 and libxkbcommon. The only effect for those
users is that wayland is now a LIB_DEP. There is no runtime effect
either way.
In the below PR, Piotr identified that vim will eagerly link against
wayland if present, even for a pure-console build.
The only toolkit that vim uses that can use wayland is gtk3, so
we now specify --without-wayland for everything else.
To complicate things, wayland support is optional in the gtk30 and
libxkbcommon ports. If either of those ports are built with wayland,
[11 lines not shown]
sockstat: fix the -j option with piped output after libxo integration
The legacy code handling -j in display() was causing xo_finish() to be
skipped. It has also been causing a memory leak since 0726c6574f8
(sockstat: Add automatic column sizing and remove -w option)
Fixes: 7b35b4d1963 (sockstat: add libxo support)
MFC after: 1 week
Reported by: glebius
Reviewed by: glebius
Sponsored by: ConnectWise
Pull Request: https://github.com/freebsd/freebsd-src/pull/1842
'kern.proc.groups' sysctl knob: Restore outputting the effective GID
In particular, fixes 'procstat -s' on a live system (for processes with
more than 16 groups).
Reviewed by: kib, emaste
Fixes: be1f7435ef218b1d ("kern: start tracking cr_gid outside of cr_groups[]")
MFC after: 9 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D52261
kinfo_proc: Restore outputting the effective GID
In particular, fixes 'procstat -s' on a live system or a core file (only
if there are less than 16 groups).
Reviewed by: kib
Fixes: be1f7435ef218b1d ("kern: start tracking cr_gid outside of cr_groups[]")
MFC after: 9 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D52259
kvm_proclist(): Restore outputting the effective GID
In particular, fixes 'procstat -s -M' (only if there are less than 16
groups).
Reviewed by: kib, emaste
Fixes: be1f7435ef218b1d ("kern: start tracking cr_gid outside of cr_groups[]")
MFC after: 9 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D52260
imgact_elf: procstat groups: Restore sending the effective GID
Fixes 'procstat -s' run on a core file when the number of groups in
effect at the moment of core dump exceeds KI_NGROUPS (16).
Reviewed by: kib
Fixes: be1f7435ef218b1d ("kern: start tracking cr_gid outside of cr_groups[]")
MFC after: 9 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D52258
nfscl: Restore sending the effective GID to the server
Fixes: be1f7435ef218b1d ("kern: start tracking cr_gid outside of cr_groups[]")
MFC after: 9 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D52256
nfs: newnfs_setroot(): Remove an obsolete comment
This comment is obsolete, as:
1. This code is FreeBSD-specific and is not shared with other BSDs.
2. With our recent changes in commit be1f7435ef218b1d ("kern: start
tracking cr_gid outside of cr_groups[]"), all of NetBSD, OpenBSD and
FreeBSD have the effective GID in a separate field (DragonFlyBSD
remains to this day an outlier).
MFC after: 9 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D52254
hwpmc: On attach, fix allowing a PMC's owner to attach it to itself
The returned value in this case was wrong, and would basically prevent
some PMC's owner process to attach that PMC to itself although the
security checks underneath would have allowed it.
Now that this early return has been fixed, its block basically becomes
a performance short-circuit which has no effect from a functional
standpoint.
Fixes: ebccf1e3a6b1 ("Bring a working snapshot of hwpmc(4), ...")
MFC after: 9 days
Sponsored by: The FreeBSD Foundation
hwt: On attach, ensure owner is a target effective GID's member
This restores a check that existed prior to commit be1f7435ef218b1d
("kern: start tracking cr_gid outside of cr_groups[]").
Fixes: be1f7435ef218b1d ("kern: start tracking cr_gid outside of cr_groups[]")
MFC after: 9 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D52253
hwpmc: On attach, ensure owner is a target effective GID's member
This restores a check that existed prior to commit be1f7435ef218b1d
("kern: start tracking cr_gid outside of cr_groups[]").
While here, improve pmc_can_attach()'s style by changing the type of
'decline_attach' to 'bool', fixing tests on it, adding missing
parentheses to 'return' statements, and by changing its return value
type to 'bool'.
Fixes: be1f7435ef218b1d ("kern: start tracking cr_gid outside of cr_groups[]")
MFC after: 9 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D52252
