This is a retread of https://reviews.freebsd.org/D34449 which I think
will fix the issue for the remote side not supporting autoneg. We now
attempt an autoneg, and if that fails fall back to the current code
that forces the link speed/duplex.
The original intent of this patch is to inform the remote switch of
duplex settings when we (the client) are specifying a fixed 10 or 100
speed. Otherwise it may get the duplex setting wrong.
The tricky case is when the remote (switch) side is fixing its
speed AND duplex while disabling autoneg and we (client) need to do
the same, which still seems to be common enough at some ISPs.
Original commit message follows:
Currently if an e1000 interface is set to a fixed media configuration,
for gigabit, it will participate in auto-negotiation as required by
IEEE 802.3-2018 Clause 37. However, if set to fixed media configuration
for 100 or 10, it does NOT participate in auto-negotiation.
By my reading of Clauses 28 and 37, while auto-negotiation is optional
for 100 and 10, it is not prohibited and is, in fact, "highly
recommended".
This patch enables auto-negotiation for fixed 100 and 10 media
configuration, in a similar manner to that already performed for 1000.
I.e., the patch enables advertising of just the manually configured
settings with the goal of allowing the remote end to match the manually
configured settings if it has them available.
To be clear, this patch does NOT allow an em(4) interface that has been
manually configured with specific media settings to respond to
auto-negotiation by then configuring different parameters to those that
were manually configured. The intent of this patch is to fully comply
with the requirements of Clause 37, but for 100 and 10.
The need for this has arisen on an em(4) link where the other end is
under a different administrative control and is set to full
auto-negotiation. Due to the cable length GigE is not working well. It
is desired to set the em(4) end to "media 100baseTX mediatype
full-duplex" which does work when both ends are configured that way.
Currently, because em(4) does not participate in autoneg for this
setting, the remote defaults to half-duplex - i.e., there's a duplex
mismatch and things don't work. With this patch, em(4) would inform the
remote that it has only 100baseTX full, the remote would match that and
it will work.
Tested by: Natalino Picone <natalino.picone@nozominetworks.com>
Tested by: Franco Fichtner <franco@opnsense.org>
Tested by: J.R. Oldroyd <fbsd@opal.com> (previous version)
Sponsored by: Nozomi Networks
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D47336
On a laptop with no other console devices than the screen, things
scroll of the screen faster than eye or camera can capture it.
This tunable slows the console down and makes it update synchronously,
so console output continues when timers or interrupts do not.
Differential Revision: https://reviews.freebsd.org/D47710
Remove the array of port module status and instead save module status
and module number.
At boot, for each PCI function driver get event from fw about module
status. The event contains module number and module status. Driver
stores module number and module status.. When user (ifconfig) ask for
modules information, for each pci function driver first queries fw to
get module number of current pci function, then driver compares the
module number to the module number it stored before and if it matches
and module status is "plugged and enabled" then driver queries fw for
the eprom information of that module number and return it to the
caller.
In fact fw could have concluded that required module number of the
current pci function, but fw is not implemented this way. current
design of PRM/FW is that MCIA register handling is only aware of
modules, not the pci function->module connections. FW is designed to
take the module number written to MCIA and write/read the content
to/from the associated module's EPROM.
So, based on current FW design, we must supply the module num so fw
can find the corresponding I2C interface of the module to write/read.
Sponsored by: NVidia networking
MFC after: 1 week
Ensure all allocated tags have a hardware context associated.
The hardware context allocation is moved into the zone import
routine, as suggested by kib. This is safe because these zone
allocations are always done in a sleepable context.
I have removed the now pointless num_resources tracking,
and added sysctls / tunables to control UMA zone limits
for these tls tags, as well as a tunable to let the
driver pre-allocate tags at boot.
MFC after: 2 weeks
Change cdev_mgtdev_page_free_page to take an iterator, rather than an
object and page, so that removing the page from the object radix tree
can take advantage of locality with iterators. Define a
general-purpose function to free all pages, which can be used in
several places.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D47692
embedfs.S needs the right aarch64 features for BTI and/or PAC.
Obtained from: CheriBSD
Fixes: c2e0d56f5e ("arm64: Support BTI checking in most of the kernel")
Sponsored by: AFRL, DARPA
Add tso_tcp_flags_mask_first_segment, tso_tcp_flags_mask_middle_segment,
and tso_tcp_flags_mask_last_segment sysctl-variables to control the
handling of TCP flags during TSO.
This allows to change the masks appropriate for classical ECN and to
configure appropriate masks for accurate ECN.
MFC after: 3 days
Sponsored by: Netflix
Add tso_tcp_flags_mask_first_segment, tso_tcp_flags_mask_middle_segment,
and tso_tcp_flags_mask_last_segment sysctl-variables to control the
handling of TCP flags during TSO.
This allows to change the masks appropriate for classical ECN and to
configure appropriate masks for accurate ECN.
Reviewed by: rrs
MFC after: 3 days
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D44259
I found I was getting constant device timeouts when doing anything
more complicated than a single SSH on laptop with RTL8811AU.
After digging into it, i found a variety of fun situations, including
traffic stalls that would recover w/ a shorter (1 second) USB transfer
timeout. However, the big one is a straight up hang of any TX endpoint
until the NIC was reset. The RX side kept going just fine; only the
TX endpoints would hang.
Reproducing it was easy - just start up a couple of traffic streams
on different WME AC's - eg a best effort + bulk transfer, like
browsing the web and doing an ssh clone - throw in a ping -i 0.1
to your gateway, and it would very quickly hit device timeouts every
couple of seconds.
I put everything into a single TX EP and the hangs went away.
Well, mostly.
So after some MORE digging, I found that this driver isn't checking
if the transfers are going into the correct EPs for the packet
WME access category / 802.11 TID; and would frequently be able
to schedule multiple transfers into the same endpoint.
Then there's a second problem - there's an array of endpoints
used for setting up the USB device, with .endpoint = UE_ADDR_ANY,
however they're also being setup with the same endpoint configured
in multiple transfer configs. Eg, a NIC with 3 or 4 bulk TX endpoints
will configure the BK and BE endpoints with the same physical endpoint
ID. This also leads to timed out transfers.
My /guess/ was that the firmware isn't happy with one or both of the
above, and so I solved both.
* drop the USB transfer timeout to 1 second, not 5 seconds -
that way we'll either get a 1 second traffic pause and USB transfer
failure, or a 5 second device timeout. Having both the TX timeout
and the USB transfer timeout made recovery from a USB transfer
timeout (without a NIC reset) almost impossible.
* enforce one transfer per endpoint;
* separate pending/active buffer tracking per endpoint;
* each endpoint now has its own TX callback to make sure the queue /
end point ID is known;
* and only frames from a given endpoint pending queue is going
into the active queue and into that endpoint.
* Finally, create a local wme2qid array and populate it with the
endpoint mapping that ensures unique physical endpoint use.
Locally tested:
* rtl8812AU, 11n STA mode
* rtl8192EU, 11n STA mode (with diffs to fix the channel config / power
timeouts.)
Differential Revision: https://reviews.freebsd.org/D47522
Add tso_tcp_flags_mask_first_segment, tso_tcp_flags_mask_middle_segment,
and tso_tcp_flags_mask_last_segment sysctl-variables to control the
handling of TCP flags during TSO.
This allows to fix the masks appropriate for classical ECN and to
configure appropriate masks for accurate ECN.
Michael notes emperically 82599 has an unexpected middle mask:
Chip First Middle Last
82599 0xFF6 0xFF6 0xF7F
which should be fixed up to 0xF76 (RFC 3168) in a future commit.
Reviewed by: rrs, rscheff
MFC after: 3 days
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D44258
Once we set that we're doing the inversion workaround, there's no sense
continuing to search for the inversion workaround.
Sponsored by: Netflix
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D47686
When multiple IRQs are specified in a single resource then we only
check the first. Change this to check all interrupts for the value
we expect to find.
Without this we may still enable the interrupt, but it can have the
wrong polatiry or trigger. This can cause an interrupt storm if the
interrupt was configured with a level trigger when it should have
been an edge.
PR: 282241
Reported by: trasz
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D47487
The driver wasn't stable - it would start fine, but during scan
it would eventually hang and no further command endpoint transfers
would complete.
After adding some debugging and looking at the logs I noticed that
things went sideways once a /data/ frame was sent. The channel
change config happened between the data frame being sent and
being completed.
My guess is that the firmware doesn't like a channel change
and reset whilst there's pending data frames. Checking the Linux
driver I found that it was doing a flush before a channel change,
and we're doing it afterwards. This acts like a fence around
ensuring scheduled TX work has completed. In net80211 the
transmit path and the control path aren't serialised, so it's
very often the case that ioctls, state changes, etc occur
whilst in parallel there are frame transmits being scheduled.
This seems to happen more frequently on a more recent, high core
(8) machine with XHCI. I remember testing this driver years ago
on single and dual core CPU laptops with no problems.
So, add some flushes - before a channel change, and during
a transition to AUTH when the BSS config is being programmed into
the firmware. These two fences seem enough to reliably
associate as a 2GHz and 5GHz STA.
Note that this isn't entirely blocking all newly queued
transmit work from occuring until after the NIC has finished
configuration. That will need some further investigation.
Locally tested:
* Wistron NuWeb AR5523 dual-band NIC, STA mode, 2/5GHz
Differential Revision: https://reviews.freebsd.org/D47655
Use the correct ID, as I have one of these NICs.
Add the previous one back in case it's out there in the wild.
@emaste did a bit of a dig into the product numbers.
@sam did change the ID from 0x0828 -> 082a in a commit
a long while back. It's worth reading the code review for
further details.
However, I do have one of these NICs and I verified that
it indeed has the given ID, and with some follow-up work
to fix some race conditions, it works fine in 2GHz 11bg
and 5GHz 11a operation.
Differential Revision: https://reviews.freebsd.org/D47654
Obtained from: Linux, drivers/net/wireless/ath/ar5523/ar5523.c
This will be useful when fixing up the sequence number generation
and checks, as the rules around how sequence numbers are generated
have been clarified in 802.11-2016 and later. QoS-NULL frames are
explicitly marked as "any sequence number".
But for now, just create a macro and use it in the one place
it's currently being used as a check - ath(4).
* Add IEEE80211_IS_QOS_NULL().
* Change the "will this frame go into the TX block-ack window" check
in the ath(4) transmit path. Note this changes the check to be
more specific, but both paths already had previous checks to ensure
they're QoS data frames.
Locally tested:
* ath(4), AR9380, STA mode w/ AMPDU TX/RX enabled and negotiated
Differential Revision: https://reviews.freebsd.org/D47645
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
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
* Add macros for the management and control frame type checks that
I've come across in the drivers.
* Delete some now old code (eg ath's ieee80211_is_action()) as there's now
a macro for it.
Local testing:
* not yet, I have a lot of wifi devices to find and test against
Differential Revision: https://reviews.freebsd.org/D47500
Add the SOC_ALLWINNER_D1 config option, following other platforms.
Co-authored-by: mhorne
Reviewed by: manu (previous version)
Sponsored by: The FreeBSD Foundation (in part)
Differential Revision: https://reviews.freebsd.org/D47515
This is a relatively well known trick for the X520 (82599), can be
useful for testing and lab settings. It's not an official standard or
particularly common but ubiquitous Broadcom switch ASICs deal with it.
We'll call it 1000Base-KX because it's SerDes on the passive cable and
I don't think it's worth adding another media type for this.
Reviewed by: emaste
MFC after: 1 week
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D47352
Only ever set the capabilities bits if kernel options are enabled.
Check for hardware capabilities before setting software bits.
Sponsored by: NVidia networking
MFC after: 1 week
Correct leading whitespace for a few lines.
Consistently use more canonical #ifdef to test for COMPAT_FREEBSD32.
Obtained from: CheriBSD
Sponsored by: AFRL, DARPA
This isn't really needed since the host driver never submits more
commands to a queue than it can hold, but I noticed that the
recently-added SQ head and tail sysctl nodes were not updating. This
fixes that and also uses these values to assert that there we never
submit a command while a queue pair is full.
Sponsored by: Chelsio Communications
Similar to nvme(4), use the current CPU to select which I/O queue to
use. The assignment in nvmf_attach() had to be moved down since
sc->num_io_queues is initialized in nvmf_establish_connection().
Note that nvmecontrol(8) still defaults to using a single I/O queue
for an association.
Sponsored by: Chelsio Communications
By inspection, index increment was missing.
PR: 281843
Reported by: Matt Jacobson
Reviewed by: bz, markj
Fixes: e4611d2626 ("usb(4): Call optional endpoint_uninit() when changing configuration or alternate setting.")
Sponsored by: The FreeBSD Foundation
There are some contexts where it is safe to sleep, so we should pass
M_WAITOK to ensure that a null pointer dereference can't happen.
A few places allocate with M_NOWAIT but have no way to signal an error.
Flag those with an XXX comment.
PR: 276770
Reviewed by: imp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D47307
Some iichid(4) child devices, currently hkbd(4) only, opens parent
device in their attach handlers. That breaks internal iichid(4) state
leading to rejecting any incoming data on software and hardware levels.
Fix it with adding of extra state check in iichid(4) attach handler.
Reported by: many
Submitted by: trasz (initial version)
PR: 280290
MFC after: 3 days
