the queue is not 'lpc stop'-ed. In that situation `lpq' will
not display the status message to the user, and the operator
may think the queue is already stopped when it is not.
MFC after: 3 weeks
conversions. Both the specification and the documentation say the
width is interpreted as the max number of wide characters to read, but
the implementation was interpreting it as the number of bytes to convert.
(See also r105317.)
This change has security implications for any applications that depend
on the buggy behavior, but the impact in practice is probably nil.
Any such application would already be buggy on other platforms that
get the semantics right. Also, these conversions are rarely used;
%ls, %lc, and %l[ are more appropriate.
Olympus FE-210 camera
LG UP3S MP3 player
Laser MP3-2GA13 MP3
PR: usb/119201
Submitted by: Peter Jeremy <peterjeremy@optushome.com.au>
Approved by: cperciva
MFC after: 1 week
This will give you more bandwidth for isochronous
FULL speed applications connected through a
High Speed HUB.
This patch has been tested with XHCI and EHCI.
MFC after: 1 week
reading wide characters manually. With this change, they now use
fgetwc(). To make this work, we use an internal version of fgetwc()
with a few extensions: it takes an mbstate * because non-wide streams
don't have a built-in mbstate, and it indicates the number of bytes
read.
vfscanf() now resembles vfwscanf() more closely. Minor functional
improvements include working xlocale support in vfscanf(), setting the
stream error indicator on encoding errors, and proper handling of
shift-based encodings. (Actually, making shift-based encodings work
with non-wide streams is hopeless, but the implementation now matches
the broken specification.)
While removing unnecessary entries from .PATH.c I missed that for the
examples WPA_SUPPLICANT_DISTDIR/HOSTAPD_DISTDIR is explicitly added to
.PATH.
Tested by: lev
MFC after: 2 weeks
is considered "busy but not doing any active TX or frame RX."
Just keep in mind that "frame RX" is "decoding what looks like a wifi
signal", not necessarily "frame successfully decoded for this particular
device."
DST should not need to worry about scheduling jobs when the DST time
changes.
Rather than removing the BUGS section in crontab(5) regarding this,
note that disabling '-s' may still cause jobs to be executed twice or
not at all.
PR: 166318
Submitted by: Florian k Unglaub (f.unglaub%googlemail!com)
MFC After: 1 week
in the HAL. That's very memory hungry (32k just for channel statistics)
which would be better served by keeping a summary in the ANI state.
Or, later, keep a survey history in net80211.
So:
* Migrate the ah_chansurvey array to be a single entry, for the current
channel.
* Change the ioctl interface and ANI code to just reference that.
* Clear the ah_chansurvey array during channel reset, both in the AR5212
and AR5416 reset path.
This tool changes the default buffering behaviour of standard
stdio streams.
It only works on dynamic binaries. To make it work for static
ones it would require cluttering stdio because there no single
entry point.
PR: 166660
Reviewed by: current@, jhb
Approved by: kib (mentor)
MFC after: 1 week
WITHOUT_OPENSSL build by using the wpa's internal crypto support if
openssl is not available, this allows us to unconditionally enable
EAP support.
MFC after: 2 weeks
* Always call ar5416GetListenTime()
* Modify ar5416GetListenTime() to:
+ don't update the ANI state if there isn't any ANI state;
+ don't update the channel survey state if there's no active
channel - just to be paranoid
+ copy the channel survey results into the current sample slot
based on the current channel; then increment the sample counter
and sample history counter.
* Modify ar5416GetMIBCyclesPct() to simply return a HAL_SURVEY_SAMPLE,
rather than a set of percentages. The ANI code wasn't using the
percentages anyway.
TODO:
* Create a new function which fetches the survey results periodically
* .. then modify the ANI code to use the pre-fetched values rather than
fetching them again
* Roll the 11n ext busy function from ar5416_misc.c to update all the
counters, then do the result calculation
* .. then, modify the MIB counter routine to correctly fetch a snapshot -
freeze the counters, fetch the values, then reset the counters.
from the current channel.
There seem to be some occasional issues with the extension channel
counters reporting more than 100% of use. I'll investigate that
soon.
The reference driver has a 3ms delay for the AR9130 but I'm not as yet
sure why. From what I can gather, it's likely waiting for some FIFO
flush to occur.
At some point in the future it may be worthwhile adding a WMAC
FIFO flush here, but that'd require some side-call through to the SoC
DDR flush routines.
Obtained from: Atheros
1. The licensing terms for the MD2 routines from RFC is not under a BSD-like
license. Instead it is only granted for non-commercial Internet
Privacy-Enhanced Mail.
2. MD2 is quite deprecated as it is no longer considered a cryptographically
strong algorithm.
Discussed with: so (cperciva), core
guarantees on acquire for the tlbie mutex. Conversely, the TLB invalidation
sequence provides guarantees that do not need to be redundantly applied on
release. Roll a small custom lock that is just right. Simultaneously,
convert the SLB tree changes back to lwsync, as changing them to sync
was a misdiagnosis of the tlbie barrier problem this commit actually fixes.
do not include file attributes in the reply to an NFS create RPC
under certain circumstances.
This resulted in a vnode of type VNON that was not usable.
This patch adds an NFS getattr RPC to nfs_create() for this case,
to fix the problem. It was tested by the person that reported
the problem and confirmed to fix this case for their server.
Tested by: Steven Haber (steven.haber at isilon.com)
MFC after: 2 weeks
ZFS volume is exported via the new NFS server. The leak occurred
because the new NFS server code didn't handle the case where
a file system sets the SAVENAME flag in its VOP_LOOKUP() and
ZFS does this for the DELETE case.
Tested by: Oliver Brandmueller (ob at gruft.de), hrs
PR: kern/167266
MFC after: 1 month
