on Intel processors. Clear spurious dependency by explicitely xoring
the destination register of popcnt.
Use bitcount64() instead of re-implementing SWAR locally, for
processors without popcnt instruction.
Reviewed by: jhb
Discussed with: jilles (previous version)
Sponsored by: The FreeBSD Foundation
rather than 20. The MP 1.4 specification states in Appendix B.2:
"A period of 20 microseconds should be sufficient for IPI dispatch to
complete under normal operating conditions".
(Note that this appears to be separate from the 10 millisecond (INIT) and
200 microsecond (STARTUP) waits after the IPIs are dispatched.) The
Intel SDM is silent on this issue as far as I can tell.
At least some hardware requires 60 microseconds as noted in the PR, so
bump this to 100 to be on the safe side.
PR: 197756
Reported by: zaphod@berentweb.com
MFC after: 1 week
ask for resource reclamation again.
This is kind of dirty hack, but as last resort this is better then stuck
indefinitely because of KVA fragmentation, waiting until some random event
free something sufficient. OpenSolaris also has this hack in its vmem(9).
MFC after: 2 weeks
uintptr_t may be 64-bit on some platforms, therefore when
finding xrefinfo by pointer to device the high word is being
cut off due to cast to phandle_t which is 32-bit long by definition.
Due to that we loose the high word of the address to compare with
xi->dev's address.
To fix that, first argument of xrefinfo_find() is extended to
uintptr_t and is being cast to appropriate type (phandle_t)
when compared.
Submitted by: Zbigniew Bodek <zbb@semihalf.com>
Reviewed by: nwhitehorn
Obtained from: Semihalf
Handle the VIRQ_DEBUG signal and print a stack trace of each vCPU on the Xen
console. This is only used for debug purposes and is triggered by the
administrator of the Xen host.
Sponsored by: Citrix Systems R&D
MFC after: 1 week
This adds an upper bound, dtrace_ustackdepth_max, to the number of frames
traversed when computing the userland stack depth. Some programs - notably
firefox - are otherwise able to trigger an infinite loop in
dtrace_getustack_common(), causing a panic.
MFC after: 1 week
This is used by the 'athsurvey' command to print out channel survey
statistics - % busy times transmit, receive and airtime.
It's as buggy and incomplete as the rest of the HAL survey support -
notably, tying into the ANI code to read channel stats and occasionally
getting garbage counters isn't very nice. It also doesn't (yet!) get
channel survey information during a scan. But it's good enough for
basic air-time debugging, which is why I'm committing it in this state.
Tested:
* AR9380, STA mode
rathe than private in each HAL module.
Whilst here, modify ath_hal_private to always have the per-channel
noisefloor stats, rather than conditionally. This just makes
life easier in general (no strange ABI differences between different
HAL compile options.)
Add a couple of methods (clear/reset, add) rather than using
hand-rolled versions of things.
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
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.
