Panasas was seeing a higher-than-expected number of link-flap events.
After joint debugging with the switch vendor, we determined there were
problems on both sides; either of which might cause the occasional
event, but together caused lots of them.
On the switch side, an internal queuing issue was causing LACP PDUs --
which should be sent every second, in short-timeout mode -- to sometimes
be sent slightly later than they should have been. In some cases, two
successive PDUs were late, but we never saw three late PDUs in a row.
On the FreeBSD side, we saw a link-flap event every time there were two
late PDUs, while the spec says that it takes *three* seconds of downtime
to trigger that event. It turns out that if a PDU was received shortly
before the timer code was run, it would decrement less than a full
second after the PDU arrived. Then two delayed PDUs would cause two
additional decrements, causing it to reach zero less than three seconds
after the most-recent on-time PDU.
The solution is to note the time a PDU arrives, and only decrement if at
least a full second has elapsed since then.
Reported by: Greg Foster <gfoster@panasas.com>
Reviewed by: gallatin
Tested by: Greg Foster <gfoster@panasas.com>
MFC after: 3 days
Sponsored by: Panasas
Differential Revision: https://reviews.freebsd.org/D35070
The use of devclass_get_softc() combined with cdev unit numbers is
probably not ideal (probably should be initializing si_drv1 when each
cdev is created instead), but it looks like a bit of a PITA to do, so
just initialize the devclass explicitly instead.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D35060
AEAD ciphers for IPsec combine both encryption and authentication. As
such, ESP configurations using an AEAD cipher should not use a
seperate authentication algorithm via -A. However, this was not
apparent from the setkey manpage and 12.x and earlier did not perform
sufficient argument validation permitting users to pair an explicit -A
such as SHA256-HMAC with AES-GCM. (The result was a non-standard
combination of AES-CTR with the specified MAC, but with the wrong
initial block counter (and thus different keystream) compared to using
AES-CTR as the cipher.)
Attempt to clarify this in the manpage by explicitly calling out AEAD
ciphers (currently only AES-GCM) and noting that AEAD ciphers should
not use -A.
While here, explicitly note which authentication algorithms can be
used with esp vs esp-old. Also add subsection headings for the
different algorithm lists and tidy some language.
I did not convert the tables to column lists (Bl -column) though that
would probably be more correct than using literal blocks (Bd
-literal).
PR: 263379
Reviewed by: Pau Amma <pauamma@gundo.com>, markj
Differential Revision: https://reviews.freebsd.org/D34947
The 'failed to write TX skb to HCI' error message is twice in the code.
Print the function name and along with the message and also the reported
error so it can possibly be helpful.
The 'failed to get tx report from firmware' was purposefully changed
away from debugging in the upstream Linux driver in
584dce175f0461d5d9d63952a1e7955678c91086 . Revert that decision and
extend the logging by the actual queue length so we get an idea how
sever the problem is (see PR for a report).
PR: 248235
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
X-MFC: only to get the reminder for later
Padding was added to __cxa_exception in 45ca8b19 and
__cxa_dependent_exception needs the same layout.
Add some static_asserts to detect this in the future.
Merge of libcxxrt commit b00c6c564357
Apparently some ports on arm require these symbols, and while they were
available in llvm's libunwind, they were never exported via the arm
specific Symbol.map. Put them in the same version block as gcc does
(GCC_3.5).
Reported by: Robert Clausecker <fuz_at_fuz.su>
MFC after: 3 days
We should call cam_periph_async() always, like SCSI does. This routine
is supposed to be more of a catch-all.
cam_periph_async() only does actions for AC_LOST_DEVICE. It ignores all
other events (today), but this may not always be true. So this is a nop
change.
Drop in a 'break' so we don't fall through unnecessarily.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D35057
To avoid annoyng messages from glibc-2.35 test suite add the simple
implementation of rseq syscall which is do nothing for now.
I plan to implement it if and when the API stabilizes.
MFC after: 2 weeks
In vm_phys_alloc_contig, for an allocation bigger than the size of any
buddy queue free block, avoid examining any maximum-size free block
more than twice, by only starting to consider a sequence of adjacent
max-blocks starting at a max-block that does not follow another
max-block. If that first max-block follows adjacent blocks of smaller
size, and if together they provide enough memory to reduce by one the
number of max-blocks required for this allocation, use them as part of
this allocation.
Reviewed by: markj
Tested by: pho
Discussed with: alc
Differential Revision: https://reviews.freebsd.org/D34815
While here, use driver->name instead of hardcoding the xenpv and
xen_et strings both for devclass_find() and BUS_ADD_CHILD().
Reviewed by: Elliott Mitchell <ehem+freebsd@m5p.com>, imp, royger
Differential Revision: https://reviews.freebsd.org/D35001
We never use the cgd that we get from the XPT_GDEV_TYPE call. Prior to
9a6844d55f we used it to determine if READ AHEAD or WRITE CACHING was
supported. However, all that information was moved into adasetflags so
we no longer need to this since it's cached in the softc and updated
with the IDENTIFY data changes automatically.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D35039
Use a switch rather than a nested if to simplify the async event
processing code. No functional changes intended.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D35038
When running binaries compiled with libasan in PIE and with ALSR on,
the previous code always print the WARNING message, the new code only
printed it if the run is made with the right verbosity
Before this change, many unit test will always fail because of the extra
message which is printed
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D35055
MFC after: 2 weeks
Disable preemption in seqlock write sections when using the _irqsave
variant. This ensures that a writer can't be preempted and subsequently
starved by a reader running in a callout handler on the same CPU.
This fixes occasional display hangs seen when using the i915 driver.
Tested by: emaste, wulf
Reviewed by: wulf, hselasky
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35021
In ieee80211_sn_sub() we need to shift the mask before applying it.
This fixes the logic from 978f25e840.
Reported by: J.R. Oldroyd (fbsd opal.com)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Our kern_sigtimedwait() calculates absolute sleep timo value as 'uptime+timeout'.
So, when the user specifies a big timeout value (LONG_MAX), the calculated
timo can be less the the current uptime value.
In that case kern_sigtimedwait() returns EAGAIN instead of EINTR, if
unblocked signal was caught.
While here switch to a high-precision sleep method.
Reviewed by: mav, kib
In collaboration with: mav
Differential revision: https://reviews.freebsd.org/D34981
MFC after: 2 weeks
Created a couple of helpers to send signals to the specific thread or to
the whole process. Use helpers in the corresponding syscalls.
This fixes the confusion where a signal destined for a whole process
was sent to a specific thread and vice versa.
There is an exclusion for the linux_kill() syscall that takes a pid
argument and should send a signal to the whole process, but I know
at least one example where kill() takes tid.
MFC after: 2 weeks
wasn't default
Since vte_reset changes register value to MDCSC_DEFAULT value, which may not
be the original value, thus causing some phy registers read failures.
Restoring VTE_MDCSC value to original after reset solves the link state
flapping issue.
Thanks to jhb ("the code looks ok") for his review.
Reviewed by: jhb
Obtained from: NetBSD via Andrius V
Differential Revision: https://reviews.freebsd.org/D34956
The contract with the lower layers is that once ENXIO is reported, all
further I/O to the device is not possible. This is reported when the
device departs for good or changes in some material manner out from
underneath the system. Since the lower layers terminate all pending I/O
when this is detected with ENXIO, reporting more than one provides no
extra value. ENXIO suppression done with atomics due to race described
in e8827f4094. It's on the error path and a rare event, so this won't affect
performance.
Sponsored by: Netflix
Reviewed by: mckusick, kib
Differential Revision: https://reviews.freebsd.org/D35034
On the 0 -> 1 transition of sc_enxio_active, report that we're doing
this. This is a rare, but interesting, event. Convert to using atomics
to set this field to prevent a rare race:
In CAM, when we invalidate a device, one thread (T1) will start the
process in error processing called from *dadone
(cam_periph_error). This routine will queue work to xpt_async_td
(T2) and indicate to *dadone to call biodone(ENXIO) for the bio. T2
wakes up and basically waits to acquire the periph lock. T2 will do
so when T1 drops the periph lock just before T1's call to
biodone. T2 acquires the lock and calls biodone(ENXIO) on all
pending bios. These two threads will race and we could lose the
printf or get two in rare cases. Since we only touch sc_enxio_active
in an error path that's infrequent, the extra atomic traffic will be
rare but will ensure robustness.
Sponsored by: Netflix
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D35037
The BIO_SPEEDUP_WRITE and BIO_SPEEDUP_TRIM bits are part of the flags
word, so print them as such.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D35035
