The arm64 unknown exception will be raised when we execute an
instruction that id invalid or disabled. To help debug these print
the instruction that failed.
Sponsored by: The FreeBSD Foundation
With soft updates enabled, an INVARIANTS panic is hit in ffs_unmount().
The problem occurs in ffs_mount() when upgrading a mount from ro->rw.
During a mount update, the soft update code gets set up but doesn't get
cleaned up if namei() fails when looking up the disk device.
Avoid this scenario by looking up the disk device first and bail early
if the namei() lookup fails.
PR: 256511
MFC After: 2 weeks
Reviewed by: mckusick, kib
Differential Revision: https://reviews.freebsd.org/D30870
This reverts commit 7d8700bc29.
Reason for revert: the patch is incomplete. 64-bit operation
is supported fully in SDHCI v4.0, v3.0 does it only for ADMA mode.
This differentiation is missing and should be taken into consideration
in case the reverted code is re-introduced.
Reported by: mmel
It appears to have introduced a regression on arm64, possibly due to the
fact that the pcpu pointer is reloaded outside of the critical section
in _rm_rlock(). Until this is resolved one way or another, let's
revert.
Reported by: Ronald Klop <ronald-lists@klop.ws>
Sponsored by: The FreeBSD Foundation
ctfdump handles v2 and v3. ctfconvert now emits only CTFv3, whereas
ctfmerge can merge v2 and v3 containers into v3 containers.
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34364
The general aim in this and subsequent patches is to minimize the
amount of code that directly references CTF types such as ctf_type_t,
ctf_array_t, etc. To that end, introduce some routines similar to the
existing fbt_get_ctt_size() (which exists to deal with differences
between v1 and v2) and change ctf_lookup_by_id() to return a void
pointer.
Support for v2 containers is preserved.
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34361
These are based on definitions added to binutils' libctf. Specifically:
- Type IDs are now encoded in 32 bits rather than 16, changing the
layout of ctf_type_t, ctf_array_t, ctf_member_t and ctf_lmember_t.
- Type info is encoded in 32 bits rather than 16. The type "kind" is
extended from 5 bits to 6, and the type "vlen" is extended from 10
bits to 25.
The main upside is that we remove the current limit, imposed by CTFv2,
of 2^{15} distinct types in the main kernel executable. Other limits,
such as that on the number of elements in an enum, imposed by the vlen
limit, are also raised.
This change adds v2 and v3 flavours of macros and type definitions which
differ between the two versions. Compatibility is preserved for now by
having generic names refer to the v2 definitions, so, e.g., ctf_type_t
is still a v2 type.
No functional change intended.
Reviewed by: Domagoj Stolfa
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34360
Use sys/ctf.h to provide various definitions required to parse the CTF
header. No functional change intended.
Reviewed by: Domagoj Stolfa, emaste
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34359
Use it instead of the existing ctf.h from OpenSolaris. This makes it
easier to use CTF in the core kernel, and to extend the CTF format to
support wider type IDs.
The imported ctf.h is modified to depend only on _types.h, and also to
provide macros which use the "parent" bit of a type ID to refer to types
in a parent CTF container.
No functional change intended.
Reviewed by: Domagoj Stolfa, emaste
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34358
To help with switching to a vdso sigtramp switch to passing through the
sigcode function when entering a signal. This ensures the return address
is within the function.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33690
The new dev.netmap.max_bridges sysctl tunable can be set in
loader.conf(5) to change the default maximum number of VALE
switches that can be created. Current defaults is 8.
MFC after: 2 weeks
Symptom: when a single extmem memory region is provided to netmap
multiple times, for multiple interfaces, the memory region is
never released by netmap once all the existing file descriptors
are closed.
Fix the relevant condition in netmap_mem_drop(): release the memory
when the last user of netmap_adapter is gone, rather then when
the last user of netmap_mem_d is gone.
MFC after: 2 weeks
Despite the buffer taken from cache or free list, it still can be
locked, due to 'lockless lookup' in getblkx() potentially operating on
the freed buffers. The lock is transient, but prevents the use of
LK_NOWAIT there for the goal of neutralizing WITNESS.
Just use LK_NOWITNESS.
Reported and tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Full CCB header overwrites made frees go into wrong zones, causing
kernel panics. Instead of copying full header use xpt_setup_ccb(),
since the only field I see used from all the header is target_id.
PR: 262263
If we can't determine the TSC frequency using CPU registers, we need to
give a chance for Hyper-V drivers to register a timecounter (during
SI_SUB_HYPERVISOR) since an emulated 8254 might not be available.
Thus, split probe_tsc_freq() into early and late stages, and wait until
the latter to attempt calibration using a reference clock.
Fixes: 84369dd523 ("x86: Probe the TSC frequency earlier")
Reported and tested by: khng, Shawn Webb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34444
As in commit c3d830cf7c, we should finalize CPU identification before
probing the TSC frequency.
Fixes: 84369dd523 ("x86: Probe the TSC frequency earlier")
Reported by: khng
The previous commit (56429daea2) that updated the driver included a
bug where a variable was undefined when ALTQ was enabled; this fixes
that issue to declare the missing variable. This wasn't caught before
because we don't use ALTQ, and so it fell on the Jenkins CI's LINT
builds to catch it.
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Reported by: Jenkins CI
MFC after: 3 days
MFC with: 56429daea2
Sponsored by: Intel Corporation
This change enables the user to control 2.5G and 5G autonegotiation
speeds via advertise_speed sysctl for X550T devices. Due to reported
interoperability issues with switches, 2.5G and 5G speeds will not be
advertised by default.
Signed-off-by: Piotr Pietruszewski <piotr.pietruszewski@intel.com>
Co-authored-by: Krzysztof Galazka <krzysztof.galazka@intel.com>
Tested by: gowtham.kumar.ks@intel.com
MFC after: 3 days
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D26245
This patch adds checks of a VF link state provided by PF via mailbox
API. Such change enables the PF to disable a VF administratively.
Since command needed by the PF to control the VF is introduced in
mailbox api version 1.2, this patch also bumps supported mailbox api
version to 1.2.
Co-authored-by: Krzysztof Galazka <krzysztof.galazka@intel.com>
Reviewed By: kbowling@
Tested by: lukasz.szczepaniak@intel.com
MFC after: 3 days
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D32004
- Adds FW logging support
- Once enabled, this lets the firmware print event and error messages
to the log, increasing the visibility into what the hardware is
doing; this is useful for debugging
- General bug fixes
- Adds inital DCB support to the driver
- Notably, this adds support for DCBX to the driver; now with the
fw_lldp sysctl set to 1, the driver and adapter will adopt a DCBX
configuration sent from a link partner
- Adds statistcs sysctls for priority flow control frames
- Adds new configuration sysctls for DCB-related features: (VLAN) user
priority to TC mapping; ETS bandwidth allocation; priority flow
control
- Remove unused SR-IOV files (until support gets added)
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Tested by: jeffrey.e.pieper@intel.com
MFC after: 3 days
MFC with: 213e91399b, e438f0a975
Relnotes: yes
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D34024
Summary:
Some targets are not responding to the FLOGI in point-to-point topology,
If the pt2pt discovery is done, Ignore the FLOGI failure.
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D34422
This code was not touched when all other user-space sleep functions were
switched to sbintime_t and decoupled from hardclock. When it is possible,
convert supplied times into sbinuptime to supply directly to msleep_sbt()
with C_ABSOLUTE. This provides the timeout resolution of few microseconds
instead of 2 milliseconds, plus avoids few clock reads and conversions.
Reviewed by: vangyzen
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D34163
This reduces the size of diffs required to support different values of
vnsz2log. In CheriBSD, kernels for CHERI architectures have vnodes
larger than 512 bytes and require a value of 9.
Reviewed by: mjg
Obtained from: CheriBSD
Sponsored by: University of Cambridge, Google, Inc.
Differential Revision: https://reviews.freebsd.org/D34418
Implement MODULE_PNP_INFO() support in LinuxKPI for the Linux
MODULE_DEVICE_TABLE.
This will allow us to auto-load LinuxKPI PCI drivers (drm-kmod do
not currently as they attach to vgapci0 which in turn grabs the PCI
to my understanding) and make any loading from loader or kld_list in
rc.conf unnecessary; see devmatch(8) for more information.
We need to ensure there is a DRIVER_MODULE() (or probably just
a DECLARE_MODULE but that makes not much difference) before the
MODULE_PNP_INFO (which we otherwise would not need).
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: imp, hselasky, manu
Differential Revision: https://reviews.freebsd.org/D26651
Rather than having LinuxKPI return BUS_PROBE_DEFAULT, return
"one less" so that on conflict of IDs others would be preferred.
This means that iwm(4) will attach instead of iwlwifi(4) for the
chipsets iwm(4) supports and iwlwifi(4) only for the other--in iwm(4)
unsupported--chipsets. This is done so that we can enable auto-loading
of drivers but for the upcoming 13.1-Release people with working iwm(4)
will not yet be affected by iwlwifi(4).
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Add bsd_probe_return which a driver can set in their 'struct pci_driver'
definition to set a driver-sepcific LinuxKPI pci return value.
This is helpful in case of multiple drivers with overlapping IDs,
such as iwlwifi(4) and iwm(4).
Contrary to an earlier version we now assume 0 is not BUS_PROBE_SPECIFIC
(which no driver should really return these days) but the bss initialized
value (bsd_probe_return unset) and we will return BUS_PROBE_DEFAULT.
Suggested by: jhb
Reviewed by: jhb
Reviewed by: hselasky, imp (earlier versions)
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
X-MFC: new struct members need to go to the end for stable/13
Differential Revision: https://reviews.freebsd.org/D33915
Add serial-number sysctl if that fdt property exists and is a printable
string. While here, ensure that the hw.fdt sysctl values fit in the
buffers provided so that they will be NUL-terminated. Tested on
Raspberry Pi 3B+ and 4.
MFC after: 5 days
Reviewed by: manu imp
Differential Revision: https://reviews.freebsd.org/D34356
VGA hardware provides many different graphics and data access modes,
each with different capabilities and limitations.
VGA vt(4) graphics mode operates on blocks of pixels at a time. When a
given pixel block contains only two colours the vt_vga driver uses write
mode 3. When the block contains more than two colours it uses write
mode 0. This is done because two-colour write mode 3 is much more
efficient.
In practice write mode 3 is used most of the time, as there is often a
single foreground colour and single background colour across the entire
console. One common exception requiring the use of mode 0 is when the
mouse cursor is drawn over a background other than black, as we need
black and white for the cursor in addition to the background colour.
VGA's default 16-colour palette provides the same set of colours as the
system console, but in a different order. Previously we configured a
non-default VGA palette that had the same colours at the same indexes.
However, this caused anything drawn before the kernel started (drawn by
the loader, for instance) to change colours once the kernel configured
the new, non-default palette.
In 5e251aec86 we switched to leaving the default VGA palette in place,
translating console colour indexes to VGA colour indexes as necessary.
This translation was missed for the write mode 0 case for pixel blocks
with more than two colours.
PR: 261751
Reviewed by: adrian
MFC after: 1 week
Fixes: 5e251aec86 ("vt(4): Use default VGA palette")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34412