These are similar to the mips24k performance counters - some are
available on perfcnt0/3, some are available on perfcnt1/4.
However, the events aren't all the same.
* Add the events, named the same as from Linux oprofile.
* Verify they're the same as "MIPS32(R) 74KTM Processor Core Family
Software User's Manual"; Document Number: MD00519; Revision 01.05.
* Rename INSTRUCTIONS to something else, so it doesn't clash with
the alias INSTRUCTIONS. I'll try to tidy this up later; there
are a few other aliases to add and shuffle around.
Tested:
* QCA9558 SoC (AP135 board) - MIPS74Kc core (no FPU.)
* make universe; where it didn't fail for other reasons.
TODO:
* It'd be nice to support the four performance counters
in at least this hardware, rather than just two.
Reviewed by: bsdimp ("looks good; don't break world".)
Summary:
Book-E and AIM trap.c are almost identical, except for a few bits. This is step
1 in unifying them.
This also renumbers EXC_DEBUG, to not conflict with AIM vector numbers. Since
this is the only one thus far that is used in the switch statement in trap(),
it's the only one renumbered. If others get added to the switch, which conflict
with AIM numbers, they should also be renumbered.
Reviewers: #powerpc, marcel, nwhitehorn
Reviewed By: marcel
Subscribers: imp
Differential Revision: https://reviews.freebsd.org/D2215
that performs the equivalent of an automatic madvise(..., MADV_DONTNEED).
The current heuristic, even with the improvements that I made a few years
ago, is a good example of making the wrong trade-off, or optimizing for
the infrequent case. The infrequent case being reading a single file that
is much larger than memory using mmap(2). And, in this case, the page
daemon isn't the bottleneck; it's the I/O.
In all other cases, the current heuristic has too many false positives,
i.e., it caches too many pages that are later reused. To give one
example, thousands of pages are cached by the current heuristic during a
buildworld and all of them are reactivated before the buildworld
completes. In particular, clang reads source files using mmap(2) and
there are some relatively large source files in our source tree, e.g.,
sqlite, that are read multiple times. With the new heuristic, I see fewer
false positives and they have a much lower cost.
I actually tried something like this more than two years ago and it
didn't perform as well as the cache behind heuristic. However, that was
before the changes to the page daemon in late summer of 2013 and the
existence of pmap_advise(). In particular, with the page daemon doing
its work more frequently and in smaller batches, it now completes its
work while the application accessing the file is blocked on I/O.
Whereas previously, the page daemon appeared to hog the CPU for so long
that it caused "hiccups" in the application's execution.
Finally, I'll add that the elimination of cache pages is a prerequisite
for NUMA support.
Reviewed by: jeff, kib
Sponsored by: EMC / Isilon Storage Division
- Add macros to handle the differences in accessing these registers on arm
and arm64.
- Use the fdt data to detect if we are on an ARMv7 or ARMv8.
- Use the virtual timer by default on arm64, we may not have access to
the physical timer.
Differential Revision: https://reviews.freebsd.org/D2208
Reviewed by: emaste
Sponsored by: The FreeBSD Foundation
Previously, the driver was trying to blink the LED in the newstate
function, but that only gets called once (unlike OpenBSD's net80211
stack). Move the LED blinking to set_channel().
While there, don't try to set the channel when we switch to the SCAN
state. This is already accomplished by the set_channel() function.
MFC after: 1 week
It's necessary to reset the screen to make sure any vendor pixels are
gone when we start boot1. In the Lenovo X1 (3rd gen), this is the
only way to clear the screen. Previously, the Lenovo logo would only
disappear after the kernel started scrolling the display.
After resetting the screen, EFI could put us in the worst LCD mode
(oversized characters), so we now find the largest mode we can use and
hope it's the most appropriate one (it's not trivial to tell what's
the correct LCD resolution at this point). It's worth noting that the
final stage loader has a 'mode' command that can be used to switch
text modes.
While there, enable the software cursor, just like in the legacy boot
mode.
MFC after: 1 week
Even on Illumos, with its much larger KVA, ZFS ARC steps back if KVA usage
reaches certain threshold (3/4 on i386 or 16/17 otherwise). FreeBSD has
even less KVA, but had no such limit on archs with direct map as amd64.
As result, on machines with a lot of RAM, during load with very small user-
space memory pressure, such as `zfs send`, it was possible to reach state,
when there is enough both physical RAM and KVA (I've seen up to 25-30%),
but no continuous KVA range to allocate even single 128KB I/O request.
Address this situation from two sides:
- restore KVA usage limitations in a way the most close to Illumos;
- introduce new requirement for KVA fragmentation, specifying that we
should have at least one sequential KVA range of zfs_max_recordsize bytes.
Experiments show that first limitation done alone is not sufficient. On
machine with 64GB of RAM it is sometimes needed to drop up to half of ARC
size to get at leats one 1MB KVA chunk. Statically limiting ARC to half
of KVA/RAM is too strict, so second limitation makes it to work in cycles:
accumulate trash up to certain critical mass, do massive spring-cleaning,
and then start littering again. :)
MFC after: 1 month
work stack and is reused again on the receive ring. Remaining received packets in the ring are not processed in that
invocation of bxe_rxeof() and defered to the task thread.
MFC after: 5 days
Amd64 uses relocatable object files as the modules format. It is good
WRT not having unneeded overhead for PIC code, in particular, due to
absence of useless GOT and PLT. But the cost is that the module
linking process cannot use hash to speed up the symbol lookup, and
that each reference to the symbol requiring a relocation, instead of
single-place relocation in GOT.
Cache the successfull symbol lookup results in the module symbol
table, using the newly allocated SHN_FBSD_CACHED value from
SHN_LOOS-HIOS range as an indicator. The SHN_FBSD_CACHED together
with the non-existent definition of the found symbol are reverted
after successfull relocations, which is done under kld_sx lock, so it
should not be visible to other consumers of the symbol table.
Submitted by: Conrad Meyer
Differential Revision: https://reviews.freebsd.org/D1718
MFC after: 3 weeks
This was not (and still is not) connected to the build, but the EFI
loader is in the process of being built for other than amd64 so these
files ought to live in their eventual MD location.
header and not only partial flags and fields. Firewalls can attach
classification tags to the outgoing mbufs which should be copied to
all the new fragments. Else only the first fragment will be let
through by the firewall. This can easily be tested by sending a large
ping packet through a firewall. It was also discovered that VLAN
related flags and fields should be copied for packets traversing
through VLANs. This is all handled by "m_dup_pkthdr()".
Regarding the MAC policy check in ip_fragment(), the tag provided by
the originating mbuf is copied instead of using the default one
provided by m_gethdr().
Tested by: Karim Fodil-Lemelin <fodillemlinkarim at gmail.com>
MFC after: 2 weeks
Sponsored by: Mellanox Technologies
PR: 7802
stage, just like for the regular world stage.
Reviewed by: rodrigc, imp, bapt, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D2187
not have interupt property in pl310 node. Interrupt is used only to
detect cache activity when L2 cache is disabled, it's not vital for
normal operations.
- Fix intrhook allocation/initialization
There are cases when gpioled nodes in DTS come from different sources
(e.g. standard Beaglebone Black LEDs in main DTS + shield LEDs in
overlay DTS) so instead of handling only first compatible node go
through all child nodes
where we want to create a new IP datagram.
o Add support for RFC6864, which allows to set IP ID for atomic IP
datagrams to any value, to improve performance. The behaviour is
controlled by net.inet.ip.rfc6864 sysctl knob, which is enabled by
default.
o In case if we generate IP ID, use counter(9) to improve performance.
o Gather all code related to IP ID into ip_id.c.
Differential Revision: https://reviews.freebsd.org/D2177
Reviewed by: adrian, cy, rpaulo
Tested by: Emeric POUPON <emeric.poupon stormshield.eu>
Sponsored by: Netflix
Sponsored by: Nginx, Inc.
Relnotes: yes
- bus_dmamap_create() does not take the BUS_DMA_NOWAIT flag
- properly unload maps
- do not assign NULL to dma map pointers
Submitted by: Konstantin Belousov <kostikbel@gmail.com>
Approved by: jfv (mentor)
MFC after: 1 week
A couple of internal functions used by malloc(9) and uma truncated
a size_t down to an int. This could cause any number of issues
(e.g. indefinite sleeps, memory corruption) if any kernel
subsystem tried to allocate 2GB or more through malloc. zfs would
attempt such an allocation when run on a system with 2TB or more
of RAM.
Note to self: When this is MFCed, sparc64 needs the same fix.
Differential revision: https://reviews.freebsd.org/D2106
Reviewed by: kib
Reported by: Michael Fuckner <michael@fuckner.net>
Tested by: Michael Fuckner <michael@fuckner.net>
MFC after: 2 weeks
On Ethernet packets have a minimal length, so very short packets get padding
appended to them. This padding is not stripped off in ip6_input() (due to
support for IPv6 Jumbograms, RFC2675).
That means PF needs to be careful when reassembling fragmented packets to not
include the padding in the reassembled packet.
While here also remove the 'Magic from ip_input.' bits. Splitting up and
re-joining an mbuf chain here doesn't make any sense.
Differential Revision: https://reviews.freebsd.org/D2189
Approved by: gnn (mentor)
When forwarding fragmented IPv6 packets and filtering with PF we
reassemble and refragment. That means we generate new fragment headers
and a new fragment ID.
We already save the fragment IDs so we can do the reassembly so it's
straightforward to apply the incoming fragment ID on the refragmented
packets.
Differential Revision: https://reviews.freebsd.org/D2188
Approved by: gnn (mentor)
Return EINVAL instead of EFTYPE if we have a multiboot kernel loaded but
failed to load the modules. This makes it clear that the kernel/module
should be handled by the multiboot handler but something went wrong.
Sponsored by: Citrix Systems R&D
Zero the list of modules array before using it, or else we might pass
uninitialized data in unused fields of the struct that will make Xen choke.
Also add a check to make sure malloc succeeds.
Sponsored by: Citrix Systems R&D
support for booting arm and arm64 from UEFI.
Differential Revision: https://reviews.freebsd.org/D2164
Reviewed by: emaste, imp (previous version)
Sponsored by: The FreeBSD Foundation
on reads or writes, the time marks are used to display idle time by
w(1) [1]. Instead, use vfs.devfs.dotimes as the selector of default
precision vs. using time_second. The later gives seconds precision,
which is good enough for the purpose.
Note that timestamp updates are unlocked and the updates itself, as
well as the check in devfs_timestamp, are non-atomic.
Noted by: truckman [1]
Reviewed by: bde
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
the top-level HAL.
The athstats program is blindly using a copy of the ar5212 ANI stats structure
to pull out ANI statistics/state and this is problematic for the AR9300
HAL.
So:
* Define HAL_ANI_STATS and HAL_ANI_STATE
* Use HAL_ANI_STATS inside the AR5212 HAL
This commit doesn't (yet) convert the ar5212AniState -> HAL_ANI_STATE when
exporting it to userland; that'll come in the next commit.
Summary:
Add "GELI Passphrase:" prompt to boot loader.
A new loader.conf(5) option of geom_eli_passphrase_prompt="YES" will now
allow you to enter your geli(8) root-mount credentials prior to invoking
the kernel.
See check-password.4th(8) for details.
Differential Revision: https://reviews.freebsd.org/D2105
Reviewed by: (your name[s] here)
MFC after: 3 days
X-MFC-to: stable/10
Relnotes: yes
Test Plan:
Drop a head copy of check-password.4th into /boot and then apply the patch
(only the patch to /boot/check-password.4th is required; no other changes are
required but you do have to have a HEAD copy of check-password.4th to
apply the patch).
NB: The rest of your /boot files can be up to 2 years old but no older.
NB: The test won't work unless your kernel has the following change
https://svnweb.freebsd.org/base?view=revision&revision=273489
Now, put into /boot/loader.conf:
geom_eli_passphrase_prompt="YES"
and reboot.
You should be prompted for a GELI passphrase before the menu (if enabled),
just after loading loader.conf(5).
NB: It doesn't matter if you're using GELI or not. However if you are using
GELI and a sufficiently new enough release (has SVN r273489) and you entered
the proper passphrase to mount your GELI encrypted root device(s), you should
notice that the boot process did not stop (you went from loader all the way to login).
Reviewers: cperciva, allanjude, scottl, kmoore
Subscribers: jkh, imp
Differential Revision: https://reviews.freebsd.org/D2105
vocabularies delay-processing, password-processing, version-processing,
frame-drawing, menu-infrastructure, menu-namespace, menu-command-helpers,
and menusets-infrastructure. The net effect is to remove almost 200
definitions from the main forth vocabulary reducing the dictionary size
by over 50%. The chances of hitting "dictionary full" should be greatly
reduced by this patch.
MFC after: 3 days
X-MFC-to: stable/10
implementation.
The kernel RPC code, which is responsible for the low-level scheduling
of incoming NFS requests, contains a throttling mechanism that
prevents too much kernel memory from being tied up by NFS requests
that are being serviced. When the throttle is engaged, the RPC layer
stops servicing incoming NFS sockets, resulting ultimately in
backpressure on the clients (if they're using TCP). However, this is
a very heavy-handed mechanism as it prevents all clients from making
any requests, regardless of how heavy or light they are. (Thus, when
engaged, the throttle often prevents clients from even mounting the
filesystem.) The throttle mechanism applies specifically to requests
that have been received by the RPC layer (from a TCP or UDP socket)
and are queued waiting to be serviced by one of the nfsd threads; it
does not limit the amount of backlog in the socket buffers.
The original implementation limited the total bytes of queued requests
to the minimum of a quarter of (nmbclusters * MCLBYTES) and 45 MiB.
The former limit seems reasonable, since requests queued in the socket
buffers and replies being constructed to the requests in progress will
all require some amount of network memory, but the 45 MiB limit is
plainly ridiculous for modern memory sizes: when running 256 service
threads on a busy server, 45 MiB would result in just a single
maximum-sized NFS3PROC_WRITE queued per thread before throttling.
Removing this limit exposed integer-overflow bugs in the original
computation, and related bugs in the routines that actually account
for the amount of traffic enqueued for service threads. The old
implementation also attempted to reduce accounting overhead by
batching updates until each queue is fully drained, but this is prone
to livelock, resulting in repeated accumulate-throttle-drain cycles on
a busy server. Various data types are changed to long or unsigned
long; explicit 64-bit types are not used due to the unavailability of
64-bit atomics on many 32-bit platforms, but those platforms also
cannot support nmbclusters large enough to cause overflow.
This code (in a 10.1 kernel) is presently running on production NFS
servers at CSAIL.
Summary of this revision:
* Removes 45 MiB limit on requests queued for nfsd service threads
* Fixes integer-overflow and signedness bugs
* Avoids unnecessary throttling by not deferring accounting for
completed requests
Differential Revision: https://reviews.freebsd.org/D2165
Reviewed by: rmacklem, mav
MFC after: 30 days
Relnotes: yes
Sponsored by: MIT Computer Science & Artificial Intelligence Laboratory
%rdi, %rsi, etc are inadvertently bypassed along with the check to
see if the instruction needs to be repeated per the 'rep' prefix.
Add "MOVS" instruction support for the 'MMIO to MMIO' case.
Reviewed by: neel
specially aml8726-m6 and aml8726-m8b SoC based devices.
aml8726-m6 SoC exist in devices such as Visson ATV-102.
Hardkernel ODROID-C1 board has aml8726-m8b SoC.
The following support is included:
Basic machdep code
SMP
Interrupt controller
Clock control driver (aka gate)
Pinctrl
Timer
Real time clock
UART
GPIO
I2C
SD controller
SDXC controller
USB
Watchdog
Random number generator
PLL / Clock frequency measurement
Frame buffer
Submitted by: John Wehle
Approved by: stas (mentor)
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.
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
