description was eaten by the dog (or an editor crash or something).
Add variable-frequency support to the arm mpcore eventtimer driver.
This allows a platform's early init code to tell the mpcore driver that the
clock frequency can vary. That causes the mpcore driver to register an
eventtimer, but not a timecounter. The platform has to provide a time
counter using some other fixed-frequency clock, but can still use the
per-cpu goodness of the mpcore hardware for event timers.
When the platform support code does something to change the frequency of
the CPU clocks (power saving, thermal management) it must tell the mpcore
driver code about it using arm_tmr_change_frequency().
register values, then restart the timer. This prevents a situation where
an old event fires just as we're about to load a new value into the timer,
when the start routine is called to change the time of the current event.
Also re-nest the parens properly for casting the result of converting
time and frequency to a count. This doesn't actually change the result of
the calcs, but will some day prevent a loss-of-precision warning on the
assignment, if that warning gets enabled.
few of them also build kern_clocksource.c. That strikes me as insane, but
maybe there's a good reason for it. Until I figure that out, un-break
the build by not referencing functions in kern_clocksource if NO_EVENTTIMERS
is defined.
when WITH_COMPRESSED_IMAGES is used.
Requested by: delphij, brooks, Nikolai Lifanov
MFC After: 1 week
X-MFC-With: r264027,r264028,r264029,r264030
Sponsored by: The FreeBSD Foundation
4248 dtrace(1M) should never create DOF with empty probes section
4249 Only probes from the first DTrace object file will be included
Illumos Revision: 4a20ab41aadcb81c53e72fc65886e964e9add59
Reference:
https://www.illumos.org/issues/4248https://www.illumos.org/issues/4249
Obtained from: Illumos
MFC after: 1 month
causing mb* functions (and similar) to be called with the wrong data
(possibly a null pointer, causing a crash).
PR: standards/188036
MFC after: 1 week
default wMaxPacketSize (64 or 512 bytes). This actually helps older FTDI
devices (which were USB 1/full speed) more than the new H-series high
speed, but even for the new chips it helps cut the number of interrupts
when doing very high speed (3-12mbaud).
When set to a non-empty value, the installation medium is
compressed with gzip(1) as part of the 'install' target in
the release/ directory.
With gzip(1) compression, downloadable image are reduced in
size quite significantly. Build test against head@263927
shows the following:
bootonly.iso: 64% smaller
disc1.iso: 44% smaller
memstick.img: 47% smaller
mini-memstick.img: 65% smaller
dvd1.iso: untested
This option is off by default, I would eventually like to
turn it on by default, and remove the '-k' flag to gzip(1)
so only compressed images are published on FTP.
Requested by: wkoszek
MFC After: 1 week
Sponsored by: The FreeBSD Foundation
This avoids extra locking in icl_pdu_queue(); the upper layer needs to call
it while holding its own lock anyway, to avoid sending PDUs out of order.
Sponsored by: The FreeBSD Foundation
A bug caused the "big endian" flag to be lost when receiving a message. As a
result, the bits are interpreted as little endian and an extremely large
allocation is attempted.
This change fixes ping(8)'s communication to casperd(8) on big-endian
architectures.
Reported by: Anton Shterenlikht
Tested by: danfe
Teach pciconf how to print out the status (enabled/disabled) of the ARI
capability on PCI Root Complexes and Downstream Ports.
MFC after: 2 months
Sponsored by: Sandvine Inc.
PCIe Alternate RID Interpretation (ARI) is an optional feature that
allows devices to have up to 256 different functions. It is
implemented by always setting the PCI slot number to 0 and
re-purposing the 5 bits used to encode the slot number to instead
contain the function number. Combined with the original 3 bits
allocated for the function number, this allows for 256 functions.
This is enabled by default, but it's expected to be a no-op on currently
supported hardware. It's a prerequisite for supporting PCI SR-IOV, and
I want the ARI support to go in early to help shake out any bugs in it.
ARI can be disabled by setting the tunable hw.pci.enable_ari=0.
Reviewed by: kib
MFC after: 2 months
Sponsored by: Sandvine Inc.
Recent FDTI chips have the ability to operate at up to 12mbps. The newer
chips with faster clocks have the same usb vendor/product IDs as the older
chips; the bcdDevice field must be used to detect the newer versions. This
change includes a new function to do that instead of using just the IDs from
the vendor/product table.
The code to choose the baud clock divisor is completely rewritten. In
addition to supporting the new higher clock rates, the rewrite fixes a
longstanding bug in the old code which put the high bits of the fractional
part of the divisor into the wrong place in the wIndex field. That bug
was mostly harmless -- it accidentally didn't affect standard baud rates
and would only show up when using relatively fast non-standard rates.
Under the hood the VT-d spec is really implemented in terms of
PCI RIDs instead of bus/slot/function, even though the spec makes
pains to convert back to bus/slot/function in examples. However
working with bus/slot/function is not correct when PCI ARI is
in use, so convert to using RIDs in most cases. bus/slot/function
will only be used when reporting errors to a user.
Reviewed by: kib
MFC after: 2 months
Sponsored by: Sandvine Inc.
My PCI RID changes somehow got intermixed with my PCI ARI patch when I
committed it. I may have accidentally applied a patch to a non-clean
working tree. Revert everything while I figure out what went wrong.
Pointy hat to: rstone
Under the hood the VT-d spec is really implemented in terms of
PCI RIDs instead of bus/slot/function, even though the spec makes
pains to convert back to bus/slot/function in examples. However
working with bus/slot/function is not correct when PCI ARI is
in use, so convert to using RIDs in most cases. bus/slot/function
will only be used when reporting errors to a user.
Reviewed by: kib
Sponsored by: Sandvine Inc.
generate dwarf4 by default as well, so always force dwarf2 when
generating debugging data. It is harmless on older versions of both
clang and gcc, but required on newer ones.
being defined. The system works fine without it (because GNUCXX isn't
built when WITHOUT_CXX is defined), and it is one of the few places we
test WITHOUT_FOO instead of MK_FOO in the base system. Simply
eliminate it to solve both problems. Also, minor tweak to make it
clearer that the default is always NO for GNUGCC on i386.
introduced, the meaning of WITH_FDT changed from 'do FDT in boot
loader and build dtc compiler' to be simply 'do FDT things in the boot
loader'. Now that we test for FDT in the architecture specific files,
this test here is now redunant and encourages bad behavior, so just
eliminate it and make it always yes. Those architectures whose boot
loaders don't support FDT already omit it when it is set to yes
anyway.
