ahci(4): Add another device ID for Marvell 9128 SATA controller: 0x91a3
This was encountered on a Gigabyte GA-P55A-UD4 motherboard identifying itself
as:
ahci0 at pci0:2:0:0: class=0x01018f rev=0x11 hdr=0x00 vendor=0x1b4b device=0x91a3 subvendor=0x1458 subdevice=0xb000
vendor = 'Marvell Technology Group Ltd.'
class = mass storage
subclass = ATA
The physical chip has "88SE9128-NAA2" printed on it.
Similar code has been in Linux for a long time:
https://github.com/torvalds/linux/commit/50be5e3657cd2851a297dc0b3fd459f25829d29b
Co-authored-by: Michael Osipov <michaelo at FreeBSD.org>
PR: 288526
Reviewed by: jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D56464
net/teddycloud: Update 0.6.7 => 0.6.8
Changelog:
https://github.com/toniebox-reverse-engineering/teddycloud/releases/tag/tc_v0.6.8
Port changes:
* Replace several source code patch files with CFLAGS instead.
* Replace long paths with DATADIR and ETCDIR instead.
* Pet portlint: remove empty line between *_DEPENDS.
* Convert pkg-message to files/pkg-message.in and fix typo.
PR: 294230
Reported by: Michael Pape <freebsd at pe82.de> (maintainer)
Approved by: vvd (co-mentor)
LinuxKPI: Update seq_file to properly implement the iterator interface
The seq_file.rst documentation in the Linux kernel documents the
iterator interface for the seq_file structure. In particular, the
ppos passed to seq_read is a logical offset into a seq_file managed by
the iterator interface, not an offset into the generated data. For
example, if a seq_file outputs state for each node in a linked-list or
array, *ppos might be used as the index of the node to output, not a
byte offset.
Rewrite seq_read to honor this contract which fixes a few bugs:
- Treat *ppos as a logical iterator offset that is only updated by the
next callback after outputting a single item via the show method.
- Use a loop to permit outputting descriptions of multiple items if
the user buffer is large enough.
- Always invoke the stop method after terminating the loop to cleanup
[9 lines not shown]
arm64/vmm: Enable 16-bit VMIDs when in use by pmap
pmap_init always uses 16-bit VMIDs when supported, but we never enable
them in VTCR_EL2 (for ASIDs, locore enables them in TCR_EL1 and
pmap_init keys off whether they've been enabled, but the order in which
pmap_init and vmmops_modinit run is reversed). As a result, although the
full 16-bit value can be stored to VTTBR_EL2 and read back, the upper 8
bits are treated as 0, and so VMIDs that our VMID allocation believes
are distinct end up aliasing.
In future this interface may change such that vmm decides on the VMID
width and tells the pmap to use that, with appropriate support for
unloading and reloading vmm, but that can come as a follow-up change, as
this is a more minimal bug fix.
Reviewed by: markj
Obtained from: CheriBSD
Fixes: 47e073941f4e ("Import the kernel parts of bhyve/arm64")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D55860
Status/2026Q1: Fixes
- Change syntax of a numbered list to fix warnings (use actual numbers
instead of repeating "1."'s)
- URL encode "..." to ensure links do not break (replacing ... with …)
amd64: fix INVLPGB range invalidation
AMD64 Architecture Programmer's Manual Volume 3 says the following:
> ECX[15:0] contains a count of the number of sequential pages to
> invalidate in addition to the original virtual address, starting from
> the virtual address specified in rAX. A count of 0 invalidates a
> single page. ECX[31]=0 indicates to increment the virtual address at
> the 4K boundary. ECX[31]=1 indicates to increment the virtual address
> at the 2M boundary. The maximum count supported is reported in
> CPUID function 8000_0008h, EDX[15:0].
ECX[31] being what we call INVLPGB_2M_CNT, signaling to increment the
VA by 2M.
> This instruction invalidates the TLB entry or entries, regardless of
> the page size (4 Kbytes, 2 Mbytes, 4 Mbytes, or 1 Gbyte). [...]
Combined with this, my interpretation of the current code is: if
[21 lines not shown]
amd64: fix INVLPGB range invalidation
AMD64 Architecture Programmer's Manual Volume 3 says the following:
> ECX[15:0] contains a count of the number of sequential pages to
> invalidate in addition to the original virtual address, starting from
> the virtual address specified in rAX. A count of 0 invalidates a
> single page. ECX[31]=0 indicates to increment the virtual address at
> the 4K boundary. ECX[31]=1 indicates to increment the virtual address
> at the 2M boundary. The maximum count supported is reported in
> CPUID function 8000_0008h, EDX[15:0].
ECX[31] being what we call INVLPGB_2M_CNT, signaling to increment the
VA by 2M.
> This instruction invalidates the TLB entry or entries, regardless of
> the page size (4 Kbytes, 2 Mbytes, 4 Mbytes, or 1 Gbyte). [...]
Combined with this, my interpretation of the current code is: if
[21 lines not shown]
tests: kqueue: improve diagnostics for our CPONFORK test
Notably, confirm in the child that our close-on-fork fd is actually
closed, and break RECV_ALL out into a table and check each bit
individually to provide a better message when the test fails.
While we're here, just switch to waitid() rather than trying to identify
the point where we have to make the switch. This reduces maintenance
slightly, as keeping our assertion static would require still adding to
a _RECV_ALL mask *just* for that purpose.
Reviewed by: kib, markj (both slightly earlier version)
(cherry picked from commit 51d2c38010824b90d7462711896a88165db9d015)
find: add -xattr and -xttrname
We use -xattr in our openrsync tests for convenience, and it seems like
a good addition to FreeBSD. -xattr and -xattrname will both consult all
available namespaces by default, but -xattrname allows filtering by
namespace using a "user:" or "system:" prefix.
Inspired by: https://github.com/apple-oss-distributions/shell_cmds
Reviewed by: kib, rmacklem
Sponsored by: Klara, Inc.
(cherry picked from commit 22fba3a9d64140d80a9e2093cfc02c9c503b2e19)
<sys/extattr.h>: use designated initializers for EXTATTR_NAMESPACE_NAMES
This is not a functional change, but it makes it more clear upon
inspection of the definition that the mapping property described is
preserved. Maybe more importantly, if one ends up getting an index
wrong or punching a hole in the name array unexpectedly, then it'll
hopefully manifest more clearly as a (null) or nullptr deref rather than
potentially just emitting the wrong namespace name.
It's noted that this almost certainly invalidates its use in C++, but
there aren't really any known C++ consumers of it- let's just cross
that bridge if we get there.
Reviewed by: kib, mckusick, rmacklem
Sponsored by: Klara, Inc.
(cherry picked from commit 84ce651836e0d037f611cd33a5c65e1d57049432)
libutil: take a size_t in trimdomain()
INT_MAX is already larger than a reasonable hostname might be, but
size_t makes some of this easier to reason about as we do arithmetic
with it. This would maybe not be worth it if we had to bump the
soversion because of it, but libutil does symbol versioning now so we
can provide a compat shim.
While we're here, fix some inconsistencies in argument names in the
manpage.
Reviewed by: des
Obtained from: https://github.com/apple-oss-distributions/libutil
Sponsored by: Klara, Inc.
(cherry picked from commit 7e70589b1bee4853cb11e3d8eb963079b18ff534)
libutil: avoid an out-of-bounds read in trimdomain(3)memchr(3) will happily believe we've passed in a valid object, but
hostsize could easily exceed the bounds of fullhost. Clamp it down to
the string size to be safe and avoid UB. This plugs a potential
overread noted in the compat shim that was just added.
Reviewed by: des
Sponsored by: Klara, Inc.
(cherry picked from commit f268f95955f5f0f91f4d39e13bcd69a24e0d8ce4)
science/orthanc-mysql: Update to allow build alongside orthanc 1.12.11
Does not build with bundled orthanc 1.12.11.
Pin bundled version to 1.12.10 instead of ../orthanc/version.mk.
