r344903 mav March 7, 2019, 10:56 p.m.
I just found that at least on Skylake CPUs cpu_ticks() never returns odd
values, only even, and possibly has even bigger step (176/2?), that makes
its lower bits very bad entropy source, leaving half of taskqueues unused.
Switch to sbinuptime(), closer to upstreams, mitigates the problem by the
rate conversion working as kind of hash function.  In case that is somehow
not enough (timer rate is too low or too divisible) mix in curcpu.

MFC after:	1 week
r344902 jilles March 7, 2019, 10:51 p.m.
r344901 brooks March 7, 2019, 10:34 p.m.
r344900 brooks March 7, 2019, 10:20 p.m.
The GPL-2.0 tag is a deprecated tag which means that same thing as
r344896 dim March 7, 2019, 7:33 p.m.
Fix inline assembler constraint validation

  The current constraint logic is both too lax and too strict. It fails
  for input outside the [INT_MIN..INT_MAX] range, but it also
  implicitly accepts 0 as value when it should not. Adjust logic to
  handle both correctly.

  Differential Revision: https://reviews.llvm.org/D58649

Pull in r355491 from upstream clang trunk (by Hans Wennborg):

  Inline asm constraints: allow ICE-like pointers for the "n"
  constraint (PR40890)

  Apparently GCC allows this, and there's code relying on it (see bug).

  The idea is to allow expression that would have been allowed if they
  were cast to int. So I based the code on how such a cast would be
  done (the CK_PointerToIntegral case in

  Differential Revision: https://reviews.llvm.org/D58821

These should fix assertions and errors when using the inline assembly
"n" constraint in certain ways.

In case of devel/valgrind, a pointer was used as the input for the
constraint, which lead to "Assertion failed: (isInt() && "Invalid
accessor"), function getInt".

In case of math/secp256k1, a very large integer value was used as input
for the constraint, which lead to "error: value '4624529908474429119'
out of range for constraint 'n'".

PR:             236216, 236194
MFC after:      1 month
X-MFC-With:     r344779
r344895 manu March 7, 2019, 7:32 p.m.
The tcon clock need a mux table for it's parent, for now just
list the parents twice.
r344894 manu March 7, 2019, 7:30 p.m.
The Display Engine 2 have it's own Clock and Control Unit, add support
for it.
r344893 manu March 7, 2019, 7:28 p.m.
If the NM clock is using a fractional divider the formula isn't the same.
r344892 manu March 7, 2019, 6:57 p.m.
r344891 cem March 7, 2019, 6:24 p.m.
This matches GNU seq, for example.

For users that are looking for similar functionality, 'jot -b foo N' will
print 'foo' N times.  See jot(1).

PR:		236347
Reported by:	<y AT maya.st>
Sponsored by:	Dell EMC Isilon
r344883 cy March 7, 2019, 1:36 p.m.
4.2.8p12 --> 4.2.8p13

MFC after:	immediately
Security:	CVE-2019-8936
		VuXML: c2576e14-36e2-11e9-9eda-206a8a720317
Obtained from:	nwtime.org
r344876 kp March 7, 2019, 11:09 a.m.
Make the tests run slightly faster by having pft_ping.py end the capture
of packets as soon as it sees the expected packet, rather than
continuing to sniff.

MFC after:	2 weeks
r344875 0mp March 7, 2019, 11:09 a.m.
The ports version of cal is an abandonware so in order to minimize the
potential bit rot of our documentation let's not mention it at all.
Interested users are going to find suitable alternatives anyway on their

Reported by:	bapt
Approved by:	bapt (src)
Approved by:	krion (mentor, implicit), mat (mentor, implicit)
Differential Revision:	https://reviews.freebsd.org/D19492
r344874 0mp March 7, 2019, 10:19 a.m.
Reviewed by:	bcr
Approved by:	bcr (doc)
Approved by:	krion (mentor, implicit), mat (mentor, implicit)
Differential Revision:	https://reviews.freebsd.org/D19491
r344873 ae March 7, 2019, 10:01 a.m.
MFC after:	1 week