There is a long-standing issue on RISC-V around --gc-sections when
statically linking, which affects the bootstrap build of LLVM. Since
fixing this properly has remained a TODO for years, commit the
workaround with documentation so that building natively from source
works out of the box.
PR: 258358
MFC after: 1 week
A new utility which dumps MIDI 1.0 events in real-time.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46418
Showcase how to detach ppt from a PCI device and attach a host driver,
and vice-versa.
MFC after: 2 days
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D46811
Both conditions are the same, so the second one is unreachable.
PR: 229550
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: andreast, markj
Differential Revision: https://reviews.freebsd.org/D47167
No functional change intended.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: markj, emaste
Differential Revision: https://reviews.freebsd.org/D47152
These malloc(9) calls are in contexts where sleeping is permitted.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, zlei, markj, emaste
Differential Revision: https://reviews.freebsd.org/D46845
The current channel naming convention is:
pcmX:[virtual_]play|record:dspX.[v]p|rY
- pcmX and dspX share the same unit numbers
- "[v]p|r" gives us the same information as "[virtual_]play|record"
Remove the redundant information, so that the channel names become more
readable: dspX.[virtual_]play|record.Y
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46836
Currently we create and destroy channels with the following consistent
pattern:
- chn_init() -> pcm_chn_add()
- pcm_chn_remove() -> chn_kill()
Instead of calling two separate functions, merge pcm_chn_add() with
chn_init(), and pcm_chn_remove() with chn_kill().
Another benefit of this change is that we avoid the confusion caused by
having pcm_chn_add(), as well as pcm_addchan().
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D46835
feeder_rate_min functions as the lower boundary.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj, emaste
Differential Revision: https://reviews.freebsd.org/D46834
Instead of checking the value of "ret" multiple times, just set a goto
label and jump there immediately in case of an error.
While here, remove a redundant assignment to "d".
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj, emaste
Differential Revision: https://reviews.freebsd.org/D46833
No longer used.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46522
If we do not enter dummy_chan_trigger() before detaching, we'll get a
use-after-free since the callout(9) callback might be called after
having been detached.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj, emaste
Differential Revision: https://reviews.freebsd.org/D46715
feeder_register() is currently a SYSINIT in order to create the root
feeder, which happens only when feedercnt is 0. Separating the root
feeder registration makes the code more readable.
No functional change intended.
While here, fix some style errors.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, zlei, markj
Differential Revision: https://reviews.freebsd.org/D46821
There is no reason to initialize global variables in feeder_register(),
as these variables are unrelated to what the function does. Instead,
initialize them during sound(4) load.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: zlei
Differential Revision: https://reviews.freebsd.org/D46749
Currently it is possible to assign a unit number that already exists.
Suppose the following channel list:
[vp2]
If we create 3 channels, we'll end up with the following list:
[vp0, vp1, vp2, vp2]
This happens because chn_init() does not check if the unit number we are
assigning already exists. While fixing this is trivial when the channel
list is sorted in ascending order, it is way more involved when sorted
in descending order. Even though sorting the list in descending order
would require deliberately modifying pcm_chn_add(), and is most likely
not going to happen, make the mechanism more robust by using a unr(9)
allocator for each channel type.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46680
Refactor CHN_INSERT_SORT() to also take into account the unit number of
each channel, while still prioritizing the type, to make the channel
list easier to work with.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46549
Simplify logic to execute the following algorithm:
1. Search for a free (i.e not busy) channel and return successfully.
2. If no channel was found, either return an ENOTSUP if no VCHAN can be
created (disabled or we reached the limit), or create one more VCHAN
and scan for it again.
3. If the second scan failed again, return EBUSY.
This patch also solves a bug where we'd end up in an infinite loop,
calling vchan_setnew() with the same `newcnt` value indefinitely, after
the following scenario:
1. Plug device.
2. Spawn X channels.
3. Kill all channels except _last_ opened.
4. Clean up all unused VCHANs.
5. Spawn X+1 channels.
6. Infinite loop in pcm_chnalloc().
I am not exactly sure which part of pcm_chnalloc() caused this bug, but
the patch fixes it at least...
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46548
The VCHAN count is checked in vchan_setnew(), and there is no reason to
cap the hardware channels in the first place.
This is part of a series of follow-up patches.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46521
This check is not really useful, and can in fact break things, if
sysctl_dev_pcm_vchans() calls vchan_setnew() with a value that will not
satisfy the KASSERT condition.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, emaste
Differential Revision: https://reviews.freebsd.org/D46545
Add devices supported by this driver to a HARDWARE section
for generation in the Hardware Compatibility Notes.
While here:
- describe more consistently with product doc and rest of manual
- consolidate basics in first paragraph of description
- mention boot time configuration
- cross-ref networking(7) quick start guide
- zap deprecated Tn, macro in list width, and "Dq Li" => "Ql"
- markup some unmarked elements
- add SPDX tag
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D47170
Add devices supported by this driver to a HARDWARE section
for inclusion in the release Hardware Compatibility Notes.
While here:
- add SPDX tag
- add networking(7) cross-ref quick start guide
- tweak examples for consistency
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D47168
This reverts commit 1a37caeb07.
I'd overlooked 06c07e1203 when I updated a
branch I'd previously committed but not updated. My search for this in
my tree before the commit was to a stale file...
Sponsored by: Netflix
A hardware IPv6 server needs 2 consecutive stids (server tids) starting
from a 2-aligned stid whereas an IPv4 server needs only 1 stid without
any constraint. The allocator used to grab the first free stid(s) for
both but this can fragment the stid space leaving nothing suitable for
IPv6 even when lots of stids are available. Change the allocator to
prefer stids for IPv4 from the ones that cannot be used for IPv6.
Reviewed by: jhb
MFC after: 1 week
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D47042
Add a "zzz_fw_ports_fwget.sh" script to each LinuxKPI based wireless
driver which in essential are all the same and in detail all different.
The scripts have been referenced in fwget(8) sources since d33f5a0afa
but were never committed.
The scripts do the full job compared to `single-line-scripts` I tried to
use before to ease maintainance life. Some use hacks like calling cpp
and extracting bits from the output to piece them together over multiple
files. It will be left as an exercise for the future to see if what was
done (a longer while ago) for iwlwifi(4) would be a good idea for some
other drivers too, to have a FreeBSD-specific sysctl to export some of
the accumulated data in an easily processable way.
The scripts are written in the "perl spirit" -- "to get the job done" --
and not to be nice or neat or efficient. For that we do not need them
often enough or in any critical path. People are welcome to improve
them if they feel like.
I've used them for two version updates now and even if ports enforce
some other (manual) editing to keep support for multiple branches for
now they worked extremly well.
For the most the scripts extract 2 parts: PCI IDs and firmware name;
then they add "flavor"s to both and put the information together.
That output is then separated into:
- fwget(8) lines of PCI ID to port/package
wifi-firmware-${name}-kmod-${flavor} mappings and
- distfiles per flavor for the ports.
- For iwlwififw(4) we also generate the tables for the man page
(and the wiki) and hopefully the .Sh HARDWARE section for iwlwifi.4
soon too.
Depending on driver various other checks are done, e.g.,
- does the PCI ID have one or more firmware files/flavors associated,
- does the referenced firmware exist in the linux-firmware.git repo,
- are there duplicates,
- find the latest version of the firmware API.
Sponsored by: The FreeBSD Foundation
Suggested by: imp (to have automation in D44918)
MFC after: 3 days
Update the sysctl export (also adding a mapping function) to also
print (1) for all lines the "flavor" (device_family) name and (2)
also print lines where we only have the trans cfg and not iwl cfg
as with the flavor we can match PCI IDs to firmware package and so
we can have an increased number of matches.
A side effect is that we can also have fwget(8) PCI ID matches for
firmware (flavors) not yet (publicly) existing. That will allow
us to add them at a later point while a previous release already
supports the chipsets and knows how to get the firmware for them.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Previously this just dereferenced NULL qp pointers and panicked.
Instead, use a shared lock on the connection lock to protect access to
the qp pointers and allocate a request. If the controller is not
associated, fail the request with ECONNABORTED.
Possibly this should be honoring kern.nvmf.fail_on_disconnection and
block waiting for a reconnect request while disconnected if that
tunable is false.
Reported by: Suhas Lokesha <suhas@chelsio.com>
Sponsored by: Chelsio Communications
Show the iommu unit' device name/unit which translates the device'
requests, if any, as parsed out from the BIOS tables.
Also show the rid value for the device.
Sponsored by: Advanced Micro Devices (AMD)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D47098
The KPI allows to store arbitrary data within struct device, retrieve it
back by name, and update the value. The data is automatically destroyed
on the device deletion. Also, the user can request to clear the named
property from all devices.
My need for this interface is due to IOMMU needing to save some
indicator on device, which must survive the re-creation of the domain
context.
Reviewed by: imp
Discussed with: emaste
Sponsored by: Advanced Micro Devices (AMD)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D46605
which returns apic device_t by apic_id, if there exists the pci representer
Sponsored by: Advanced Micro Devices (AMD)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
PCI_IRQ_LEGACY was added in 366d68f283 (likely) for rtw88 only.
The define now got renamed and I cannot find any other use but
rtw88 and rtw89.
We keep the old name as comapt while driver updates are in
progress enabling it defining LINUXKPI_VERSION for the two drivers.
Sponsored by; The FreeBSD Foundation
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D46822
Add alloc_netdev_dummy() which is needed by an updated rtw88 driver.
Given we already call linuxkpi_init_dummy_netdev() ourselves allow the
setup function to be NULL to not initialize and start a tasq td twice.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D46802
While mounting ZFS root during boot on Linux distributions from initrd,
mount from busybox is effectively used which executes mount system call
directly. This skips the ZFS helper mount.zfs, which checks and enables
the mount options as specified in dataset properties. As a result,
datasets mounted during boot from initrd do not have correct mount
options as specified in ZFS dataset properties.
There has been an attempt to use mount.zfs in zfs initrd script,
responsible for mounting the ZFS root filesystem (PR#13305). This was
later reverted (PR#14908) after discovering that using mount.zfs breaks
mounting of snapshots on root (/) and other child datasets of root have
the same issue (Issue#9461).
This happens because switching from busybox mount to mount.zfs correctly
parses the mount options but also adds 'mntpoint=/root' to the mount
options, which is then prepended to the snapshot mountpoint in
'.zfs/snapshot'. '/root' is the directory on Debian with initramfs-tools
where root filesystem is mounted before pivot_root. When Linux runtime
is reached, trying to access the snapshots on root results in
automounting the snapshot on '/root/.zfs/*', which fails.
This commit attempts to fix the automounting of snapshots on root, while
using mount.zfs in initrd script. Since the mountpoint of dataset is
stored in vfs_mntpoint field, we can check if current mountpoint of
dataset and vfs_mntpoint are same or not. If they are not same, reset
the vfs_mntpoint field with current mountpoint. This fixes the
mountpoints of root dataset and children in respective vfs_mntpoint
fields when we try to access the snapshots of root dataset or its
children. With correct mountpoint for root dataset and children stored
in vfs_mntpoint, all snapshots of root dataset are mounted correctly
and become accessible.
This fix will come into play only if current process, that is trying to
access the snapshots is not in chroot context. The Linux kernel API
that is used to convert struct path into char format (d_path), returns
the complete path for given struct path. It works in chroot environment
as well and returns the correct path from original filesystem root.
However d_path fails to return the complete path if any directory from
original root filesystem is mounted using --bind flag or --rbind flag
in chroot environment. In this case, if we try to access the snapshot
from outside the chroot environment, d_path returns the path correctly,
i.e. it returns the correct path to the directory that is mounted with
--bind flag. However inside the chroot environment, it only returns the
path inside chroot.
For now, there is not a better way in my understanding that gives the
complete path in char format and handles the case where directories from
root filesystem are mounted with --bind or --rbind on another path which
user will later chroot into. So this fix gets enabled if current
process trying to access the snapshot is not in chroot context.
With the snapshots issue fixed for root filesystem, using mount.zfs in
ZFS initrd script, mounts the datasets with correct mount options.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Ameer Hamza <ahamza@ixsystems.com>
Signed-off-by: Umer Saleem <usaleem@ixsystems.com>
Closes#16646
The update to py-twisted 24.7.0 broke EPSV mode in twisted's ftp server.
Work around this by disabling EPSV (and thus using PASV).
PR: 282154
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
The ping tests were originally broken by an unrelated isue that
is now fixed ( 2926c25942 ).
THanks to kp@ for fixing the test and Jose Luis Duran for pinting it out.
This reverts commit 7bc0cb91a2.
The description is listed in angle brackets after the device name
similar to device probe messages.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47157
device_detach() checks the device state and only calls a driver's
DEVICE_DETACH method if the device is attached but not busy.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47156
This gives the parent bus driver the opportunity to cleanup any
allocated resources, etc. left behind by a failed attach attempt.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47155
This better matches the variable names and the function comment as
well as clarifying the reason for the order of operations.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47154
Previously only providers in kernel modules were removed leaving
dangling pointers to tracepoints, etc. in unloaded kernel modules.
PR: 281825
Reported by: Sony Arpita Das <sonyarpitad@chelsio.com>
Reviewed by: markj
Fixes: ddf0ed09bd sdt: Implement SDT probes using hot-patching
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D46890
The FreeBSD linux/compiler.h in OpenZFS was copied from a very old
version of FreeBSD's linuxkpi's linux/compiler.h. There's no need for
this duplication. Use FreeBSD's linuxkpi version instead, and provide
zfs_fallthrough to augment it (it's all that's needed). Use #pragma once
to avoid naming issues for guard variables. Since this is a complete
rewrite, use my copyright here (the original code in FreeBSD still
credits everybody). This works back at least to FreeBSD 12.4, which
is not out of support, and all newer releases.
Remove extra copies of macros that were defined elsewhere, but are now
properly defined in LinuxKPI so are redundant.
Sponsored-by: Netflix
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Warner Losh <imp@bsdimp.com>
Closes#16650
