| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(or direct dispatch) behind the TXQ lock (which, remember, is doubling
as the TID lock too for now.)
This ensures that:
(a) the sequence number and the CCMP PN allocation is done together;
(b) overlapping transmit paths don't interleave frames, so we don't
end up with the original issue that triggered kern/166190.
Ie, that we don't end up with seqno A, B in thread 1, C, D in
thread 2, and they being queued to the software queue as "A C D B"
or similar, leading to the BAW stalls.
This has been tested:
* both STA and AP modes with INVARIANTS and WITNESS;
* TCP and UDP TX;
* both STA->AP and AP->STA.
STA is a Routerstation Pro (single CPU MIPS) and the AP is a dual-core
Centrino.
PR: kern/166190
|
| |
|
|
|
|
|
|
| |
See previous commit.
PR: kern/166190
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
scheduled from the head of the software queue rather than trying to
queue the newly given frame.
This leads to some rather unfortunate out of order (but still valid
as it's inside the BAW) frame TX.
This now:
* Always queues the frame at the end of the software queue;
* Tries to direct dispatch the frame at the head of the software queue,
to try and fill up the hardware queue.
TODO:
* I should likely try to queue as many frames to the hardware as I can
at this point, rather than doing one at a time;
* ath_tx_xmit_aggr() may fail and this code assumes that it'll schedule
the TID. Otherwise TX may stall.
PR: kern/166190
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an unfortunate byproduct of how the routine is used - it's called
with the head frame on the queue, but if the frame is failed, it's inserted
into the tail of the queue.
Because of this, the sequence numbers would get all shuffled around and
the BAW would be bumped past this sequence number, that's now at the
end of the software queue. Then, whenever it's time for that frame
to be transmitted, it'll be immediately outside of the BAW and TX will
stall until the BAW catches up.
It can also result in all kinds of weird duplicate BAW frames, leading
to hilarious panics.
PR: kern/166190
|
|
|
|
|
|
| |
required.
PR: kern/166190
|
|
|
|
|
|
|
| |
_TID_ lock is held.
For now the TID lock is also the TXQ lock. This is just to make sure
that the right TXQ lock is held for the given TID.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This showed up when doing heavy UDP throughput on SMP machines.
The problem with this is because the 802.11 sequence number is being
allocated separately to the CCMP PN replay number (which is assigned
during ieee80211_crypto_encap()).
Under significant throughput (200+ MBps) the TX path would be stressed
enough that frame TX/retry would force sequence number and PN allocation
to be out of order. So once the frames were reordered via 802.11 seqnos,
the CCMP PN would be far out of order, causing most frames to be discarded
by the receiver.
I've fixed this in some local work by being forced to:
(a) deal with the issues that lead to the parallel TX causing out of
order sequence numbers in the first place;
(b) fix all the packet queuing issues which lead to strange (but mostly
valid) TX.
I'll begin fixing these in a subsequent commit or five.
PR: kern/166190
|
| |
|
|
|
|
|
|
| |
- Add -b to short error messages
Obtained from: NetBSD
|
|
|
|
|
|
|
|
|
|
| |
both places where they are mentioned in find(1).
Discussed with: dougb
PR: docs/168885
Reported by: Ronald F. Guilmette (rfg at tristatelogic dot com)
Approved by: gabor (mentor)
MFC after: 3 days
|
|
|
|
| |
MFC after: 1 month
|
|
|
|
| |
MFC after: 1 month
|
| |
|
|
|
|
|
|
|
|
| |
on the underlying object and not on the capability itself.
Discussed with: rwatson
Sponsored by: FreeBSD Foundation
MFC after: 1 month
|
|
|
|
|
|
|
|
|
|
| |
This is much like -t but with a different format which is ISO8601-like and
allows fractions of a second.
The precision is limited to microseconds because of utimes() and friends,
even though stat() returns nanoseconds.
MFC after: 10 days
|
|
|
|
| |
MFC after: 1 month
|
|
|
|
|
|
|
|
|
|
|
|
| |
propagate the stack execution permissions when stack is grown down.
First, curproc->p_sysent->sv_stackprot specifies maximum allowed stack
protection for current ABI, so the new stack entry was typically marked
executable always. Second, for non-main stack MAP_STACK mapping,
the PROT_ flags should be used which were specified at the mmap(2) call
time, and not sv_stackprot.
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
| |
Return PROTO_ATA protocol in response to XPT_PATH_INQ.
smartmontools uses it to identify ATA devices and I don't know any other
place now where it is important. It could probably use XPT_GDEV_TYPE
instead for more accurate protocol information, but let it live for now.
Reported by: matthew
MFC after: 3 days
|
|
|
|
|
| |
is not used in this part of the function and correctly initialised later
when it is used.
|
|
|
|
| |
include the latter file from the former rather than duplicating it.
|
| |
|
|
|
|
| |
specific statistics for ath(4).
|
| |
|
|
|
|
| |
MFC after: 1 month
|
|
|
|
|
|
|
|
| |
- Remove cpuset stopped_cpus which is no longer used.
- Add a short comment for cpuset suspended_cpus clearing.
- Fix the un-ordered x86/acpica/acpi_wakeup.c in conf/files.amd64 and i386.
Pointed-out by: attilio@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modified Fri Jul 10 07:44:34 2009 CDT by rafael
backport part of
http://gcc.gnu.org/ml/gcc-cvs/2007-10/msg00118.html
The patch is for libstdc++ and it was GPL2 at the time.
Modified Tue Apr 29 01:20:19 2008 CDT by asl
Backport from mainline (pre-GPLv3).
Fix for sizeof(const void*) > sizeof(unsigned long).
Approved by: jhb (mentor)
MFC after: 2 weeks
|
|
|
|
|
|
| |
common function.
Reviewed by: imp
|
|
|
|
|
|
|
|
|
| |
to become available. Otherwise we may excessively spin and fail
with ``fsync: giving up on dirty''.
Reviewed by: kib
Tested by: Peter Holm
MFC after: 1 week
|
|
|
|
|
|
|
| |
changes done in r233478.
Approved by: kib(mentor)
MFC after: 3 days
|
|
|
|
|
|
|
|
| |
differentiate between an incremental and full stream.
Be sure not to generate guid equal to 0.
Reported by: someone who saw 0 being generated as 64bit random guid
MFC after: 3 days
|
|
|
|
|
|
|
| |
we now use sx lock for filedesc structure protection.
Reviewed by: kib
MFC after: 1 month
|
|
|
|
|
| |
MFC after: 1 month
MFC with: r236820
|
|
|
|
|
| |
Reviewed by: tegge
MFC after: 1 month
|
|
|
|
|
|
|
| |
Incorrect mask can possibly be one of the reasons for kern/127209 existance.
Approved by: kib(mentor)
MFC after: 3 days
|
|
|
|
|
|
| |
Submitted by: Jan Sieka
Reviewed by: arm@
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reporting. It includes:
- removing of error messages controlled by bootverbose, replacing them
with more universal and informative debugging on CAM_DEBUG_INFO level,
that is now built into the kernel by default;
- more close following to the arguments submitted by caller, such as
SF_PRINT_ALWAYS, SF_QUIET_IR and SF_NO_PRINT; consumer knows better which
errors are usual/expected at this point and which are really informative;
- adding two new flags SF_NO_RECOVERY and SF_NO_RETRY to allow caller
specify how much assistance it needs at this point; previously consumers
controlled that by not calling cam_periph_error() at all, but that made
behavior inconsistent and debugging complicated;
- tuning debug messages and taken actions order to make debugging output
more readable and cause-effect relationships visible;
- making camperiphdone() (common device recovery completion handler) to
also use cam_periph_error() in most cases, instead of own dumb code;
- removing manual sense fetching code from cam_periph_error(); I was told
by number of people that it is SIM obligation to fetch sense data, so this
code is useless and only significantly complicates recovery logic;
- making ada, da and pass driver to use cam_periph_error() with new limited
recovery options to handle error recovery and debugging in common way;
as one of results, CAM_REQUEUE_REQ and other retrying statuses are now
working fine with pass driver, that caused many problems before.
- reverting r186891 by raj@ to avoid burning few seconds in tight DELAY()
loops on device probe, while device simply loads media; I think that problem
may already be fixed in other way, and even if it is not, solution must be
different.
Sponsored by: iXsystems, Inc.
MFC after: 2 weeks
|
|
|
|
|
| |
MFC after: 1 month
MFC with: r236731
|
|
|
|
|
|
| |
C++ file extensions.
MFC after: 3 days
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Show IPv4/IPv6 header IFF there are some flows following.
Wrap some long lines.
Sponsored by Yandex LLC
Reviewed by: glebius (previous version)
Approved by: ae(mentor)
MFC after: 1 week
|
|
|
|
|
| |
Pointed by: bcr
Approved by: kib(mentor)
|
| |
|
| |
|
|
|
|
|
| |
MFC after: 3 days
X-MFC-With: r236776
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
suspend/resume procedures are minimized among them.
common:
- Add global cpuset suspended_cpus to indicate APs are suspended/resumed.
- Remove acpi_waketag and acpi_wakemap from acpivar.h (no longer used).
- Add some variables in acpi_wakecode.S in order to minimize the difference
among amd64 and i386.
- Disable load_cr3() because now CR3 is restored in resumectx().
amd64:
- Add suspend/resume related members (such as MSR) in PCB.
- Modify savectx() for above new PCB members.
- Merge acpi_switch.S into cpu_switch.S as resumectx().
i386:
- Merge(and remove) suspendctx() into savectx() in order to match with
amd64 code.
Reviewed by: attilio@, acpi@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
test.
POSIX says that SIGPIPE affects a process and therefore a SIGPIPE caused and
received by a subshell environment may or may not affect the parent shell
environment.
The change assumes that ${SH} is executed in a new process. This must be the
case if it contains a slash and everyone appears to do so anyway even though
POSIX might permit otherwise.
This change makes builtins/wait3.0 work in ksh93.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Consistently refer to rmlocks as "read-mostly locks".
- Relate rmlocks to rwlocks rather than sx locks since they are closer to
rwlocks.
- Add a separate paragraph on sleepable read-mostly locks contrasting them
with "normal" read-mostly locks.
- The flag passed to rm_init_flags() to enable recursion for readers is
RM_RECURSE, not LO_RECURSABLE.
- Fix the description for RM_RECURSE (it allows readers to recurse, not
writers).
- Explicitly note that rm_try_rlock() honors RM_RECURSE.
- Fix some minor grammar nits.
|
|
|
|
|
| |
Reviewed by: dim
MFC after: 3 days
|