critical_exit().
Based on the discussion with: jhb
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential revision: D9276
MFC after: 1 week
overwrites an existing file rather than removing it and creating a
new file. If the old and new version of the file both have extended
attributes and the extended attributes of the two versions of the
file are different, the result is that the new file ends up with
the union of the extended attributes of the old and new files.
To get the behavior of replacing the extended attributes rather
than augmenting them requires explicitly removing the old attributes
and then adding the new ones.
To get this behavior, the old file must be unlinked (which clears
out the old extended attributes). Then the new file of the same
name must be created and the new extended attributes added to it.
This behavior can be obtained by specifying the -u flag when running
restore. Rather than defaulting the -u option to on and possibly
breaking existing scripts using restore, this change simply notes
in the restore.8 manual page that the -u flag is recommended when
using restore on filesystems that contain extended attributes.
PR: 216127
Reported by: dewayne at heuristicsystems.com.au
Differential Revision: https://reviews.freebsd.org/D9208
The delta here is just between the current TX/RX copmletion and the previous
TX/RX completion. The metadata needed to link TX descriptor timestamps to their
/completion/ timestamp isn't there yet.
Our base binutils sets -many by default anyway, but external gcc may not do
this.
PR: kern/215948
Submitted by: Mark Millard <markmi AT dsl-only DOT net>
Reported by: Mark Millard
MFC after: 2 weeks
This is supposed to only be applied to the first subframe and only if
RTS/CTS is being done. I'm still not yet checking RTS/CTS exchange status
so it's just happening for all subframes on AR9380 and later.
This gets MCS23 throughput up from around 250mbit to 303mbit with RTS/CTS
protection enabled, and around 330mbit with no HT protection enabled.
Now, MCS23 has a PHY rate of 450mbit and we should be seeing closer to
400mbit for a straight one-way UDP test, but this beats the previous
maximum throughput.
Tested:
* AR9380 (STA) -> AR9580 (AP) - STA with the modifications, doing UDP TX
test using iperf.
mappings for armv6 pmap zero and copy operations to the MD PCPU region.
Change sysmap initialization to only allocate KVA pages for CPUs that
are actually present.
While here, collapse CMAP3 into CMAP2 (their use was mutually exclusive
anyway) and "recover" some space in PCPU padding that has always been
available due to 64-byte cacheline padding.
Reviewed by: skra
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D9172
descriptor state will not change anymore). This seems to eliminate the
race where we can miss a stalled queue under high load.
While here remove the unnecessary curly brackets.
Reported by: Konstantin Kormashev <konstantin@netgate.com>
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC (Netgate)
Set both IEEE80211_HTCAP_LDPC and IEEE80211_HTC_TXLDPC capability flags
if LDPC is supported + set 'do_ldpc = 1' only when it is not disabled,
not just supported.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D9277
- Pad small packets to 60 bytes and not 64 (exclude the CRC bytes);
- Pad the packet using m_append(9), if the packet has enough space for
padding, which is usually true, it will not be necessary append a newly
allocated mbuf to the chain.
Suggested by: yongari
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC (Netgate)
It is only a first step and not perfect, but better then nothing.
The main blocker is CAM target frontend, that can not be unloaded,
since CAM does not have mechanism to unregister periph driver now.
MFC after: 2 weeks
Stop testing for LK_RETRY and error multiple times. Also postpone the
VI_DOOMED until after LK_RETRY was seen as it reads from the vnode.
No functional changes.
Note that mandoc does not use anymore sqlite3 but a home made database format
An important improvement has been made as well in makewhatis performance:
Tests on my laptop shows makewhatis on the entire system goes from 26s to 12s
A recent change enforced the VAP limit as well as the peer limit.
I now need to actually set iv_ampdu_limit or we don't transmit more
than 8K sized aggregates.
This restores the expected (suboptimal, but still much faster) behaviour.
Tested:
* AR9380, STA mode
CID 1341620 Fix a small memory leak
CID 1341630 Though this is technically a false positive, rearrange the
code for clarity.
CID 1341635 Eliminate dead code
CID 1368663 Fix a double mutex unlock in the error path
Also:
* Use sig_atomic_t for variables accessed from signal handlers
* Don't conditionalize free(3) on its argument being non-null
Reported by: Coverity
CID: 1341620 1341630 1341635 1368663
Reviewed by: ken
MFC after: 4 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D9237
CID 1229913 Fix output of "camcontrol persist -i report_capabilities".
The reported Persistent Reservation Types were wrong in all
cases.
CID 1356029 Annotate the code so Coverity will know that this is a false
positive.
CID 1366830 Fix a memory leak in "camcontrol timestamp -s"
CID 1366832 Fix a segfault that could be caused by bad drive firmware
Also, fix the man page entry for the "camcontrol epc state" command to match
what the code does.
Reviewed by: ken, wblock
MFC after: 4 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D9239
SDM states that CLFLUSHOPT instructions can be ordered with other
writes by SFENCE, heavier MFENCE is not required.
Reviewed by: alc
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
The length of the scsi_set_timestamp_parameters struct was incorrect. LTO-5
drives don't care, but LTO-7 drives do.
Reviewed by: Sam Klopsch
MFC after: 2 weeks
Sponsored by: Spectra Logic Corp
configtimer().
During normal operation "state->nextcallopt" will always be less than
or equal to "state->nextcall" and checking only "state->nextcallopt"
before calling "callout_process()" is sufficient. However when
"configtimer()" is called a race might happen requiring both of these
binary times to be checked.
Short description of race:
1) A configtimer() call will reset both "state->nextcall" and
"state->nextcallopt" to the same binary time.
2) If a "callout_reset()" call happens between "configtimer()" and the
next "callout_process()" call, "state->nextcallopt" will get updated
and "state->nextcall" will remain at the current time. Refer to logic
inside cpu_new_callout().
3) getnextcpuevent() only respects "state->nextcall" and returns this
value over and over again, even if it is in the past, until "now >=
state->nextcallopt" becomes true. Then these two time variables are
corrected by a "callout_process()" call and the situation goes back to
normal.
The problem manifests itself in different ways. The common factor is
the timer process(es) consume all CPU on one or more CPU cores for a
long time, blocking other kernel processes from getting execution
time. This can be seen by very high interrupt counts as displayed by
"vmstat -i | grep timer" right after boot.
When EARLY_AP_STARTUP was enabled in r310177 the likelyhood of hitting
this bug apparently increased.
Example output from "vmstat -i" before patch:
cpu0:timer 7591 69
cpu9:timer 39031773 358089
cpu4:timer 9359 85
cpu3:timer 9100 83
cpu2:timer 9620 88
Example output from "vmstat -i" after patch:
cpu0:timer 4242 34
cpu6:timer 5531 44
cpu3:timer 6450 52
cpu1:timer 4545 36
cpu9:timer 7153 58
Before the patch cpu9 in the example above, was spinning in a loop in
order to reach 39 million interrupts just a few seconds after
bootup. After the patch the timer interrupt counts are more or less
consistent.
Discussed with: mav @
Reported by: several people
MFC after: 1 week
Sponsored by: Mellanox Technologies
