not change interrupt vector if it is not pointing the ROM itself. Actually,
we just fail shadowing altogether if that is the case because the shadowed
copy will be useless for sure and POST may not be relocatable or useful.
While I'm here, fix a debugging message under bootverbose, really. r211829
fixed one case but broke another. Mea Culpa.
or not by comparing reported TX consumer index with saved index. So
remove unnecessary check done after freeing transmitted mbufs.
While I'm here nuke unnecessary variable initializations.
tag. All controllers that are not BCM5755 or higher have 4GB
boundary DMA bug. Previously bge(4) used 32bit DMA address to
workaround the bug(r199670). However this caused the use of bounce
buffers such that it resulted in poor performance for systems which
have more than 4GB memory. Because bus_dma(9) honors boundary
restriction requirement of DMA tag for dynamic buffers, having a
separate TX/RX mbuf DMA tag will greatly reduce the possibility of
using bounce buffers. For DMA buffers allocated with
bus_dmamem_alloc(9), now bge(4) explicitly checks whether the
requested memory region crossed the boundary or not.
With this change, only the DMA buffer that crossed the boundary
will use 32bit DMA address. Other DMA buffers are not affected as
separate DMA tag is created for each DMA buffer.
Even if 32bit DMA address space is used for a buffer, the chance to
use bounce buffer is still very low as the size of buffer is small.
This change should eliminate most usage of bounce buffers on
systems that have more than 4GB memory.
More correct fix would be teaching bus_dma(9) to honor boundary
restriction for buffers created with bus_dmamem_alloc(9) but it
seems that is not easy.
While I'm here cleanup bge_dma_map_addr() and remove unnecessary
member variables in bge_dmamap_arg structure.
Tested by: marcel
heavy I/O load.
Many thanks to LSI for continuing to support FreeBSD.
PR: kern/149968
Submitted by: LSI (Tom Couch)
Reported by: Kai Kockro <kkockro web de>
Tested by: Kai Kockro, jpaetzel
MFC after: 7 days
configuration function. For failed memory allocations, em(4)/lem(4)
called panic(9) which is not acceptable on production box.
igb(4)/ixgb(4)/ix(4) allocated the required memory in stack which
consumed 768 bytes of stack memory which looks too big.
To address these issues, allocate multicast array memory in device
attach time and make multicast configuration success under any
conditions. This change also removes the excessive use of memory in
stack.
Reviewed by: jfv
Just showing some buffer allocation error is more appropriate
action for drivers. This should fix occasional panic reported on
em(4) when driver encountered resource shortage.
Reviewed by: jfv
supported by many BIOSes to improve performance of VESA BIOS calls for real
mode OSes but it is not our intention here. However, this may help some
platforms where the video ROMs are inaccessible after suspend, for example.
Note it may consume up to 64K bytes of contiguous memory depending on video
controller model when it is enabled. This feature can be disabled by
setting zero to 'debug.vesa.shadow_rom' loader tunable via loader(8) or
loader.conf(5). The default is 1 (enabled), for now.
ID, plus the ability to force '16-bit mode' which really means NE-2000
mode. Other open source drivers suggest that the Holtek misbehaves if
you allow the 8-bit probe. Also, all of the PCI chips emulate
NE-2000ish cards, so always force 16-bit mode for memory transfers.
PR: 84202 (patch not used)
I'm not sure whether adding this logical id is correct or not
because Compex RL2000 is in the list of supported hardware list.
I guess the Compex RL2000 could be PCI variant while the controller
in question is ISA controller. It seems PNP compat id didn't match
or it had multiple compat ids so isa_pnp_probe() seemed to return
ENOENT.
PR: kern/80853
support WOL. Some controllers require additional 3-wire auxiliary
remote wakeup connector to draw power. More recent xl(4)
controllers may not need the wakeup connector though.
initialize controller from a known good state. Previously driver
used to issue controller reset while TX/RX DMA are in progress.
I guess resetting controller in active TX/RX DMA cycle is to ensure
stopping I/Os in xl_shutdown(). I remember some buggy controllers
didn't respond with stop command if controller is under high
network load at the time of shutdown so resetting controller was
the only safe way to stop the I/Os. However, from my experiments,
controller always responded with stop command under high network
load so I think it's okay to remove the xl_reset() in
device_shutdown handler.
Resetting controller also will clear configured RX filter which
in turn will make WOL support hard because driver have to reprogram
RX filter in WOL handler as well as setting station address.
datagrams with checksum value 0 when TX UDP checksum offloading is
enabled. Generating UDP checksum value 0 is RFC 768 violation.
Even though the probability of generating such UDP datagrams is
low, I don't want to see FreeBSD boxes to inject such datagrams
into network so disable UDP checksum offloading by default. Users
still override this behavior by setting a sysctl variable or loader
tunable, dev.bge.%d.forced_udpcsum.
I have no idea why this issue was not reported so far given that
bge(4) is one of the most commonly used controller on high-end
server class systems. Thanks to andre@ who passed the PR to me.
PR: kern/104826
Makefiles or *.mk files, use ${CC:T:Mfoo} instead, so only the basename
of the compiler command (excluding any arguments) is considered.
This allows you to use, for example, CC="/nondefault/path/clang -xxx",
and still have the various tests in bsd.*.mk identify your compiler as
clang correctly.
ICC if cases were also changed.
Submitted by: Dimitry Andric <dimitry at andric.com>
method is used by the PCI bus driver to query the power management system
to determine the proper device state to be used for a device during suspend
and resume. For the ACPI PCI bridge drivers this calls
acpi_device_pwr_for_sleep(). This removes ACPI-specific knowledge from
the PCI and PCI-PCI bridge drivers.
Reviewed by: jkim
If it does, don't then try reprogramming the NF "cap" values (ie
what values are the "maximum" value the NF can be) - instead,
just leave the current CCA value as the NF cap.
This was inspired by some similar work from ath9k. It isn't
a 100% complete solution (as there may be some reason where a
high NF CCA/cap is written, causing the baseband to stop thinking it
is able to transmit, leading to stuck beacon and interface reset)
which I'll investigate and look at fixing in a later commit.
Obtained from: Linux
AR5416 and later chipsets.
ath_hal_calibrateN() calls the HAL calibrateN function with rxchainmask=0x1.
This is not necessarily the case for AR5416 and later chipsets.
list of devices supported by uplcom(4) with the following sources:
NetBSD src/sys/dev/usb/uplcom.c 1.70
OpenBSD src/sys/dev/usb/uplcom.c 1.52
Linux drivers/usb/serial/pl2303.h from kernel 2.6.35
BeOS usb_serial/driver.c 1.32
Give several devices better descriptions, and rename
PROLIFIC2 -> NETINDEX while here to match everybody else.
MFC after: 6 weeks (after r211111)
flag immediately so it's only set once per longcal interval.
Without this, the current AR5416 code will continuously spam NF
calibrations during a periodic calibration if the longcal flag
is set. The longcal flag wouldn't be cleared until the calibration
method indicates that calibrations are "complete".
This drops the rate of NF calibration updates down from "once every
shortcal" (ie, every 100ms) during a periodic calibration, to only
once per "longcal" interval. Spamming NF calibrations every 100ms
caused some potentially horrific issues in noisy environments as
NF calibrations can take longer than 100ms and this spamming can
cause invalid NF calibration results to be read back - leading to
missed beacons, and thus leading to a stuck beacon situation.
Stuck beacons cause interface resets, which restart calibrations.
This means that the longcal calibration runs every 100ms (shortcal)
until all initial calibrations are completed. This spamming can then
cause the above issues which leads to stuck beacons, leading to
interface resets, etc, etc. Quite annoying.
within the device table. This code uses the same algorithm as used in the
Linux, NetBSD and DragonflyBSD driver.
While investigating this, it became apparent that the Linux driver always
initialises the device, and not just in the PL2303HX case. Change
uplcom(4) to do the same.
This change allows us to synchronize our device ID list with Linux and
NetBSD, without requiring knowledge of the chipset in use.
Reviewed by: hselasky
MFC after: 6 weeks
controller. These controllers are known as L1D(AR8151) and
L2CB/B2(AR8152). This change adds supports for the following
controllers.
o AR8151 v1.0(L1D) gigabit ethernet controller
o AR8151 v2.0(L1D) gigabit ethernet controller
o AR8152 v1.1(L2CB) fast ethernet controller
o AR8152 v2.0(L2CB2) fast ethernet controller
These controllers have the same feature of AR8131/AR8132 and
support improved power saving control. The user visible change at
this moment is reduced jumbo frame size from 9KB to 6KB. Many
thanks to Atheros for continuing to support FreeBSD.
HW donated by: Atheros Communications, Inc.
- Increase target limit from 4 to 64; this limit will be removed entirely
at a later time.
- Improve recovery from lost network connections.
- Fix some potential deadlocks and a serious memory leak.
- Fix incorrect use of MH_ALIGN (instead of M_ALIGN), which makes no
practical difference, but triggers a KASSERT with INVARIANTS.
- Fix some warnings in iscontrol(8) and improve the man page somewhat.
Submitted by: Daniel Braniss <danny@cs.huji.ac.il>
Sponsored by: Dansk Scanning A/S, Data Robotics Inc.
like memory mapped register access. Typical problem from the issue
was MII access returned unreliable values. I'm not sure this comes
from lack of register flushing in MII access after accessing
STE_PHYCTL register though.
To address the issue, read hints data that controls which type of
memory mapping should be used in driver. ste(4) still prefers
memory mapping to io mapping but honor hints entered by user except
for controllers that have problems with memory mapping.
The hint to use iomapping could be given by adding the following
line to /boot/device.hints file.
hint.ste.0.prefer_iomap="1"
PR: kern/149285
MFC after: 5 days
suspend state. Also disable master clock after PHY power down,
this is supposed to save more power. The master clock should be
enabled if WOL is active.
and BeOS. The devices supported by uslcom(4) are now in sync with:
NetBSD src/sys/dev/usb/uslsa.c 1.11
OpenBSD src/sys/dev/usb/uslcom.c 1.20
Linux source/drivers/usb/serial/cp210x.c from kernel 2.6.35
BeOS usb_serial/driver.c 1.32
Two vendor/product IDs from Linux have not been added to uslcom(4):
SILABS SAEL - This device has special code in u3g to support it
SILABS GSM2228 - I suspect this should also be covered by u3g(4).
MFC after: 1 week
vendor ID in the vendor section, and by symbolic name in the product
section. Products are sorted by product ID. While here, get rid of a
duplicate Microsoft Mouse entry, revealed by sorting.
MFC after: 1 week
value resulted in poor performance for UDP packets. With this
change, UDP bulk transfer performance is more than 940Mbps.
While I'm here fix a wrong register definition.
bus_generic_resume() since the pci_link(4) driver was added.
- Change the ACPI PCI-PCI bridge driver to inherit most of its methods
from the generic PCI-PCI bridge driver. In particular, this will now
restore PCI config registers for ACPI PCI-PCI bridges.
Tested by: Oleg Sharoyko osharoiko of gmail
infrastructure, not us. This appears to be a leftover from an older
version of the driver.
Submitted by: avg
Tested by: Anton Shterenlikht <mexas bristol.ac.uk>
MFC after: 1 week
X-MFC-Note: To stable/8 and stable/7 only
This way we would have an opportunity to hide the
Tj(target) value doesn't seem right stuff if we know
it's not working there.
Add temperature value for Core2 Duo Extreme Mobile that
I have access to.
Xeon 5500/5600 series:
- Utilize IA32_TEMPERATURE_TARGET, a.k.a. Tj(target) in place
of Tj(max) when a sane value is available, as documented
in Intel whitepaper "CPU Monitoring With DTS/PECI"; (By sane
value we mean 70C - 100C for now);
- Print the probe results when booting verbose;
- Replace cpu_mask with cpu_stepping;
- Use CPUID_* macros instead of rolling our own.
Approved by: rpaulo
MFC after: 1 month
a PMC. It was possible that we could have turned a bit on but
never cleared it.
Extend the calls to rdmsr() to all necessary functions, not
just those which previously caused a panic.
Pointed out by: jhb@
MFC after: 1 week
the official vendor listed for 0x076b, rather than Omnikey, as in the PR.
PR: usb/123351
Submitted by: Marcin Cieslak <saper SYSTEM.PL>
MFC after: 1 week
This patch is different to that provided in the PR, due to the changes in
this driver since 7.x.
PR: usb/129945
Submitted by: Antonio Hilario <avahilario gmail.com>
MFC after: 1 week
- Bring in several other devices from OpenBSD while here. Use the
official manufacturer name over the OpenBSD name in the case of
GEMALTO. Reorder list slightly to aid future syncing.
- Remove duplicate SILABS CP2102 define from usbdevs
PR: usb/131912 [1]
Submitted by: Jack Twilley <mathuin gmail.com> [1]
MFC after: 1 week
plug. Note that the Vendor ID 0x04b4 is officially assigned to Cypress,
so use that instead of adding a second vendor with an identical ID, in the
same way other similar cases are treated in usb/usbdevs.
PR: usb/132785
Submitted by: Dirk-Willem van Gulik <dirkx webweaving.org>
MFC after: 1 week
10G cards. 1G cards are x4 only.
- Use constants from pcireg.h for reading the current link width.
- Use pci_set_max_read_req() rather than implementing it by hand.
Reviewed by: np
MFC after: 1 week
This is similar to a fix in r189305 but for earlier ICH versions (<= 5).
Reported by: someone via attilio
Discussed with: des, attilio
MFC after: 1 week
tail pointers of the tx and rx queues. We needed a SYSCTL_PROC
to correctly get the values at run time.
Submitted by: Andrew Boyer aboyer at averesystems.com
MFC after: 1 week
This version adds support for ARC1880; additionally this version fixed
an issue where all devices on a SAS port gets offlined when any device
failed on the port [1].
Many thanks to Areca for continuing to support FreeBSD.
PR: kern/148502 [1]
Submitted by: Ching-Lung Huang <ching2048 areca com tw>
Obtained from: Areca
Tested by: Rich Ercolani <rercola acm jhu edu> [1]
MFC after: 2 weeks
lengths. Make MI wrapper code to validate periods in request. Make kernel
clock management code to honor these hardware limitations while choosing hz,
stathz and profhz values.
- Fixed the interface probe routine to only attach to USB interfaces the driver
actually supports. This allows other drivers to attach to things like
MicroSD slots etc.
- Fixed network interface enumeration to be globally sequential instead of
relying on the USB interface numbers. This make sure the first network
interface always is at uhso0 and the second at usho1 and so on.
- Added a radio kill switch; exposed through sysctl.
- Updated the manual page to be verbose about the number of serial ports and
include iCON 452 in the set of tested hardware.
Submitted by: Fredrik Lindberg
calls. Also add BUS_DMA_COHERENT flag to bus_dmamem_alloc(9) to
take advantage of efficient synchronization for architectures that
support that feature.
Reviewed by: davidch
return code. If context was not setup correctly give up
initialization. While I'm here move variable declarations to the
beginning of the function.
Reviewed by: davidch
AcpiOsMapMemory()/AcpiOsUnmapMemory() (-> pmap_mapbios()/pmap_unmapbios())
for AcpiOsReadMemory() and AcpiOsWriteMemory(). Although they do not sound
too obvious, these functions are exclusively used to access memory mapped
IO in ACPICA.
According to ACPICA User Guide and Programmer Reference, the read data must
be zero extended to fill the 64-bit return value even if the bit width of
the location is less than 64.
- Return error when 64-bit access is requested as we do not support 64-bit
PCI register access (yet). XXX We may have to split it up into two 32-bit
accesses if it is really required.
According to ACPICA User Guide and Programmer Reference, the read data must
be zero extended to fill the 32-bit return value even if the bit width of
the port is less than 32.
- Remove 64-bit read/write from AcpiOsReadMemory() and AcpiOsWriteMemory().
These functions do not support 64-bit access (yet). Clean up style nits
and unnecessary bit masking while I am here.
Reported by: Liu, Jinsong (jinsong dot liu at intel dot com) via
Lin Ming (ming dot m dot lin at intel dot com) [1]
- The 6000 series WiMAX devices need a separate firmware.
- The b-gen devices are not hooked because the hardware revision type
is not know.
Obtained from: OpenBSD
MFC after: 1 week
r165114 added that code and that change ignored the same logic
committed in r135772. In addition, data FIFO protection should be
selectively enabled instead of applying to all PCIe devices.
While I'm here add BCM5785 to devices that do not require this
fix.
and remove a buffer overflow:
- Remove the array of per-type dispatch functions. Instead, pass each
structure to a single callback. The callback should check the type of
each table entry to take appropriate action. This matches the behavior
of other table walkers such as for the MP Table and MADT.
- Don't attempt to save an array of string pointers for each structure
entry. Instead, just skip the strings. If this code is reused to
provide a generic SMBIOS table walker in the future we could provide
a method that looks up a specific string N for a given structure record
instead of pre-populating an array of pointers. This fixes a buffer
overflow for structure entries with more than 20 strings.
PR: kern/148546
Reported by: Spencer Minear @ McAfee
MFC after: 3 days
The code in question verifies that all register write operations only change
bits that are defined (in the register definition file) for that effected
register. The bug effectively disabled this checking.
o Fix the check by testing the opcode against all supported read ("and" based)
operands.
o Add missing bit definitions to the aic7xxx and aic79xx register definition
files so that the warning (treated as a fatal error) does not spuriously
fire.
Reported by: Pawel Worach <pawel.worach@gmail.com>
MFC after: 1 week
All of the necessary wrmsr calls are now preceded by a rdmsr
and we leave the reserved bits alone.
Document the bits in the relevant registers for future reference.
Tested by: mdf
MFC after: 1 week
was missed in r209599.
Reported and tested by: Michael Moll
- Declare mpt_dma_buf_alloc() static just like mpt_dma_buf_free(), both are
used in mpt.c only.
Reviewed by: ken
MFC after: r209599
a packet has only a header in the first mbuf, the
checksum code will dereference a pointer into the
non-existing IP header. Do a check for the size and
pullup if needed. Thanks to Michael Tuexen for this
fix.
MFC: asap - should be in 8.1 IMHO
Do not grab lock while setting up interrupt, as it causes LOR with
allocation code. Instead make interrupt handler check that CAM bus
initialization completed before touching it.
While there, slightly improve attach errors handling.
Reported by: kib
The following systems are affected:
- MPC8555CDS
- MPC8572DS
This overhaul covers the following major changes:
- All integrated peripherals drivers for Freescale MPC85XX SoC, which are
currently in the FreeBSD source tree are reworked and adjusted so they
derive config data out of the device tree blob (instead of hard coded /
tabelarized values).
- This includes: LBC, PCI / PCI-Express, I2C, DS1553, OpenPIC, TSEC, SEC,
QUICC, UART, CFI.
- Thanks to the common FDT infrastrucutre (fdtbus, simplebus) we retire
ocpbus(4) driver, which was based on hard-coded config data.
Note that world for these platforms has to be built WITH_FDT.
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
start so we should adjust the mbuf if the driver is running in PIO mode.
Now it should work well with WPA authentication and association for LP
PHY devices.
Tested by: Warren Block <wblock at wonkity.com>
MFC after: 1 month
checksum offloading is enabled. The frame has a valid checksum
value so payload might be modified during TX checksum calculation.
Disable TX checksum offloading but give users chance to enable it
when they know their controller works without problems with TX
checksum offloading.
Reported by: Andrzej Tobola <ato <> iem dot pw dot edu dot pl>
- Run the adapter's tick at 1Hz and remove link state checks from it.
Instead, have each port check its link state. Delay the check so that
it takes place slightly after the driver is notified of a change in
link state. This is a cheap way to debounce these notifications if
many are received in rapid succession. POLL_LINK_1ST_TIME flag can
also be eliminated as a side effect of these changes.
- Do not reset the PHY when link goes down.
- Clear port's link_fault flag if the PHY indicates link is down.
- get_link_status_r should leave speed and duplex alone when link is down.
MFC after: 1 month
checksum is enabled in sge_init_locked().
While I'm here do not set RX checksum bits in RX descriptor
initialization. It is controller's job to set these bits.
Tested by: xclin <xclin <> cs dot nctu dot edu dot tw >
configuration to get IPv4 TSO work on BCM57780. While I'm here
apply the same fix to BCM5785 which shares similar hardware feature
of BCM57780. This change makes TSO work on BCM57780.
Tested by: Tong Liu <nemoliu <> gmail dot com>
it. This can happen in some cases when plugging in SD/SmartCard PC
Cards with empty slots. It is better to detect this bogosity, and
refuse to attach rather than panic with a division by zero (in one of
many places) down stream.
the core changes but left out the shared code, lol.
Well, and a couple fixes to the core... hopefully
this will all be complete now.
Happy happy joy joy :)
What this provides is support for the 'virtual function'
interface that a FreeBSD VM may be assigned from a host
like KVM on Linux, or newer versions of Xen with such
support.
When the guest is set up with the capability, a special
limited function 82576 PCI device is present in its virtual
PCI space, so with this driver installed in the guest that
device will be detected and function nearly like the bare
metal, as it were.
The interface is only allowed a single queue in this configuration
however initial performance tests have looked very good.
Enjoy!!
limit the advertised speed of an SFP+ to 1G, effectively
"forcing" link at that lower speed. It is off by default
and is enabled by sysctl dev.ix.0.force_gig=1, 0 will
set it back to the norm.
The mpt driver previously didn't report a 'maxio' size to CAM, and so the
da(4) driver limited I/O sizes to DFLTPHYS (64K) by default. The number
of scatter gather segments allowed, as reported to busdma, was
(128K / PAGE_SIZE) + 1, or 33 on architectures with 4K pages.
Change things around so that we wait until we've determined how many
segments the adapter can support before creating the busdma tag used for
buffers, so we can potentially support more S/G segments and therefore
larger I/O sizes.
Also, fix some things that were broken about the module unload path. It
still gets hung up inside CAM, though.
mpt.c: Move some busdma initialization calls in here, and call
them just after we've gotten the IOCFacts, and know how
many S/G segments this adapter can support.
mpt.h: Get rid of MPT_MAXPHYS, it is no longer used.
Add max_cam_seg_cnt, which is used to report our maximum
I/O size up to CAM.
mpt_cam.c: Use max_cam_seg_cnt to report our maximum I/O size to CAM.
Fix the locking in mpt_cam_detach().
mpt_pci.c: Pull some busdma initialization and teardown out and put
it in mpt.c. We now delay it until we know many scatter
gather segments the adapter can support, and therefore
how to setup our busdma tags.
mpt_raid.c: Make sure we wake up the right wait channel to get the
raid thread to wake up when we're trying to shut it down.
Reviewed by: gibbs, mjacob
MFC after: 2 weeks
This prevents a kernel fault by dividing with zero because the initial
rate was 0 and didn't be initialized.
Tested by: Warren Block <wblock at wonkity.com>
MFC after: 3 days
changed to RUN because ic->ic_newassoc isn't set anywhere now. In the
previous bwi_newassoc() is used to initialize AMRR rate routines.
Tested by: Warren Block <wblock at wonkity.com>
MFC after: 3 days
It has more features than acpi_aiboost(4) and it will eventually replace
acpi_aiboost(4).
Submitted by: Constantine A. Murenin <cnst at FreeBSD.org>
Reviewed by: freebsd-acpi, imp
MFC after: 1 month
FPU registers for copying. Remove the switch table and jumps from
bcopy/bzero/... to the actual implementation.
As a side-effect, i486-optimized bzero is removed.
Reviewed by: bde
Tested by: pho (previous version)
properly short terminate their transfers. This fixes a problem where input
appears several seconds late.
Reported by: Alexander Yerenkow
Submitted by: Hans Petter Selasky
HPET to steal IRQ0 from i8254 and IRQ8 from RTC timers. It can be suitable
for HPETs without FSB interrupts support, as it gives them two unshared
IRQs. It allows them to provide one per-CPU event timer on dual-CPU system,
that should be suitable for further tickless kernels.
To enable it, such lines may be added to /boot/loader.conf:
hint.atrtc.0.clock=0
hint.attimer.0.clock=0
hint.hpet.0.legacy_route=1
writing event timer drivers, for choosing best possible drivers by machine
independent code and for operating them to supply kernel with hardclock(),
statclock() and profclock() events in unified fashion on various hardware.
Infrastructure provides support for both per-CPU (independent for every CPU
core) and global timers in periodic and one-shot modes. MI management code
at this moment uses only periodic mode, but one-shot mode use planned for
later, as part of tickless kernel project.
For this moment infrastructure used on i386 and amd64 architectures. Other
archs are welcome to follow, while their current operation should not be
affected.
This patch updates existing drivers (i8254, RTC and LAPIC) for the new
order, and adds event timers support into the HPET driver. These drivers
have different capabilities:
LAPIC - per-CPU timer, supports periodic and one-shot operation, may
freeze in C3 state, calibrated on first use, so may be not exactly precise.
HPET - depending on hardware can work as per-CPU or global, supports
periodic and one-shot operation, usually provides several event timers.
i8254 - global, limited to periodic mode, because same hardware used also
as time counter.
RTC - global, supports only periodic mode, set of frequencies in Hz
limited by powers of 2.
Depending on hardware capabilities, drivers preferred in following orders,
either LAPIC, HPETs, i8254, RTC or HPETs, LAPIC, i8254, RTC.
User may explicitly specify wanted timers via loader tunables or sysctls:
kern.eventtimer.timer1 and kern.eventtimer.timer2.
If requested driver is unavailable or unoperational, system will try to
replace it. If no more timers available or "NONE" specified for second,
system will operate using only one timer, multiplying it's frequency by few
times and uing respective dividers to honor hz, stathz and profhz values,
set during initial setup.
measured interval as upper bound. It should be more precise then just
assuming hz/2. For idle CPU it should be quite precise, for busy - not
worse then before.
