This bug and https://www.mail-archive.com/freebsd-stable@freebsd.org/msg124458.html
both have this fix. It turns unknown errors into an autosense failure, which causes
us to grab the sense buffer manually. It also sets a condition that we use to retry
timed out commands that jmg reports as being helpful.
I'm torn on committing it. The code seems fine in terms of fixing
things. But this is a 10-year-old bug with few other bugs and a short CC
list for a driver that might go away in 15 anyway. I'm going to commit
and close the bug, and MFC it in a week, unless someone complains (which
seems unliekly, given the age of this hardware, I susepct most of it is
out of service).
Suggested by: jmg, Scott Long
PR: 191135
MFC After: 1 week
Reviewed by: imp
(cherry picked from commit f52154a2044a4d1f324952af05542f93fdf0a088)
We don't use legacy receive descriptors and masking out the vlan ID
isn't necessary since the tag is in the standard format, so remove it.
(cherry picked from commit 124b7722aad7d4cf12d96c030659aef78175aa9c)
Normally the reply to destroy_server() releases the listen context but
it is not called when the adapter is suspended. Release the context
right away in that case.
Sponsored by: Chelsio Communications
(cherry picked from commit 45d5b9f0324a13df06712b7a9df5f2fbe8475764)
This got lost many years ago in 8eb6488ebb
It is used by the driver's DBG printfs.
(cherry picked from commit bf6f0db8a762966b08430692c92ae34e667948db)
net80211 node ni_chw currently encodes the channel width as Mhz number.
LinuxKPI 802.11 uses enum ieee80211_sta_rx_bw for the same.
Rather than keeping the "20" and "40" throughout the code (eventually
expanded to 80/160/320) switch them over to use the enum throughout.
Once we get to 320Mhz channel widths we would otherwise also need to
extend the uint8_t in struct ieee80211_node; making
enum ieee80211_sta_rx_bw __packed allows us for lots more channel
widths without breaking the KBI.
Sponsored by: The FreeBSD Foundation
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D47891
(cherry picked from commit ca389486a9599768e0ba69dca13c208020623083)
(cherry picked from commit 2c8b0d6205f6f98855773e3a82640b50abb2f2f6)
Replace is_power_of_2(length) with power2(length). When length != 0, as in
this case, they produce the same result. This will allow an implementation
of is_power_of_two to be dropped.
Reviewed by: alc, markj
Differential Revision: https://reviews.freebsd.org/D45536
(cherry picked from commit a94ed493b50752cee09245fc312c63b00331f217)
Linux has a header file that defines an ilog2 function and some simple
functions/macros that use it: roundup_pow_of_two, is_power_of_2,
rounddown_pow_of_two, and order_base_2. This change moves three of
those simple functions (all but is_power_of_2) from linuxkpi to
libkern. It also deletes a few implementations of these functions
that have previously been copied into code for various device drivers,
so that they can use the libkern version. The is_power_of_2 macro was
not moved because powerof2 in param.h provides almost the same service
already (except that they disagree about whether 0 is a power of two).
Since the linux definitions of these functions were copied into
FreeBSD 11 years ago, linux has improved them, and this change
provides those improvements. In particular, a giant table of log
values for evaluating ilog2 for constant values is no longer
necessary.
Reviewed by: alc, markj (previous version)
Differential Revision: https://reviews.freebsd.org/D45536
(cherry picked from commit c8b0c33b03ac072413b27bed2bdae2ae27426f3a)
The kernel source contains several definitions of an ilog2 function;
some are slower than necessary, and one of them is incorrect.
Elimininate them all and define an ilog2 macro in libkern to replace
them, in a way that is fast, correct for all argument types, and, in a
GENERIC kernel, includes a check for an invalid zero parameter.
Folks at Microsoft have verified that having a correct ilog2
definition for their MANA driver doesn't break it.
Reviewed by: alc, markj, mhorne (older version), jhibbits (older version)
Differential Revision: https://reviews.freebsd.org/D45170
Differential Revision: https://reviews.freebsd.org/D45235
(cherry picked from commit b0056b31e90029553894d17c441cbb2c06d31412)
In 4cc5d081d8c23, a change was introduced that manipulated
drv_ioctl_data->reqcap using IFCAP2 bits. This was noticed
when creating a mixed lagg with mce0 and ixl0 caused the
interfaces' txcsum caps to be disabled.
Fixes: 4cc5d081d8c23
Reviewed by: glebius
Sponsored by: Netflix
MFC After: 7 days
(cherry picked from commit 36fdc42c6a4c828d334471438c4f852e4b5a25e2)
ELECOM EDC-QUA3C is a USB3.1 Gen1 Type-A/C 2.5GBASE-T network adapter.
This also works as a cdce(4) device by:
usbconfig -d X.Y set_config 1
or
usbconfig -d X.Y set_config 2
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
MFC after: 2 weeks
Pull Request: https://github.com/freebsd/freebsd-src/pull/1578
(cherry picked from commit dc273058cb0b6bef075e77272afc66f1a1fd3889)
These are reportedly still in fairly wide use.
We strongly encourage folks with this hardware to post a dmesg on
dmesgd.nycbug.org.
This reverts commit 4591322980.
Discussed with: brooks
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 8b012980b8cc5f8619cd552ee6df7b98b97c5d62)
Commit 27b932e32fab ("sound: Safely remove channel from list in one
pass") optimized CHN_REMOVE_SAFE() to perform almost equally to
CHN_REMOVE(), so we can turn CHN_REMOVE_SAFE() into CHN_REMOVE() without
fears of performance regressions, while also being more robust.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D48249
(cherry picked from commit ffcefe5310e084415a2f292a00f4637d4059c40f)
The CHN_REMOVE_SAFE() macro did two traversals of the channel list to
remove a channel, one to check whether the channel is an element of the
list, and a second traversal through SLIST_REMOVE(). Reduce this to one
traversal, while still preventing a NULL dereference in case the channel
in question is not present in the list.
While here, rename the macro arguments to something more descriptive.
MFC after: 1 week
Reviewed by: christos
Differential Revision: https://reviews.freebsd.org/D48207
(cherry picked from commit 27b932e32faba1137ff307d05b787d837ccadda8)
Main goal is to have a unit test, with sample test data that is verified
against the current macro implementation of pcm sample read and write
functions. With a test in place, we can proceed on a planned refactoring
of the sample read and write code, and confidently check the new code
for regressions.
Implementation of the unit test itself has to avoid any cast or
conversion affected by endianness, to make the tests compatible with all
machine architectures.
MFC after: 1 week
Reviewed by: christos, markj
Differential Revision: https://reviews.freebsd.org/D48330
(cherry picked from commit 27ef5d48c729defb83a8822143dc71ab17f9d68b)
Wrong signedness of usage value results in inverted range check in hmt(4)
driver that allows out of bound array access leading to panic.
Reported by: many
Sponsored by: Future Crew, LLC
Obtained from: NetBSD
NetBSD PR: kern/53605
PR: 274014, 282592
(cherry picked from commit 38b67578fb4bbf568f7012ca3921a4d15cfe7c5d)
This driver prefers connection speed over sas port speed. On stable/13
branch the stack-allocated CCB is not cleared thus the cam layer may
report weird speed on boot.
```
da0: <VMware Virtual disk 2.0> Fixed Direct Access SPC-4 SCSI device
da0: 4294967.295MB/s transfers
```
-current and stable/14 have the change [1] which clears stack-allocated
CCB thus are not affected, but I want -current and stable/14 to have this
fix in to reduce drift between branches.
1. ec5325dbca cam: make sure to clear even more CCBs allocated on the stack
Reviewed by: imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D48438
(cherry picked from commit 7befd68335a0b34405b6293f30cc47cabc46ab06)
It uses the same audio codec as 12th gen (PCI ID 0x0002).
Actually everything is the same, except the CPU.
Signed-off-by: Daniel Schaefer <dhs@frame.work>
(cherry picked from commit 48b9d78a0a9d795cfdeb56895a27309aadd50c77)
Aborting ATIO while its CTIOs are in progress makes impossible to
handle their completions, making them stuck forever. Detect this
case by checking ctcnt counter and if so instead of aborting just
mark the ATIO as dead to block any new CTIOs. It is not perfect
since the task id can not be reused for some more time, but not
as bad as the task stuck forever.
MFC after: 1 week
(cherry picked from commit 2c48a8f161c91bf7020122697d064a25287097a3)
The termios layer wants some level of guarantee that we've actually
submitted param changes to the hardware when our functions return, so we
need to do a little more waiting to avoid violating those guarantees.
This is especially important as some hardware has some minimum timing
specifications around this stuff, and without being less asynchronous
the software dealing with these devices can't reasonably operate the
hardware without more excessive delays than they should need.
More specifically, we make sure that:
- The command to start transfers is finished before we toggle DTR/RTS
- The status_change command finishes before we return, which may change
some fields in the softc that we need for a subsequent call into
usb_serial
- cfg_param finishes before we re-enable transfers, and we ensure that
RTS is appropriately toggled before we return to userland
This has been observed to fix some flakiness in connecting to some
ESP32 devices.
Tested by: kenrap from Libera
Reviewed by: imp, kib
(cherry picked from commit 36a80f4264350a2f4f0686eb91ae7f5943d40327)
ucom_queue_command will issue commands for open/close, then wait on them
to be finished. In the spirit of playing it safe, allow
ucom_queue_command's wait to be interrupted in case the usb process gets
jammed up waiting on the hardware -- we can at least recover the user
thread that initiated it, even if we can't recover the usb process.
Reviewed by: imp, kib
(cherry picked from commit 729eb176a465cedc55c5980f116d87be592421f1)
There's only one error that we can get back right now, but future
changes will add some more cases that we need to watch out for. Start
by returning errors and propagating them back.
Reviewed by: kib
(cherry picked from commit 51f3d0874f6216907c8971c4af9d6be6c93edf7b)
The commit to introduce TCP_USE_DDP support had a couple of bugs that
broke support for zerocopy receive via aio_read(). First, the length
and offset arguments to mk_update_tcb_for_ddp() were reversed which
prevented DDP from working. Second, the AIO state in the toep was
initialized too late when the first aio_read() request was queued.
Reported by: Harshavardhan Tanneru @ Chelsio
Fixes: eba13bbc37ab cxgbe: Support TCP_USE_DDP on offloaded TOE connections
MFC after: 1 week
Sponsored by: Chelsio Communications
(cherry picked from commit 70693a45381b687e40ea30710aa38cb9f24b6b02)
Correct leading whitespace for a few lines.
Consistently use more canonical #ifdef to test for COMPAT_FREEBSD32.
Obtained from: CheriBSD
Sponsored by: AFRL, DARPA
(cherry picked from commit 727de621c5f07681034eed2d6ce3662a8239e987)
Otherwise the ifmedia subsystem may call unguarded NULL function
pointers. Same issue that was fixed for cxgb(4) in f2daf8995.
Also see: https://github.com/opnsense/src/issues/228
(cherry picked from commit 0482974b2c021a8abbc044d3e2b1240250f791e7)
- When handling notify acknowledge from target code for task abort
request, not only send abort to the firmware, but also delete the
ATIO private data associated with the command. It is required for
proper tag reuse, allowing new "conflicting" commands to be passed
to the target. CTL was already fixed to handle that right, instead
of delaying them in restart queue of the driver.
- When target finally aborts the command (which it should have
done before the notify ack) we should not send another abort to
the firmware. Since we already sent the abort and deleted ATIO
private data above, just return successful completion here, doing
nothing. Since the tag can be reused by that time, we can not
rely on its uniqueness, so when searching to the ATIO private data
compare also the aborted CCB pointer in addition to the tag.
- Fix BA_RJT sending in isp_acknak_abts(). While it should be
rare, teach the code to send error responses for ABTS requests.
MFC after: 2 weeks
(cherry picked from commit ec3175fc3b2c1b07144a85e6a3e2fe534acc0c87)
When aborting command waiting in restart queue remove it from the
queue before freeing it. This should fix NULL dereference panics
we saw on some very busy system.
MFC after: 2 weeks
(cherry picked from commit 40fb1b8bc1cf452d83edc5b25bc1d8bd13c0e72d)
HIDRAW_GET_REPORT ioctl is documented to update hgd_actlen on return
with the number of bytes copied. It does not do this.
Reviewed by: wulf
PR: 282790
MFC after: 1 week
(cherry picked from commit f4f46a2eef3be6d19c65a4ca4ee70f365dd5be4f)
USB_GET_REPORT ioctl is documented to update ugd_actlen on return with
the number of bytes copied. It does not do this.
Reviewed by: wulf
PR: 282790
MFC after: 1 week
(cherry picked from commit 0b5d86b38ae9aec92ef96b9227a404a2df3c9234)
Some Fujitsu Lifebooks return an invalid _BIX object. The first element
of _BIX is a revision number, which indicates what elements will follow:
* ACPI 4.0 defined _BIX revision 0 with 20 elements.
* ACPI 6.0 introduced _BIX revision 1 with 21 elements.
The problem is that the offending Lifebooks have the a non-zero _BIX
revision, but provide 20 fields only.
The ACPICA parser chokes on this [1], but that seems to be
inconsequential. More importantly, our own battery info handling code
also verifies that for revision > 0, there are at least 21 fields - and
refuses to process the invalid _BIX. One workaround would be to
introduce special case / quirk handling for Fujitsu Lifebooks. A better
one is to relax the requirements check: If there are only 20 elements,
treat the _BIX as revision 0, no matter what revision number was
provided by the device.
Linux doesn't run into this problem by the way because it only supports
the 20 fields defined in the ACPI 4.0 spec [3]. It never looks at the
revision number or the 21st field added in ACPI 6.0.
[1] https://cgit.freebsd.org/src/tree/sys/contrib/dev/acpica/components/namespace/nsprepkg.c#n815
[2] https://cgit.freebsd.org/src/tree/sys/dev/acpica/acpi_cmbat.c#n371
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/battery.c#n418
PR: 252030
Reviewed by: imp
MFC After: 2 weeks
(cherry picked from commit cd8c3af747cc300c8257c315c7576644e2bb86ff)
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
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D47042
(cherry picked from commit f48fb131c2523d4915d1ad4eba002251c64f5574)
Reported by: Sony Arpita Das @ Chelsio
Fixes: 5c15094916bf cxgbe(4): Update the board names of the T6 OCP cards.
Sponsored by: Chelsio Communications
(cherry picked from commit 878413d5590c9f24fb8a92ebca00899662594874)
