Round displayed pps (instead of truncating)


git-svn-id: svn://svn.freebsd.org/base/head@239139 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Clarify comments about number of tx / rx rings


git-svn-id: svn://svn.freebsd.org/base/head@239140 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Fix whitespace (missing newline)


git-svn-id: svn://svn.freebsd.org/base/head@239141 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Fix an incorrect comment.


git-svn-id: svn://svn.freebsd.org/base/head@239142 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
More rototilling with target mode in an attemp to get multiple
CCB at a time outstanding reliable. It's not there yet, but this
is the direction to go in so might as well commit. So far,
multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode),
but it fails if there are more downstream than the SIM wants
to handle and SRR is sort of confused when this happens, plus
it is not entirely quite clear what one does if a CCB/CTIO fails
and you have more in flight (that don't fail, say) and more queued
up at the SIM level that haven't been started yet.

Some of this is driven because there apparently is no flow control
to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO
requests. It is also more driven in that the few target mode
periph drivers there are are not really set up for handling pushback-
heck most of them don't even check for errors (and what would they
really do with them anyway? It's the initiator's problem, really....).

The data transfer arithmetic has been worked over again to handle
multiple outstanding commands, so you have a notion of what's been
moved already as well as what's currently in flight. It turns that
this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET
code which was sending back 24 bytes of rpl data instead of the
specified 16. What happened furthermore here is that sending back
16 bytes and reporting an overrun of 8 bytes made the initiator
(running FC-Tape aware f/w) mad enough to request, and keep
requesting, another FCP response (I guess it didn't like the answer
so kept asking for it again).

Sponsored by: Spectralogic
MFC after:	1 month


git-svn-id: svn://svn.freebsd.org/base/head@239143 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Be more descriptive about poll error / timeout when transmitting.


git-svn-id: svn://svn.freebsd.org/base/head@239145 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Improve lock and unlock symmetry

- Move destruction of per-ring locks to netmap_dtor_locked to mirror the
initialization that happens in NIOCREGIF.  Otherwise unloading a netmap-
capable interface that was never put into netmap mode would try to
mtx_destroy an uninitialized mutex, and panic.

- Destroy core_lock in netmap_detach, mirroring init in netmap_attach.

- Also comment out the knlist_destroy for now as there is currently no
knlist_init.

Sponsored by:   ADARA Networks
Reviewed by:    luigi@


git-svn-id: svn://svn.freebsd.org/base/head@239149 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
nftw(): Do not check the maxfds argument against OPEN_MAX.

Apart from the fact that nothing should have OPEN_MAX as a limit (as opposed
to RLIMIT_NOFILE from getrlimit() or _SC_OPEN_MAX from sysconf()), POSIX
does not require us to check this.

PR:		95239
Submitted by:	Todd Miller


git-svn-id: svn://svn.freebsd.org/base/head@239150 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
ftw(): Do not check the maxfds argument against OPEN_MAX.

Apart from the fact that nothing should have OPEN_MAX as a limit (as opposed
to RLIMIT_NOFILE from getrlimit() or _SC_OPEN_MAX from sysconf()), POSIX
does not require us to check this. POSIX does have a requirement on the
application that maxfds not exceed {OPEN_MAX}, but does not require the
implementation to check it ("may fail").

PR:		95239


git-svn-id: svn://svn.freebsd.org/base/head@239151 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Merge r132141 and r111272 from amd64/i386:
  Reduce the size of a PV entry by eliminating pv_ptem.  There is no need
  to store a pointer to the page table page in the PV entry because it is
  easily computed during the walk down the page table.

  Eliminate the ptphint from the pmap.  Long, long ago, page table pages
  belonged to a vm object, and we would look up page table pages based
  upon their offset within this vm object.  In those days, this hint may
  have had tangible benefits.

Tested by:	jchandra


git-svn-id: svn://svn.freebsd.org/base/head@239152 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
SCHED_4BSD scheduling quantum mechanism appears to be broken for some time.
With switchticks variable being reset each time thread preempted (that is
done regularly by interrupt threads) scheduling quantum may never expire.
It was not noticed in time because several other factors still regularly
trigger context switches.

Handle the problem by replacing that mechanism with its equivalent from
SCHED_ULE called time slice. It is effectively the same, just measured in
context of stathz instead of hz. Some unification is probably not bad.


git-svn-id: svn://svn.freebsd.org/base/head@239153 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Refresh with OpenBSD RCS ID changes to reflect that we now have essentionally
the same file.


git-svn-id: svn://svn.freebsd.org/base/head@239156 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Rework r220198 change (by fabient). I believe it solves the problem from
the wrong direction. Before it, if preemption and end of time slice happen
same time, thread was put to the head of the queue as for only preemption.
It could cause single thread to run for indefinitely long time. r220198
handles it by not clearing TDF_NEEDRESCHED in case of preemption. But that
causes delayed context switch every time preemption happens, even when not
needed.

Solve problem by introducing scheduler-specifoc thread flag TDF_SLICEEND,
set when thread's time slice is over and it should be put to the tail of
queue. Using SW_PREEMPT flag for that purpose as it was before just not
enough informative to work correctly.

On my tests this by 2-3 times reduces run time deviation (improves fairness)
in cases when several threads share one CPU.

Reviewed by:	fabient
MFC after:	2 months
Sponsored by:	iXsystems, Inc.


git-svn-id: svn://svn.freebsd.org/base/head@239157 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
nftw(): POSIX says directories causing loops should be silently skipped.

Formerly, loops caused nftw() to abort the traversal with ELOOP.


git-svn-id: svn://svn.freebsd.org/base/head@239160 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Add HAL_DMA_ADDR.


git-svn-id: svn://svn.freebsd.org/base/head@239161 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Add a missing HAL_DMA_ADDR definition.


git-svn-id: svn://svn.freebsd.org/base/head@239162 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Add charge pump current register.


git-svn-id: svn://svn.freebsd.org/base/head@239167 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
More comments about setting PLLA, or rather that we never do.


git-svn-id: svn://svn.freebsd.org/base/head@239168 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
RFC 2289 requires all hashes be stored in little endian format before
folding to 64 bits, while SHA1 code is big endian.  Therefore, a bswap32
is required before using the value.

Without this change, the implementation does not conform to test vector
found in RFC 2289.

PR:		bin/170519
Submitted by:	Arthur Mesh <arthurmesh gmail com> (with changes)
MFC after:	1 week


git-svn-id: svn://svn.freebsd.org/base/head@239169 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Merge r134393 from amd64/i386:
  The machine-independent parts of the virtual memory system always pass a
  valid pmap to the pmap functions that require one.  Remove the checks for
  NULL.  (These checks have their origins in the Mach pmap.c that was
  integrated into BSD.  None of the new code written specifically for
  FreeBSD included them.)


git-svn-id: svn://svn.freebsd.org/base/head@239170 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f