The patch in the PR largely no longer applied due to age, but
thanks to Evgeniy Khramtsov for the patches in the PR.
PR: 120024
Reported by: bcran
Approved by: blackend (mentor)
Obtained from: Evgeniy Khramtsov <evgeniy@khramtsov.org> (partly)
If copyin family of routines fault, kernel does clear PSL.AC on the
fault entry, but the AC flag of the faulted frame is kept intact. Since
onfault handler is effectively jump, AC survives until syscall exit.
Reported by: m00nbsd, via Sony
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
admbugs: 975
Since periph_runccb now handles all the polling stuff, and
xpt_polled_action is now unused and can be removed.
Sponsored by: Netflix
Reviewed by: mav@
Differential Revision: https://reviews.freebsd.org/D30394
Nothing is using the sim callout to unfreeze the queue. Remove it to
simplify the SIM. This was introduced in the original CAM commit in 1998
but setting the CAM_SIM_REL_TIMEOUT_PENDING flag was removed in 1999 in
commit 87cfaf0e1f which reworked how bus reset worked. That work was
merged just after 3.2R was released. Remove the unused residuals.
Sponsored by: Netflix
Reviewed by: scottl@, mav@
Differential Revision: https://reviews.freebsd.org/D30383
Summary:
Log the vm_fault() error in the data_abort panic so it is easier to
find the reason vm_fault() failed (e.g., invalid address).
Reviewed by: andrew
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D30362
The push bit itself was also not actually being properly moved to
the right edge. The FIN bit was incorrectly on the left edge. We
fix these two issues as well as plumb in the mtu_change for
alternate stacks.
Reviewed by: mtuexen
Sponsored by: Netflix Inc
Differential Revision: https://reviews.freebsd.org/D30413
When we create an nvlist and insert it into another nvlist we must
remember to destroy it. The nvlist_add_nvlist() function makes a copy,
just like nvlist_add_string() makes a copy of the string. If we don't
we're leaking memory on every (nvlist-based) ioctl() call.
While here remove two redundant 'break' statements.
PR: 255971
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC ("Netgate")
The man page SYNOPSIS for EARLY_DRIVER_MODULE() shows that it has
an "enum sysinit_elem_order order" argument.
The actual macro in sys/bus.h does not have an order argument.
PR: 256103
Reported by: J.R. Oldroyd <fbsd at opal dot com>
Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D30411
These files have been unused ever since the OpenSolaris import
Sponsored by: Axcient
MFC after: 2 weeks
Reviewed By: freqlabs
Differential Revision: https://reviews.freebsd.org/D30371
Early in the arm64 pmap code we need to translate between a virtual
address and a physical address. Rather than manually walking the page
table we can ask the hardware to do it for us.
Reviewed by: kib, markj
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D30357
- Process the list of local IPs once instead of once per adapter. Add
addresses from all VNETs to the driver's list but leave hardware
updates for later when the global VNET/IFADDR list locks have been
released.
- Add address to the hardware table synchronously when a CLIP entry is
requested for an address that's not already in there.
- Provide ioctls that allow userspace tools to manage addresses in the
CLIP table.
- Add a knob (hw.cxgbe.clip_db_auto) that controls whether local IPs are
automatically added to the CLIP table or not.
MFC after: 2 weeks
Sponsored by: Chelsio Communications
This fixes inability to start USB xfers in a case when FIFO has been
already open()-ed but no read() or poll() calls has been issued yet.
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D30343
This fixes lose of evdev events after moused has been killed.
While here use bitwise operations for UMS_EVDEV_OPENED flag.
Reviewed by: hselasky
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D30342
With this patch:
% dmesg | grep -i uart
uart2: <Intel Gemini Lake SIO/LPSS UART 0> mem 0xa1426000-0xa1426fff,0xa1425000-0xa1425fff irq 4 at device 24.0 on pci0
uart3: <Intel Gemini Lake SIO/LPSS UART 1> mem 0xa1424000-0xa1424fff,0xa1423000-0xa1423fff irq 5 at device 24.1 on pci0
uart4: <Intel Gemini Lake SIO/LPSS UART 2> mem 0xfea10000-0xfea10fff irq 6 at device 24.2 on pci0
uart5: <Intel Gemini Lake SIO/LPSS UART 3> mem 0xa1422000-0xa1422fff,0xa1421000-0xa1421fff irq 7 at device 24.3 on pci0
PR: 256101
Submitted by: Daniel Ponte <amigan@gmail.com>
MFC after: 1 week
Else recursive use of EPOCH(9) may cause the wrong priority to be restored.
Bump the __FreeBSD_version due to changing the thread and epoch tracker
structure.
Differential Revision: https://reviews.freebsd.org/D30375
Reviewed by: markj@
MFC after: 1 week
Sponsored by: Mellanox Technologies // NVIDIA Networking
It turns out that, silly adrian, setting it to 64 means only two
AMPDU frames of 32 subframes each. Thus, whilst those are in-flight,
any subsequent queues frames to that node get dropped.
This ends up being pretty no bueno for performance if any receive
is also going on at that point.
Instead, set it to 128 for the time being to ensure that SOME
frames get queued in the meantime. This results in some frames
being immediately available in the software queue for transmit
when the two existing A-MPDU frames have been completely sent,
rather than the queue remaining empty until at least one is sent.
It's not the best solution - I still think I'm scheduling receive
far more often than giving time to schedule transmit work -
but at least now I'm not starving the transmit side.
Before this, a bidirectional iperf would show receive at ~ 150mbit/sec.
but the transmit side at like 10kbit/sec. With it set to 128 it's
now 150mbit/sec receive, and ~ 10mbit receive. It's better than 10kbit/sec,
but still not as far as I'd like it to be.
Tested:
* AR9380/QCA934x (TL-WDR4300 AP), Macbook pro test STA + AR9380 test STA
I've been using STA+AP modes at home for a couple years now
and I've been finding and fixing a lot of weird corner cases.
This is the eventual patchset I've landed on.
* Don't force beacon resync in STA mode if we're using sw beacon tracking.
This stops a variety of stomping issues when the STA VAP is reconfigured;
the AP hardware beacons were being stomped on!
* Use the first AP VAP to configure beacons on, rather than the first VAP.
This prevents weird behaviour in ath_beacon_config() when the hardware
is being reconfigured and the STA VAP was the first one created.
* Ensure the beacon interval / timing programming is within the AR9300
HAL bounds by masking off any flags that may have been there before
shifting the value up to 1/8 TUs rather than the 1 TU resolution the
previous chips used.
Now I don't get weird beacon reprogramming during startup, STA state
changes and hardware recovery which showed up as HI-LARIOUS beacon
configurations and STAs that would just disconnect from the AP very
frequently.
Tested:
* AR9344/AR9380, STA and AP and STA+AP modes
I've seen this fail from time to time and just hang during reset.
Instead of it just hanging, just poke it again. I've not seen it
fail in hundreds of test resets now.
Tested:
* AR9344 AP/STA configuration
A problem was reported via email, where a large (130000+) accumulation
of NFSv4 opens on an NFSv4 mount caused significant lock contention
on the mutex used to protect the client mount's open/lock state.
Although the root cause for the accumulation of opens was not
resolved, it is obvious that the NFSv4 client is not designed to
handle 100000+ opens efficiently. When searching for an open,
usually for a match by file handle, a linear search of all opens
is done.
This patch adds a table of hash lists for the opens, hashed on
file handle. This table will be used by future commits to
search for an open based on file handle more efficiently.
MFC after: 2 weeks
In order to compare upcoming changes for their effectivness, measure
performance by counting opertions and the runtime of each operation
over the time. Accumulate all tests in a single instance, so make it
complicated over the time. If you wait long enough, you will notice
the expiry of old flows.
Reviewed by: kp (earlier version)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D30379
The previous:
if ((uoff_t)uio->uio_offset + uio->uio_resid > lim)
signal(....);
was replaced with:
if ((uoff_t)uio->uio_offset + uio->uio_resid < lim)
return;
signal(....);
Making (uoff_t)uio->uio_offset + uio->uio_resid == lim trip over the
limit, when it did not previously.
Unbreaks running 13.0 buildworld.
It was possible that termination of ktrace session occured during some
record write, in which case write occured after the close of the vnode.
Use ktr_io_params refcounting to avoid this situation, by taking the
reference on the structure instead of vnode.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D30400
Instead of trying to partially ifdef out ktrace handling, define the
missing identifier to 0. Without this fix lack of ktrace in the kernel
also means there is no SIGXFSZ signal delivery.
