Omit unused rates while initializing / dumping Tx power values.
They were not accessed anywhere (except for debugging), so this is
(mostly) no-op.
Tested with
* RTL8188EU, STA mode.
* RTL8812AU, STA mode.
Found by: PVS-Studio
1. Deadcode in ecore_init_cache_line_size(), qlnx_ioctl() and
qlnx_clean_filters()
2. ARRAY_VS_SINGLETON issue in qlnx_remove_all_mcast_mac() and
qlnx_update_rx_prod()
MFC after:5 days
If the ExchangeID/CreateSession operations done by an NFSv4.1 client
after the server crashes/reboots fails, it is possible that some process/thread
is waiting for an open_owner lock. If the client state is free'd, this
can cause a crash.
This would not normally happen, but has been observed on a mount of the
AmazonEFS service.
Reported by: cperciva
Tested by: cperciva
PR: 216086
MFC after: 2 weeks
during recovery.
If the NFSv4.1 client gets a NFSv4.1 NFSERR_BADSESSION reply to an Open/Lock
operation while recovering from the server crash/reboot, allow the opens
to be retained for a subsequent recovery attempt. Since NFSv4.1 servers
should only reply NFSERR_BADSESSION after a crash/reboot that has lost
state, this case should almost never happen.
However, for the AmazonEFS file service, this has been observed when
the client does a fresh TCP connection for RPCs.
Reported by: cperciva
Tested by: cperciva
PR: 216088
MFC after: 2 weeks
if_vlan(4) interfaces inherit IPv4 checksum offloading flags from the
parent when VLAN_HWCSUM and VLAN_HWTAGGING flags are present on the
parent interface. Do the same for IPv6 checksum offloading flags.
Reported by: Harry Schmalzbauer
Reviewed by: np, gnn
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D10356
With the zfs probe cleanup, the mistake did slip in the probe code;
instead of reading the pool GUID for the actual boot device (partition),
we read GUID for first found pool from the boot disk.
This will break the case when there are both zfs pool and ufs on the boot
disk, and the ufs is used for boot, not zfs.
Reviewed by: smh
Differential Revision: https://reviews.freebsd.org/D10359
administrator.
This restores the behavior that was prior to r274246.
No objection from: #network
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D10215
Instead, issue a diagnostic and return appropriate error if
ncl_flush() was unable to clean buffer queue after the specified
number or retries.
Reviewed by: rmacklem
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
This is in preparation for A-MSDU decap in A-MPDU support.
* refactor out the code to purge a single reorder slot into ampdu_rx_purge_slot().
* refactor out the code to add a frame to the given reorder slot
to ampdu_rx_add_slot().
This should be a big no-op as far as current code is concerned.
Tested:
* QCA9880v2, STA mode (11ac)
* iwn(4), STA mode (11n)
Reviewed by: avos
Differential Revision: https://reviews.freebsd.org/D10328
Larry Rosenman reported a crash on freebsd-current@ which was caused by
a premature release of the krpc backchannel socket structure.
I believe this was caused by a race between the SVC_RELEASE() in clnt_vc.c
and the xprt_unregister() in the higher layer (clnt_rc.c), which tried
to lock the mutex in the xprt structure and crashed.
This patch fixes this by removing the xprt_unregister() in the clnt_vc
layer and allowing this to always be done by the clnt_rc (higher reconnect
layer).
Reported by: ler@lerctr.org
Tested by: ler@letctr.org
MFC after: 2 weeks
The AmazonEFS NFSv4.1 server does not support the FILES_FREE and FILES_TOTAL
attributes. As such, an NFSv4.1 mount to the server would return garbage
for these values. This patch initializes the fields of the nfsstatfs structure,
so that "df" and friends will at least return consistent bogus values.
This patch should have effect when mounting other NFSv4.1 servers.
Reported by: cperciva
MFC after: 2 weeks
We are otherwise susceptible to a race with a concurrent vm_map_wire(),
which may drop the map lock to fault pages into the object chain. In
particular, vm_map_protect() will only copy newly writable wired pages
into the top-level object when MAP_ENTRY_USER_WIRED is set, but
vm_map_wire() only sets this flag after its fault loop. We may thus end
up with a writable wired entry whose top-level object does not contain the
entire range of pages.
Reported and tested by: pho
Reviewed by: kib
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D10349
This update does add the code to pass partition size to vdev_probe() via
simple callback. Tested via tinderbox build, but not yet with actual boot.
The code can be improved still, but to verify the idea to read media
block size and amedia size has to be confirmed first.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D10302
Entries may be removed and freed if an I/O error occurs during mirror
synchronization, so we cannot assume that all entries of ds_bios are
valid.
Also ensure that a synchronization BIO's array index is preserved after
a successful write.
Reported and tested by: pho
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Arm64 pmap interprets accessed writable ptes as modified, since
ARMv8.0 does not track Dirty Bit Modifier in hardware. If writable bit
is removed, page must be marked as dirty for MI VM.
This change is most important for COW, where fork caused losing
content of the dirty pages which were not yet scanned by pagedaemon.
Reviewed by: alc, andrew
Reported and tested by: Mark Millard <markmi@dsl-only.net>
PR: 217138, 217239
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Switched from using timestamps to RTT estimates when performing TCP receive
buffer auto resizing, as not all hosts support / enable TCP timestamps.
Disabled reset of receive buffer auto scaling when not in bulk receive mode,
which gives an extra 20% performance increase.
Also extracted auto resizing to a common method shared between standard and
fastpath modules.
With this AWS S3 downloads at ~17ms latency on a 1Gbps connection jump from
~3MB/s to ~100MB/s using the default settings.
Reviewed by: lstewart, gnn
MFC after: 2 weeks
Relnotes: Yes
Sponsored by: Multiplay
Differential Revision: https://reviews.freebsd.org/D9668
like I hoped, since they are needed for removing parts over the border.
Continue fixing bugs in them.
In the vga planar mode renderer, remove removal of the part of the
image over the text window. This was hard-coded for nearly 8x16 fonts
and in practice didn't remove enough for 8x8 fonts. This used the
wrong attribute over cutmarked regions. The caller refreshes with the
correct attribute later, so the attribute bug only caused flicker.
The caller uses the same hard-coding, so the refreshes fix up all the
spots with the wrong attribute, but keep missing the missed spots.
This still gives trails of bits of cursors for cursor motions in the
affected configurations (mainly depth 4 modes with 8x8) fonts. 8x14
fonts barely escape the problem since although the cursor is drawn
as 16x16, its active part is only 9x13 and the active part fits in
the hard-coded 2x2 character cell window for 8x14 fonts. 8x8 fonts
need a 2x3 window.
In the fb non-sparc64 renderer, the buggy image removal was buggier
and was already avoided by returning before it. Remove it completely
and fix nearby style bugs. It was essentially the same as for the vga
planar mode renderer (obfuscated by swapping x and y). This was buggier
since fb should handle more types of hardware so the hard-coding is
wronger.
The remaining fb image removal is also buggier. It never supported
software cursors drawn into the border, and the hardware cursor is
probably broken by other bugs to be fixed soon.
This patch gives a requestor of the exclusive lock on the client state
in the NFSv4 client priority over shared lock requestors. This avoids
the server crash recovery thread being starved out by other threads doing
RPCs.
Tested by: cperciva
PR: 216087
MFC after: 2 weeks
When the NFSv4 client Commit operation encountered a stale write verifier,
it erroneously mapped that to EIO. This could have caused recently written
data to be lost when a server crashes/reboots between an UNSTABLE write
and the subsequent commit. This patch fixes this.
The bug was only for the NFSv4 client and did not affect NFSv3.
Tested by: cperciva
PR: 215887
MFC after: 2 weeks
For the ReclaimComplete operation, the RPC layer should not loop on
NFSERR_BADSESSION. If it does, the recovery thread (nfscl) can get stuck
looping and will not do a recovery.
This patch fixes it so it does not loop. This bug only affects NFSv4.1 and
only when a server reboots.
Tested by: cperciva
PR: 215886
MFC after: 2 weeks
imx6 based on a single cortex-a7 core. Other changes to imx6 drivers
and support code are needed to fully support the imx6ul.
Also fix an indentation glitch committed in the prior change.
driver for imx6. Some newer dts source puts the GIC node at the root
instead of under /soc, so look in both places. Also, sometimes the GIC
node doesn't list itself as its own interrupt-parent, allow that too.
At this point, INTRNG is not going away (the option may go away, but the
code is not), so we no longer need code to support workarounds that handled
the lack of INTRNG functionality.
If an operation that preceeds a Setattr in an NFSv4 compound fails,
there is no bitmap of attributes to parse. Without this patch, the
parsing would fail and return EBADRPC instead of the correct failure
error. This could break recovery from a server crash/reboot.
Tested by: cperciva
PR: 215883
MFC after: 2 weeks
The work to implement zfs reader to inspect all pool label copies did
miss the userboot, this update does correct this issue.
Since userboot is already using common/disk.c API (disk_open() etc),
the fix is quite simple - we only need to make sure the userdisk_iocl()
will call disk_ioctl(). In addition, the diskioctl callback does return
int, not pointer.
Note, the review request is actually addressing the sparc and userboot,
but as testing the fix for sparc will take some more time, I am posting the
userboot fix now.
This patch is part of the implementation presented in review:
https://reviews.freebsd.org/D10302
Once we have the sparc part tested, we will have the complete fix
for the issue.
Reviewed by: imp
The MFC will include a compat definition of smp_no_rendevous_barrier()
that calls smp_no_rendezvous_barrier().
Reviewed by: gnn, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D10313
- renaming l_ifreq::ifru_metric to l_ifreq::ifru_ivalue;
- adding a definition for ifr_ifindex which points to l_ifreq::ifru_ivalue.
A quick search indicates that Linux already got the above changes since 2.1.14.
Reviewed by: kib, marcel, dchagin
MFC after: 1 week
This is applicable only to the older processors that do not have the AMD
Topology extension.
Opteron 6100-series "Magny-Cours" processors had multiple nodes within a
package and didn't have the Topology extension. Without this change
FreeBSD would assume that those processors have a single L3 cache shared
by all cores while, in fact, each node has its own L3 cache.
Many thanks to Freddie Cash <fjwcash@gmail.com> for providing valuable
hardware information.
MFC after: 2 weeks
(that is, in all supported 8, 15, 16 and 24-color modes). Moving the
mouse cursor while holding down a button (giving cut marking) left a
trail of garbage from misremoved mouse cursors (usually colored
rectangles and not cursor shapes). Cases with a button not held down
worked better and may even have worked.
No renderer support for removing (software) mouse cursors is needed
(and many renderers don't have any), since sc_remove_mouse_image()
marks for update the region containing the image and usually much
more. The mouse cursor can be (partially) over as many as 4 character
cells, and removing it in only the 1-4 cells occupied by it would be
best for efficiency and for avoiding flicker. However,
sc_remove_mouse_image() can only mark a single linear region and
usually marks a full row of cells and 1 more to be sure to cover the
4 cells. It always does this, so using the special rendering method
just wastes even more time and gives even more flicker. The special
methods will be removed soon.
The general method always works. vga_pxlmouse_direct() appeared to
defer to it by returning immediately if !on. However,
vga_pxlmouse_direct() actually did foot-shooting using a disguised
saveunder method. Normal order near a mouse move is:
(1) remove the mouse cursor in the renderer (optional)
(2) remove the mouse cursor again and refresh the screen over the
mouse cursor and much more from the vtb. When the mouse has
actually moved and a button is down, many attributes in this
region are changed to be up to date with the new cut marking
(3) draw the keyboard cursor again if it was clobbered by the update
(4) draw the mouse cursor image in its new position.
The bug was to remove the mouse cursor again in step (4), before the
drawing it again in (4), using a saveunder that was valid in step (1)
at best. The quick fix is to use the saveunder in step (1) and not
in step (4). Using it in step (4) also used it before it was
initialized, initially and after mode and screen switches.
in the vga renderer. Removal used stale attributes and didn't try to
merge with the current attribute for cut marking, so special rendering
of cut marking was lost in many cases. The gfb renderer is too broken
to support special rendering of cut marking at all, so this change is
supposed to be just a style fix for it. Remove all traces of the
saveunder method which was used to implement this bug.
Fix drawing of the cursor image in text mode, only in the vga
renderer. This used a stale attribute from the frame buffer instead
of from the saveunder, but did merge with the current attribute for
cut marking so it caused less obvious bugs (subtle misrendering for
the character under the cursor).
The saveunder method may be good in simpler drivers, but in syscons
the 'under' is already saved in a better way in the vtb. Just redraw
it from there, with visible complications for cut marking and
invisible complications for mouse cursors. Almost all drawing
requests are passed a flag 'flip' which currently means to flip to
reverse video for characters in the cut marking region, but should
mean that the the characters are in the cut marking regions so should
be rendered specially, preferably using something better than reverse
video. The gfb renderer always ignores this flag. The vga renderer
ignored it for removal of the text cursor -- the saveunder gave the
stale rendering at the time the cursor was drawn. Mouse cursors need
even more complicated methods. They are handled by drawing them last
and removing them first. Removing them usually redraws many other
characters with the correct cut marking (but transiently loses the
keyboard cursor, which is redrawn soon). This tended to hide the
saveunder bug for forward motions of the keyboard cursor. But slow
backward motions of the keyboard cursor always lost the cut marking,
and fast backwards motions lost in for about 4 in every 5 characters,
depending on races with the scrn_update() timeout handler. This is
because the forward motions are usually into the region redrawn for
the mouse cursor, while backwards motions rarely are.
Text cursor drawing in the vga renderer used also used a
possibly-stale copy of the character and its attribute. The vga
render has the "optimization" of sometimes reading characters from the
screen instead of from the vtb (this was not so good even in 1990 when
main memory was only a few times faster than video RAM). Due to care
in update orders, the character is never stale, but its attribute
might be (just the cut marking part, again due to care in order).
gfb doesn't have the scp->scr pointer used for the "optimization", and
vga only uses this pointer for text mode. So most cases have to
refresh from the vtb, and we can be sure that the ordering of vtb
updates and drawing is as required for this to work.
GNU toolchain does not recognize LR as standard register alias,
but clang does. Use of #define will work on both. Place the
definition into central machine/asm.h instead of patching every
affected file, as requested by plaftorm maintainers.
Reviews by: andrew, emaste, imp
Differential Revision: https://reviews.freebsd.org/D10307
