This symptom is "calibrations don't ever run", which may cause some
pretty spectacularly bad behaviour in noisy environments or with longer
uptimes.
Thanks to dtrace to make it easy to check if specific non-inlined functions
are getting called by things like the ANI and calibration HAL methods.
Grr.
Tested:
* AR9380, STA mode
Use list for the cancellation points enumeration. Move notes about
functions into the list inline.
The discussion of the idiomatic use of cancellation facilities does
not belong to RETURN VALUES section, move it to NOTES.
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Note that to cancel blocked kevent(2) call, changelist must be empty,
since we cannot cancel a call which already made changes to the
process state. And in reverse, call which only makes changes to the
kqueue state, without waiting for an event, is not cancellable. This
makes a natural usage model to migrate kqueue loop to support
cancellation, where existing single kevent(2) call must be split into
two: first uncancellable update of kqueue, then cancellable wait for
events.
Note that this is ABI-incompatible change, but it is believed that
there is no cancel-safe code that relies on kevent(2) not being a
cancellation point. Option to preserve the ABI would be to keep
kevent(2) as is, but add new call with flags to specify cancellation
behaviour, which only value seems to add complications.
Suggested and reviewed by: jilles
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
rtld on x86 to be hidden. This is a micro-optimization, which allows
intrinsic references inside rtld to be handled without indirection
through PLT. The visibility of rtld symbols for other objects in the
symbol namespace is controlled by a version script.
Reviewed by: kan, jilles
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri May 31 12:17:08 2013 +0000
drm: Sort connector modes based on vrefresh
Keeping the modes sorted by vrefresh before the pixel clock makes the
mode list somehow more pleasing to the eye.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
PR: 198936
Obtained from: Linux
MFC after: 1 month
MFC with: r280183
will depend on ficl having been built, and are set via bsd.arch.inc.mk we
need to place this after ficl.
As Makefile.amd64 is now late enough we can add the i386 directory to this.
In particular, such DDB commands were added:
show vmem <addr>
show all vmem
show vmemdump <addr>
show all vmemdump
As possible usage, that allows to see KVA usage and fragmentation.
which showed up after I started changing addresses this early.
It turns out that there's some other malarky going on behind the scenes
in the HAL and merely setting the net80211/ifp mac address this early
isn't enough. If the MAC is set from kenv at attach time, the HAL
also needs to be programmed early.
Without this, the VAP wouldn't work enough for finishing association -
probe requests would be fine as they're broadcast, but association
request would fail.
Older compilers, and compatibility modes, may not support variadic macros.
I normally wouldn't go out of my way to support those old compilers but
there is a prescendent in other system headers for using the same macro
multiple times, and the solution (although non-elegant IMHO) works.
Requested by: bde
Solution by: tijl
This allows the TL-WDR3600 to use the correct MAC address for ath0, ath1
and arge0. arge1 isn't used; until I disable it entirely it'll just
show up with a randomly generated MAC.
This is used by the AR71xx platform code to choose a local MAC based on
the "board MAC address", versus whatever potentially invalid/garbage
values are stored in the Atheros calibration data.
A lot of these dinky atheros based MIPS boards don't have a nice, well,
anything consistent defining their MAC addresses for things.
The Atheros reference design boards will happily put MAC addresses
into the wifi module calibration data like they should, and individual
ethernet MAC addresses into the calibration area in flash.
That makes my life easy - "hint.arge.X.eeprommac=<addr>" reads from
that flash address to extract a MAC, and everything works fine.
However, aside from some very well behaved vendors (eg the Carambola 2
board), everyone else does something odd.
eg:
* a MAC address in the environment (eg ubiquiti routerstation/RSPRO)
that you derive arge0/arge1 MAC addresses from.
* a MAC address in flash that you derive arge0/arge1 MAC addresses from.
* The wifi devices having their own MAC addresses in calibration data,
like normal.
* The wifi devices having a fixed, default or garbage value for a MAC
address in calibration data, and it has to be derived from the
system MAC.
So to support this complete nonsense of a situation, there needs to be
a few hacks:
* The "board" MAC address needs to be derived from somewhere and squirreled
away. For now it's either redboot or a MAC address stored in calibration
flash.
* Then, a "map" set of hints to populate kenv with some MAC addresses
that are derived/local, based on the board address. Each board has
a totally different idea of what you do to derive things, so each
map entry has an "offset" (+ve or -ve) that's added to the board
MAC address.
* Then if_arge (and later, if_ath) should check kenv for said hint and
if it's found, use that rather than the EEPROM MAC address - which may
be totally garbage and not actually work right.
In order to do this, I've undone some of the custom redboot expecting
hacks in if_arge and the stuff that magically adds one to the MAC
address supplied by the board - instead, as I continue to test this
out on more hardware, I'll update the hints file with a map explaining
(a) where the board MAC should come from, and (b) what offsets to use
for each device.
The aim is to have all of the tplink, dlink and other random hardware
we run on have valid MAC addresses at boot, so (a) people don't get
random B:S:D❌x:x ethernet MACs, and (b) the wifi MAC is valid
so it works rather than trying to use an invalid address that
actually upsets systems (think: multicast bit set in BSSID.)
Tested:
* TP-Link TL_WDR3600 - subsequent commits will add the hints map
and the if_ath support.
TODO:
* Since this is -HEAD, and I'm all for debugging, there's a lot of
printf()s in here. They'll eventually go under bootverbose.
* I'd like to turn the macaddr routines into something available
to all drivers - too many places hand-roll random MAC addresses
and parser stuff. I'd rather it just be shared code.
However, that'll require more formal review.
* More boards.
The -a flag reads a file saved by -O, not -o.
The -m flag requires the -R flag. Copy that paragraph from -a.
Reviewed by: adrian
Approved by: kib (mentor)
MFC after: 1 week
Sponsored by: Dell Inc
in this area and by the Clang static analyzer.
Remove some dead assignments.
Fix a typo in a panic string.
Use umtx_pi_disown() instead of duplicate code.
Use an existing variable instead of curthread.
Approved by: kib (mentor)
MFC after: 3 days
Sponsored by: Dell Inc
common (autogenerated) versions. Removes extra vertical space,
and makes it easier to grep for usage throughout the tree.
Conditionally compile only for arm6 [1] (yes sounds odd but is right).
Submitted by: andrew [1]
Reviewed by: gnn, andrew (ian earlier version I think)
Differential Revision: https://reviews.freebsd.org/D2159
Obtained from: Cambridge/L41
Sponsored by: DARPA, AFRL
CPU, also add protection against invalid CPU's as well as
split c_flags and c_iflags so that if a user plays with the active
flag (the one expected to be played with by callers in MPSAFE) without
a lock, it won't adversely affect the callout system by causing a corrupt
list. This also means that all callers need to use the macros and *not*
play with the falgs directly (like netgraph used to).
Differential Revision: htts://reviews.freebsd.org/D1894
Reviewed by: .. timed out but looked at by jhb, imp, adrian hselasky
tested by hiren and netflix.
Sponsored by: Netflix Inc.
originated from the return to usermode. #ss must be handled same as
#np.
Reported by: Andrew Lutomirski through secteam
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Without this the autotuning fails for small amounts of RAM (32mb),
which all the AR91xx shipping products seemed to have.
Thanks to gjb for reminding me to re-test this stuff.
Tested:
* AR91xx, TP-Link TL-WR1043nd v1
duplicated code in the two classes, and also allows devices in FDT-based
systems to declare simplebus as their parent and still work correctly
when the FDT data describes the device at the root of the tree rather
than as a child of a simplebus (which is common for interrupt, clock,
and power controllers).
Differential Revision: https://reviews.freebsd.org/D1990
Submitted by: Michal Meloun
