Use correct NVRAM address for ISP28xx based HBAs to read NVRAM contents.
WWPN/WWNN and framesize are correctly read from NVRAM now.
PR: 271062
Reviewed by: imp, mav
Sponsored by: Technical University of Munich
Pull Request: https://github.com/freebsd/freebsd-src/pull/726
This covers the following HBAs:
ISP2812-based 64/32G Fibre Channel to PCIe Controller:
QLE2770 Single Port 32GFC PCIe Gen4 x8 Adapter
QLE2772 Dual Port 32GFC PCIe Gen4 x8 Adapter
QLE2870 Single Port 64GFC PCIe Gen4 x8 Adapter
QLE2872 Dual Port 64GFC PCIe Gen4 x8 Adapter
ISP2814-based 64/32G Fibre Channel to PCIe Controller:
QLE2774 Quad Port 32GFC PCIe Gen4 x16 Adapter
QLE2874 Quad Port 64GFC PCIe Gen4 x16 Adapter
While here, add required bits to support 64GB FC.
Default framesize is set to 2048 for ISP28xx based HBAs for now.
PR: 271062
Reviewed by: imp, mav
Sponsored by: Technical University of Munich
Pull Request: https://github.com/freebsd/freebsd-src/pull/726
This makes use of the alternate address space support in both GCC and
clang to access per-CPU data as accesses relative to GS:. The
original motivation for this is that it quiets verbose warnings from
GCC 12. However, this version is also much easier to read and
allows the compiler to generate better code (e.g. the compiler can
use a GS: memory operand directly in other instructions such as IMUL
and CMP rather than always MOVing to a temporary register).
The one caveat is that the current approach is very inefficient at -O0
since the compiler expects to load the 0 base offset from a global
variable instead of assuming it is 0 (even with the const).
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D40647
Strictly speaking, SYS V Aarch64 ABI does not states that lr should be
cleared, however gdb relies on lr and tryes to unwind stack further.
Reviewed by:
Differential Revision: https://reviews.freebsd.org/D40841
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
Replace the 'count' field in a trie node with a bitmap that
identifies non-NULL children. Drop the 'last' field, and use the
last bit set in the bitmap instead. In lookup_le, lookup_ge,
remove, and reclaim_all, use the bitmap to find the
previous/next/only/every non-null child in constant time by
examining the bitmask instead of looping across array elements
and null-checking them one-by-one.
A buildworld test suggests that this reduces the cycle count on
those functions that eliminate some null-checks by 4.9%, 1.5%,
0.0% and 13.3%.
Reviewed by: alc
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D40775
vmspace_free() is called redundantly in the 32-bit-compatible
path in sysctl_kern_proc_vm_layout(), causing a premature free
(possibly for the current address space). Remove the extra call.
PR: 272401
Reported by: marklmi at yahoo.com
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D40908
Refactor to eliminate duplicated rate and delay tables, with minor style
tweaks for changed lines. Remove an obsolete comment about needing to
convert from microseconds to ticks (that's done elsewhere). Remove
traiing whitespace in kbdcontrol.c.
Except for the new warning, no change in behavior
Sponsored by: DSS GmbH
Reviewed by: imp [minor style tweaks as well]
Pull Request: https://github.com/freebsd/pull/683
Differential Revision: https://reviews.freebsd.org/D38818
The layout of modspecific_t on both little endian and big endian are as
follows:
|0|1|2|3|4|5|6|7|
+-------+-------+
|uintval| |
+-------+-------+
|ulongval |
+-------+-------+
For the following code snippet:
CP(mod->data, data32, longval);
CP(mod->data, data32, ulongval);
It only takes care of little endian platforms that it truncates the
highest 32bit automatically. However on big endian platforms it takes
the highest 32bit instead. This eventually returns a garbage syscall
number to the 32bit userland.
Since modspecific_t's usage currently is for the use of syscall modules,
we only initialize modspecific32_t with uintval. Now on both BE and LE
64-bit platforms it always pick up the first 4 bytes.
Sponsored by: Juniper Networks, Inc.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D40814
MFC after: 1 week
To enable faster debug of customer issues Intel wants an end user to
gather information about PHY configuration and status to debug link and
connection issues in the field. For this reason the end user should
have possibility of obtaining PHYs registers values at runtime during
debugging.
Differential Revision: https://reviews.freebsd.org/D40354
Approved by: erj
flsll is inlined, or replaced by a smart binary search implementation,
on all architectures, and HAVE_INLINE_FLSLL is #defined always. So
remove code the the #undefined case.
Reviewed by: mhorne, tuexen
Differential Revision: https://reviews.freebsd.org/D40704
There is no longer be any point to maintaining a binary search routine
for ffs; inlines will always do it as well or better.
Reviewed by: mhorne
Differential Revision: https://reviews.freebsd.org/D40703
HAVE_INLINE_FLSLL is #defined always. This change assumes that where
__HAVE_INLINE_FLSLL is tested, the two leading underscores are a
mistake, and that the code will be better for using the efficient
flsll implementation.
Reviewed by: markj, mhorne
Differential Revision: https://reviews.freebsd.org/D40705
HAS_INLINE_FLS and similar macros are defined always.
Removes the redundant tests for these always-true conditions.
Reviewed by: mhorne
Differential Revision: https://reviews.freebsd.org/D40707
These are poorly optimized (linear search), and we now prefer the
compiler-provided routines on all platforms. These files can be removed.
Reviewed by: emaste, dougm
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40699
Use of compiler builtin ffs/ctz functions will result in optimized
instruction sequences when possible, and fall back to calling a function
provided by the compiler run-time library. We have slowly shifted our
platforms to take advantage of these builtins in 60645781d6 (arm64),
1c76d3a9fb (arm), 9e319462a0 (powerpc, partial).
Some platforms still rely on the libkern implementations of these
functions provided by libkern, namely riscv, powerpc (ffs*, flsll), and
i386 (ffsll and flsll). These routines are slow, as they perform a
linear search for the bit in question. Even on platforms lacking
dedicated bit-search instructions, such as riscv, the compiler library
will provide better-optimized routines, e.g. by using binary search.
Consolidate all definitions of these functions (whether currently using
builtins or not) to libkern.h. This should result in equivalent or
better performing routines in all cases.
One wart in all of this is the existing HAVE_INLINE_F*** macros, which
we use in a few places to conditionally avoid the slow libkern routines.
These aren't easily removed in one commit. For now, provide these
defines unconditionally, but marked for removal after subsequent
cleanup.
Removal of the now unused libkern routines will follow in the next
commit.
Reviewed by: dougm, imp (previous version)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40698
Simply speaking, being started the drm-kmod driver should create sysfs helpers,
which is «drm» class devices, with the unit number 0, 128 and, perhaps 64.
If a drm helper created by vgapci driver with the corresponding unit number
exists then the drm-kmod driver initialize it by the device_initialize() lkpi
method, otherwise drm-kmod driver create new «drm» device.
For hw, where two or more different GPU installed, it's not guaranteed that
the order of loading GPU drivers will be the same as the vgapci devices numbered.
I.e., on hw where vgapci0 is Nvidia GPU and vgapci1 is Intel GPU, when drm-kmod
loaded first it will use drm0 helper of vgapci0 device.
There is no problem for drm-kmod driver unless we do not traverse device
tree, as needed for https://reviews.freebsd.org/D38545.
drm-kmod is ok for this change as it has fallback to create corresponding
drm device.
Reviewed by:
Differential Revision: https://reviews.freebsd.org/D38546
- Add new DB_DEFINE_TABLE and DB_DECLARE_TABLE macros to define new
command tables. DB_DECLARE_TABLE is intended for use in headers
similar to MALLOC_DECLARE and SYSCTL_DECL.
DB_DEFINE_TABLE takes three arguments, the name of the parent table,
the command name, and the name of the table itself, e.g.
DB_DEFINE_TABLE(show, foo, show_foo) defines a new "show foo" table.
- DB_TABLE_COMMAND, DB_TABLE_COMMAND_FLAGS, DB_TABLE_ALIAS, and
DB_ALIAS_FLAGS allow new commands and aliases to be defined. These
are similar to the existing DB_COMMAND, etc. except that they take
an initial argument giving the name of the parent table, e.g.:
DB_TABLE_COMMAND(show_foo, bar, db_show_foo_bar)
defines a new "show foo bar" command.
This provides a cleaner interface than the ad-hoc use of internal
macros like _DB_SET that was required previously (e.g. in cxgbe(4)).
This retires DB_FUNC macro as well as the internal _DB_FUNC macro.
Reviewed by: melifaro, kib, markj
Differential Revision: https://reviews.freebsd.org/D40819
To that end add __enum_uint8_decl and __enum_uint8.
By default enums take 4 bytes, but vast majority of them have values
which would fit in a byte.
One can try to workaround the problem by using bitfields, like so:
enum some_small_enum foo:8;
but that's ugly and runs into trouble when using atomic_load (you can't
take an address of a bitfield, even if it is sized to a multiply of a
byte).
Both gcc 13 and clang support specifying the size, and for older
variants one can fallback to the "packed" attribute.
Names are mangled in order to avoid mix use with plain enum.
Reviewed by:
Differential Revision: https://reviews.freebsd.org/D39031
Argument unused since commit 93a0ba8f49.
Rename it to enforce_lkflags(), which seems to more aptly describe what it does.
[mjg: massaged the commit message a little]
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D40848
This will be used by bhyve and will allow the size to change, e.g. for SVE.
Reviewed by: markj
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D40131
In get_kernel_reg_masked we use update_lower_register to get the lower
value of two registers for a given field. It will return the entire
register value with just the single field updated.
Because of this get_kernel_reg_masked needs to use the returned value
directly rather than ORing each field together. Fix this by updating
the mask and returning that from get_kernel_reg_masked.
Reviewed by: markj
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D40846
Add support for LAN port found on Thinkpad Hybrid USB-C with USB-A dock.
While here fix a small typo
- s/UBS/USB/
Sponsored by: Technical University of Munich
Reviewed by: markj
MFC after: 2 weeks
Pull Request: https://github.com/freebsd/freebsd-src/pull/791
before calling vn_fullpath_hardlink(). Otherwise we get random failures
when the len is automatically clipped.
Reported and tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Search for and print kernel symbols in case a register's value is a
kernel address. Also improve column alignment.
Reviewed by: mhorne, jhb
Approved by: markj (mentor)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40829
Needed by the forthcoming RISC-V and ARM64 ports.
Reviewed by: markj
Approved by: markj (mentor)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40872
Bug Fixes:
* Initialize statistics before the interface is available
* Fix driver unload crash
Minor Changes:
* Mechanically convert ena(4) to DrvAPI
* Remove usage of IFF_KNOWSEPOCH
MFC after: 2 weeks
Sponsored by: Amazon, Inc.
When ena_detach is called, we first call ether_ifdetach(),
which destroys internal addresses of ifp. One such address
is ifp->if_addr->ifa_addr. Then during ena_destroy_device(),
if_link_state_change() is called, eventually trying to access
ifp->if_addr->ifa_addr->sa_family. This causes an access
to garbage memory and crashes the kernel.
Ticket [1] was opened to the FreeBSD community to add null
check in the code of if_link_state_change().
A fix was submitted in commit [2], however it was noted
that it is our driver's responsibilty to not call
if_link_state_change() after calling ether_ifdetach().
This commit makes sure if_link_state_change() is not called
after ether_ifdetach().
[1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270813
[2]: https://reviews.freebsd.org/D39614
Fixes: 32f63fa7f9 ("Split ENA reset routine into restore and destroy stages")
MFC after: 2 weeks
Sponsored by: Amazon, Inc.
In [1], the FBSD community exposed a bug in the fbsd/ena driver.
Bug description:
----------------
Current function call order is as follows:
1. ena_attach()
1.1. ena_setup_ifnet()
1.1.1. Registration of ena_get_counter()
1.1.2. ether_ifattach(ifp, adapter->mac_addr);
1.2. Statistics allocation and initialization.
At point 1.1.2, when ether_ifattach() returns, the interface is available,
and stats can be read before they are allocated, leading to kernel panic.
Also fixed a potential memory leak by freeing the stats since they were
not freed in case the following calls failed.
Fix:
----
This commit moves the statistics allocation and initialization to happen
before ena_setup_ifnet()
[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268934
Fixes: 9b8d05b8ac ("Add support for Amazon Elastic Network Adapter (ENA) NIC")
Fixes: 30217e2dff ("Rework counting of hardware statistics in ENA driver")
MFC after: 2 weeks
Sponsored by: Amazon, Inc.
When we are sending terminating signal to the group, killpg() needs to
guarantee that all group members are to be terminated (it does not need
to ensure that they are terminated on return from killpg()). The
pg_killsx change eliminates the largest window there, but still, if a
multithreaded process is signalled, the following could happen:
- thread 1 is selected for the signal delivery and gets descheduled
- thread 2 waits for pg_killsx lock, obtains it and forks
- thread 1 continue executing and terminates the process
This scenario allows the child to escape still.
To fix it, count the number of signals sent to the process with
killpg(2), in p_killpg_cnt variable, which is incremented in killpg()
and decremented after signal handler frame is created or in exit1()
after single-threading. This way we avoid forking if the termination is
due.
Noted and reviewed by: markj (previous version)
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D40493
If the process group member performs fork(), the child could escape
signalling from killpg(). Prevent it by introducing an sx process group
lock pg_killsx which is taken interruptibly shared around fork. If there
is a pending signal, do the trip through userspace with ERESTART to
handle signal ASTs. The lock is taken exclusively during killpg().
The lock is also locked exclusive when the process changes group
membership, to avoid escaping a signal by this means, by ensuring that
the process group is stable during fork.
Note that the new lock is before proctree lock, so in some situations we
could only do trylocking to obtain it.
This relatively simple approach cannot work for REAP_KILL, because
process potentially belongs to more than one reaper tree by having
sub-reapers.
Reported by: dchagin
Tested by: dchagin, pho
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D40493
If we're called on an mbuf that's passed through codel before it may
already contain the MTAG_CODEL tag. The code accounts for this and does
not allocate a new mtag. However, it inserts the mtag unconditionally.
That is, it inserts the existing mtag a second time.
When the mbuf later gets freed we iterate over the list of mtags to fee
them one by one, and we'll end up freeing an mtag that's already been
freed.
Only insert the mtag if we've allocated a new one. If we found one
there's no need to insert it again.
See also: https://redmine.pfsense.org/issues/14497
Sponsored by: Rubicon Communications, LLC ("Netgate")
Improve consistency of the field names with tcpsinfo_t:
* Use mss instead of max_seg_size.
* Use lport and rport instead of tcp_localport and tcp_foreignport.
Use t_flags instead of flags to improve consistency with t_flags2.
Add laddr and raddr, since the addresses were missing when compared
to the output of siftr.
Reviewed by: cc
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D40834
Per https://reviews.llvm.org/D68115, only the first field is
zero-initialized, meanwhile other fields are undef.
The pattern can be observed on clang as well, that when
-ftrivial-auto-var-init=pattern is specified 0xaa is filled for
non-active fields, otherwise they are zero-initialized.
Technically both are acceptable when using clang. However it
would be good to simply bzero the modspecific_t in such case to
be strict to the standard.
MFC with: 2cab2d43b8
MFC after: 1 day
Sponsored by: Juniper Networks, Inc.
Reviewed by: delphij
Differential Revision: https://reviews.freebsd.org/D40830
