Add internal tracking of smp startup status to reliably figure out
   what methods are to be used to get gtaskqueue up and running.

e1000:
   Calculating this pointer gives undefined behaviour when (last == -1)
   (it is before the buffer).  The pointer is always followed.  Panics
   occurred when it points to an unmapped page.  Otherwise, the pointed-to
   garbage tends to not have the E1000_TXD_STAT_DD bit set in it, so in the
   broken case the loop was usually null and the function just returned, and
   this was acidentally correct.

Submitted by:	bde
Reviewed by:	Matt Macy <mmacy@nextbsd.org>

If "capacity" LU option is set, ramdisk backend now implements featured
thin provisioned disk, storing data in malloc(9) allocated memory blocks
of pblocksize bytes (default PAGE_SIZE or 4KB).  Additionally ~0.2% of LU
size is used for indirection tree (bigger pblocksize reduce the overhead).
Backend supports all unmap and anchor operations.  If configured capacity
is overflowed, proper error conditions are reported.

If "capacity" LU option is not set, the backend operates mostly the same
as before without allocating real storage: writes go to nowhere, reads
return zeroes, reporting that all LBAs are unmapped.

This backend is still mostly oriented on testing and benchmarking (it is
still a volatile RAM disk), but now it should allow to run real FS tests,
not only simple dumb dd.

MFC after:	2 weeks

PR:		215922
Submitted by:	danielsh AT apache DOT org
Approved by:	bcr (mentor)
MFC after:	5 days
Differential Revision:	https://reviews.freebsd.org/D9313

While here, extract NARGREG as a definition.

Reviewed by:	br
Differential Revision:	https://reviews.freebsd.org/D9249

Reviewed by:	sephe
Approved by:	sephe (mentor)
MFC after:	2 weeks
Sponsored by:	Microsoft
Differential Revision:	https://reviews.freebsd.org/D9102

This makes it easier for the userland script to find the releated
VF interface.

Reviewed by:	sephe
Approved by:	sephe (mentor)
MFC after:	2 weeks
Sponsored by:	Microsoft
Differential Revision:	https://reviews.freebsd.org/D9101

Hyper-V's NIC SR-IOV implementation needs a Hyper-V synthetic NIC and
a VF NIC to work together (both NICs have the same MAC address), mainly to
support seamless live migration.

When the VF device becomes UP (or DOWN), the synthetic NIC driver needs
to switch the data path from the synthetic NIC to the VF (or the opposite).

Note: multicast/broadcast packets are still received through the synthetic
NIC and we need to inject the packets through the VF interface (if the VF is
UP), even if the synthetic NIC is DOWN (so we need to force the rxfilter
to be NDIS_PACKET_TYPE_PROMISCUOUS, when the VF is UP).

Reviewed by:	sephe
Approved by:	sephe (mentor)
MFC after:	2 weeks
Sponsored by:	Microsoft
Differential Revision:	https://reviews.freebsd.org/D8964

Hyper-V's NIC SR-IOV implementation needs a Hyper-V synthetic NIC and
a VF NIC to work together, mainly to support seamless live migration.

When the VF device becomes UP (or DOWN), the synthetic NIC driver needs
to switch the data path from the synthetic NIC to the VF (or the opposite).

So the synthetic NIC driver needs to know when a VF device is becoming
UP or DOWN and hence the patch is made.

Reviewed by:	sephe
Approved by:	sephe (mentor)
MFC after:	2 weeks
Sponsored by:	Microsoft
Differential Revision:	https://reviews.freebsd.org/D8963

It's unnecessary because the upper nework stack does the same checking.

In the case of Hyper-V SR-IOV, we need to remove the checking because
1) multicast/broadcast packets are still received through the synthetic
NIC and we need to inject the packets through the VF interface;
2) we must inject the packets even if the synthetic NIC is down, or has
a different MTU from the VF device.

Reviewed by:	sephe
Approved by:	sephe (mentor)
MFC after:	2 weeks
Sponsored by:	Microsoft
Differential Revision:	https://reviews.freebsd.org/D8962

This will be used by the coming NIC SR-IOV patch.

Reviewed by:	sephe
Approved by:	sephe (mentor)
MFC after:	2 weeks
Sponsored by:	Microsoft
Differential Revision:	https://reviews.freebsd.org/D8909

PR:		203406
Submitted by:	Fehmi Noyan Isi (fnoyanisi AT yahoo DOT com)
Approved by:	wblock (mentor)
MFC after:	5 days
Differential Revision:	 https://reviews.freebsd.org/D8691

MFC after:	2 weeks

Committed over the D-Link DWA-131 rev E1 on amd64 with WPA.

Reviewed by:	avos

the same cycle of the 32khz clock.

I've never actually noticed this error happening, but it's an easy fix.

Variables "fast" and "active" are both constant in lacp_port_create(), but
comments mispleadingly suggest that "fast" can be changed via ioctl. The
constant values control the value of "lp->lp_state", so it too is constant,
and the code for assigning different value to it is essentially dead.

Remove both "fast" and "active", and set "lp->lp_state" unconditionally;
that gets rid of the dead code and misleading comments.

CID: 1305692
CID: 1305734

Reported by:	asomers
Reviewed by:	asomers
MFC after:	1 week
Sponsored by:	Panasas
Differential Revision:	https://reviews.freebsd.org/D9302

Remove custom DTS duplicate of tda19988 node and use upstream-provided
one introduced by r295436. This duplication created two tdaX devices
which confused fb driver into using only 640x480 area while setting
display to native resolution.

Reported by:	Michael Smith
MFC after:	3 days

MFC after:	1 week

Makes head code compile on 10.3 and cleanup is never wrong.

MFC after:	3 days

Worker threads now use a pthread_cond_t to wait for work instead of
burning the cpu up.

Obtained from:	DragonflyBSD (07774aea0ccf64a48fcfad8899e3bf7c8f18277a)
MFC after:	2 weeks

MFC after:	2 weeks

MFC after:	2 weeks

* limit cabq to 64 - in practice if this stays at ath_txbuf then
  all buffers can be tied up by a very busy broadcast domain (eg ARP
  storm, way too much MDNS/NETBIOS).  It's been like this in the
  freebsd-wifi-build AP project for the longest time.

* Now that I figured out the hilarity inherent in aggregate forming
  and AR9380 EDMA work, change the per-node to 64 frames by default.
  I'll do some more work to shorten the queue latency introduced when
  doing data so TCP isn't so terrible, but it's now no longer /always/
  tens of milliseconds of extra latency  when doing active iperf tests.

Notes:

The reason for the extra latency is partly tx/rx taskqueue handling and
scheduling, and partly due to a lack of airtime/QoS awareness of per-node
traffic.  Ideally we'd have different limits/priorities on the QoS/TID
levels per node so say, voice/video data got a better share of buffer
allocations over best effort/bulk data, but we currently don't implement
that.  It's not /hard/ to do, I just need to do it.

Tested:

* AR9380 (STA), AR9580 (hostap) - both with the relevant changes.
  TCP is now at around 180mbit with rate control and RTS protection
  enabled.  UDP stays at 355mbit at MCS23, no HT protection.

This is two fixes, which establishes what I /think/ is pretty close to the
theoretical PHY maximum speed on the AR9380 devices.

* When doing A-MPDU on a TID, don't queue to the hardware directly if
  the hardware queue is busy.  This gives us time to get more packets
  queued up (and the hardware is busy, so there's no point in queuing
  more to the hardware right now) to potentially form an A-MPDU.

  This fixes up the throughput issue I was seeing where a couple hundred
  single frames were being sent a second interspersed between A-MPDU
  frames.  It just happened that the software queue had exactly one
  frame in it at that point.  Queuing it until the hardware finishes
  transmitting isn't exactly costly.

* When determining whether to dequeue from a software node/TID queue into
  the hardware queue, fix up the checks to work right for EDMA chips
  (ar9380 and later.)   Before it was not dispatching anything until
  the FIFO was empty.  Now we allow it to dispatch another aggregate
  up to the hardware aggregate limit, like I intended with the earlier
  work.

This allows a 5GHz HT40, short-GI, "htprotmode off" test at MCS23
to achieve 357 Mbit/sec in a one-way UDP test.  The stars have to be
aligned /just right/ so there are no retries but it can happen.
Just don't expect it to work in an OTA test if your 2yo is running
around the room - MCS23 is very very sensitive to channel conditions.

Tested:

* AR9380 STA (test) -> AR9580 hostap

TODO:

* More thorough testing on pre-AR9380 chips (AR5416, AR9160, AR9280)
* (Finally) teach ath_rate_sample about throughput/latency rather than
  air time, so I can get good transmit rates with a 2yo running around.

When investigating performance on UDP TX on the AR9380 I found that the
following sequence was occuring:

* INTR
* EINPROGRESS - nothing yet
* INTR
* TXSTATUS - process a TX completion for an aggregate
* INTR, INTR
* TXSTATUS - process a TX completion for an aggregate
* TXD, TXD ... populate frames from the hardware queue and submit

What should be happening is a completed TXSTATUS fires off more packets
that are queued on active TIDs.

What /was/ happening was after that first TXSTATUS the TX queue hardware queue
was still empty, so it didn't push anything into the FIFO.  Only after the
second TXSTATUS did any progress get made.

This is one of two commits - it ensures that the software TX queue scheduler
is called /after/ TX completion, otherwise no frames from the software staging
queues will be processed into the hardware queues.

The second commit will fix it so it populates aggregate frames correctly
when the above occurs - right now ath_txq_sched() is called, but it doesn't
populate anything because its pre-check conditions are wrong.

Whilst here, add/tweak debugging.

Tested:

* AR9380 STA (testing device) -> AR9580 hostap

Building kernel with devel/powerpc64-gcc (6.2.0) yields the following error:
/usr/src/sys/powerpc/powerpc/db_trace.c:299:20: error: calling
'__builtin_frame_address' with a nonzero argument is unsafe
[-Werror=frame-address]

Work around this by dereferencing the frame address manually instead.

PR:		215600
Reported by:	Mark Millard <markmi AT dsl-only DOT net>
MFC after:	2 weeks

This ioctl has been considered legacy by upstream since the DTrace code
was first imported, and is unused. The removal also allows some
simplification of dtrace_helper_slurp().

Also remove a bogus copyout in the DTRACEHIOC_ADDDOF handler. Due to a
bug, it would overwrite an in-memory copy of the DOF header rather than
the passed-in DOF helper. Moreover, DTRACEHIOC_ADDDOF already copies the
helper back out automatically since its argument has the IOC_OUT attribute.

to line up output from "iscsictl -v" with "ctladm islist -v".

MFC after:	2 weeks

This changes the CTL frontend ABI and thus shouldn't be MFC-ed.

Reviewed by:	mav@

It again reinstall missing skel files without overwriting changed one
Add a regression test about it

Reported by:	ae
MFC after:	3 days

Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D9258

Submitted by:	wblock
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
Differential revision:	https://reviews.freebsd.org/D9211

critical_exit().

Based on the discussion with:	jhb
Reviewed by:	imp
Sponsored by:	The FreeBSD Foundation
Differential revision:	D9276
MFC after:	1 week

to VNASSERT in _vn_lock(), simplify messages.

Sponsored by:	The FreeBSD Foundation
X-MFC with:	r312600, r312601, r312602, r312606

In particular, crossmp vnode might leak into rename code.

PR:	216380
Reported by:	fnacl@protonmail.com
Sponsored by:	The FreeBSD Foundation
X-MFC with:	r309425

pw usermod foo -m

It used to be able to (re)create the home directory if it didn't exists

PR:		216224
Reported by:	ae
MFC after:	3 days

PR:	208343
Submitted by:	Kaho Tashikazu <kaho@elam.kais.kyoto-u.ac.jp>