relying on what the register defaults are.
This forces the blink mode to be proportional to the TX and RX frames
which match the RX filter.
This (along with a few tweaks to if_ath_led.c to configure the correct
GPIO pins) allows my DWA-552 AR5416 NIC to blink the LEDs in a useful
fashion, however those LEDs are marked "Link" and "Act(ivity)", which
don't really map well to the "power" / "network" LED interface which
the MAC provides. Some further tinkering is needed to see what other
useful operating modes are possible.
kernel builds. All the instances of this warning in our tree are
completely harmless, and many people seem to like adding extra
parentheses to make precedence clearer.
MFC after: 1 week
builds. All the instances of this warning in our tree are completely
harmless. (Most of the empty bodies look to be used simply as reminder
for the developer to add something later.)
While here, assign to CWARNEXTRA with ?=, so it can be overridden
easily, if needed.
MFC after: 1 week
to always evaluate to 0 if we are using a compiler that doesn't implement them.
This lets us use the macros easily in standard headers (e.g. stdatomic.h, which
should be the subject of my next commit).
Approved by: dim (mentor)
sysclock_getsnapshot() function allows the caller to obtain a snapshot of all
the system clock and timecounter state required to create time stamps at a later
point. The sysclock_snap2bintime() function converts a previously obtained
snapshot into a bintime time stamp according to the specified flags e.g. which
system clock, uptime vs absolute time, etc.
These KPIs enable useful functionality, including direct comparison of the
feedback and feed-forward system clocks and generation of multiple time stamps
with different formats from a single timecounter read.
Committed on behalf of Julien Ridoux and Darryl Veitch from the University of
Melbourne, Australia, as part of the FreeBSD Foundation funded "Feed-Forward
Clock Synchronization Algorithms" project.
For more information, see http://www.synclab.org/radclock/
In collaboration with: Julien Ridoux (jridoux at unimelb edu au)
these to trigger a NOTE_ATTRIB EVFILT_VNODE kevent when the extended
attributes of a vnode are changed.
Note that OS X already implements this behavior.
Reviewed by: rwatson
MFC after: 2 weeks
As soon as not all devices support READ CAPACITY(16), automatically fall
back to READ CAPACITY(10) if CAM_REQ_INVALID or SSD_KEY_ILLEGAL_REQUEST
status returned.
It also provides first bits of information about Logical Block Provisioning
(aka UNMAP/TRIM) support by the device.
CWARNEXTRA variable, which gets included into the initial CWARNFLAGS
setting. This makes it easier to override CWARNFLAGS with completely
custom settings (including enabling any disabled warnings).
Reminded by: arundel
MFC after: 1 week
MS_SYNC flag. The system must guarantee that all writes are finished
before syscalls returned. Schedule the writes in async mode, which is
much faster and allows the clustering to occur. Wait for writes using
VOP_FSYNC(), since we are syncing the whole file mapping.
Potentially, the restriction to only apply the optimization can be
relaxed by not requiring that the mapping cover whole file, as it is
done by other OSes.
Reported and tested by: az
Reviewed by: alc
MFC after: 2 weeks
state from correctly updating things.
The reference driver directly enables/disables the LED state as required,
rather than nailing it up like it currently is. That'll have to come
later by adding some further HAL methods.
Obtained from: Atheros
* Bring the AR5416 GPIO mux mask code in line with the code from the
HAL.
* Add HAL_DEBUG_GPIO debugging statements, to track what's going on.
* Add Kiwi GPIO specific changes for reading values back.
Obtained from: Atheros
* As a preparation for AR9287 GPIO support, add in the AR9287 GPIO mask.
* Fix the association mask values; these are post-shift values but were
being shifted in twice. This resulted in some garbage being written
in the wrong place and the link LED (at least on my d-link AR5416
NIC) giving totally incorrect blink patterns.
Some users were reporting concurrent resets _were_ occuring - ie,
either two ath_reset()s ran at the same time (likely one on each CPU)
or ath_reset() versus ath_chan_change().
Instead, this now tries to grab the serialisation semaphore and will
pause() for a while if it fails. It will always eventually succeed though
and will log an error if it hits the recursion situation.
All of this stuff needs to die a horrible death at some point and be
replaced with a properly serialising method of programming this stuff
(eg using the net80211 taskqueue for all of this stuff.) The trouble
is figuring out how to handle the concurrent ioctl() based things without
introducing more LORs (which is another reason why I haven't just wrapped
all of this stuff in large, long-lived locks, a-la what Linux can get
away with.)
MFC after: Absolutely, positively never.
This doesn't fix compilation w/out AH_SUPPORT_AR5416 as all of the software
aggregation support in if_ath_tx.c and 11n code in if_ath_tx_ht.c touches
the 11n specific fields. I'll work on that later.
going on with the occasional garbage rs_antenna field reported by AR9285
users.
I've discovered that the 11n NICs only fill out the entire RX status
descriptor on the final descriptor in an aggregate. Some of the fields
(notably RSSI) are complete nonsense for A-MPDU subframes. This may
be another example of this.
The driver doesn't currently toss out statistics for non-final aggregate
frames. It's likely that this should be done.
If any users hit this particular debugging message they should report it
immediately to freebsd-wireless@freebsd.org - please ensure you have
ATH_DEBUG enabled so it prints out the full receive descriptor.
PR: kern/163312
jhb@ spotted that nfscl_getstateid() might modify credentials when
called from nfsrpc_read() for the case where p != NULL, whereas
nfsrpc_read() only did a crdup() to get new credentials for p == NULL.
This bug was introduced by r195510, since pre-r195510 nfscl_getstateid()
only modified credentials for the p == NULL case. This patch modifies
nfsrpc_read()/nfsrpc_write() so that they do crdup() for the p != NULL case.
It is conceivable that this bug caused the crash reported by glebius@, but
that will not be determined for some time, since the crash occurred after
about 1month of operation.
Tested by: glebius
Reviewed by: jhb
MFC after: 2 weeks
might be useful in some cases, but which are not severe enough to error
out the whole kernel build. Display them anyway, so there is at least
some incentive to fix them eventually.
Start with -Wtautological-compare warnings. These usually occur when
people check if unsigned quantities are negative, or similar cases. To
clean these up would be painful, and might give problems if the base
type which is compared against changes to signed later on.
MFC after: 1 week
connected via SAS or USB. Unluckily I've found that SAS (mps) and USB-SATA
I have translate models in different ways, requiring twice more quirks.
Unluckily for Hitachi, their model names are trimmed on SAS, making
impossible to identify 4K sector drives that way.
There's currently no public code which uses this feature and the
current reference driver doesn't enable this feature at all.
It's possible it was used by a previous version of the driver and
that indeed it should return HAL_STATUS; but at this point I'm
happy to require that they complain and submit a patch.
This was found by LLVM compile-time type checking.
Submitted by: dim
revision 1.122
date: 2009/05/13 01:01:34; author: dlg; state: Exp; lines: +6 -4
only keep track of the number of updates on tcp connections. state sync on
all the other protocols is simply pushing the timeouts along which has a
resolution of 1 second, so it isnt going to be hurt by pfsync taking up
to a second to send it over.
keep track of updates on tcp still though, their windows need constant
attention.
revision 1.120
date: 2009/04/04 13:09:29; author: dlg; state: Exp; lines: +5 -5
use time_uptime instead of time_second internally. time_uptime isnt
affected by adjusting the clock.
revision 1.175
date: 2011/11/25 12:52:10; author: dlg; state: Exp; lines: +3 -3
use time_uptime to set state creation values as time_second can be
skewed at runtime by things like date(1) and ntpd. time_uptime is
monotonic and therefore more useful to compare against.
revision 1.118
date: 2009/03/23 06:19:59; author: dlg; state: Exp; lines: +8 -6
wait an appropriate amount of time before giving up on a bulk update,
rather than giving up after a hardcoded 5 seconds (which is generally much
too short an interval for a bulk update).
pointed out by david@, eyeballed by mcbride@
revision 1.171
date: 2011/10/31 22:02:52; author: mikeb; state: Exp; lines: +2 -1
Don't forget to cancel bulk update failure timeout when destroying an
interface. Problem report and fix from Erik Lax, thanks!
Start a brief note of revisions merged from OpenBSD.
GEOM and using READ CD command for reading data, same as acd driver does.
Audio CDs identified by checking respective bit of the control field of
the first track in TOC.
This fixes bunch of error messages during boot (GEOM taste) with Audio CD
inserted and allows to grab Audio CD image using just dd.
MFC after: 1 month
