obtaining and releasing shared and exclusive locks. The algorithms for
manipulating the lock cookie are very similar to that rwlocks. This patch
also adds support for exclusive locks using the same algorithm as mutexes.
A new sx_init_flags() function has been added so that optional flags can be
specified to alter a given locks behavior. The flags include SX_DUPOK,
SX_NOWITNESS, SX_NOPROFILE, and SX_QUITE which are all identical in nature
to the similar flags for mutexes.
Adaptive spinning on select locks may be enabled by enabling the
ADAPTIVE_SX kernel option. Only locks initialized with the SX_ADAPTIVESPIN
flag via sx_init_flags() will adaptively spin.
The common cases for sx_slock(), sx_sunlock(), sx_xlock(), and sx_xunlock()
are now performed inline in non-debug kernels. As a result, <sys/sx.h> now
requires <sys/lock.h> to be included prior to <sys/sx.h>.
The new kernel option SX_NOINLINE can be used to disable the aforementioned
inlining in non-debug kernels.
The size of struct sx has changed, so the kernel ABI is probably greatly
disturbed.
MFC after: 1 month
Submitted by: attilio
Tested by: kris, pjd
that the driver clock is identical to the processor or bus clock.
This is the case for the PowerQUICC processor. When the clock is
high enough, overflows happen in the calculation of the time it
takes to send 1/10 of a character, used in delay loops. Fix the
overflows so as to fix bugs in the delay loops that can cause either
insufficient delays or excessive delays.
system devices (i.e. console, debug port or keyboard), don't stop
after the first match. Find them all and keep track of the last.
The reason for this change is that the low-level console is always
added to the list of system devices first, with other devices added
later. Since new devices are added to the list at the head, we have
the console always at the end. When a debug port is using the same
UART as the console, we would previously mark the "newbus" UART as
a debug port instead of as a console. This would later result in a
panic because no "newbus" device was associated with the console.
By matching all possible system devices we would mark the "newbus"
UART as a console and not as a debug port.
While it is arguably better to be able to mark a "newbus" UART as
both console and debug port, this fix is lightweight and allows
a single UART to be used as the console as well as a debug port
with only the aesthetic bug of not telling the user about it also
being a debug port.
Now that we match all possible system devices, update the rclk of
the system devices with the rclk that was obtained through the
bus attachment. It is generally true that clock information is
more reliable when obtained from the parent bus than by means of
some hardcoded or assumed value used early in the boot. This by
virtue of having more context information.
MFC after: 1 month
by driver backends to mark individual channels as enabled or not.
The default implementation of this method always mark channels as
enabled.
This method is currently not used, but is added with the PowerQUICC
in mind where the 2nd SCC channel can be disabled.
watchdog might hide the succesful arming of an earlier one. Accept that on
failing to arm any watchdog (because of non-supported timeouts) EOPNOTSUPP is
returned instead of the more appropriate EINVAL.
MFC after: 3 days
When submitting rx buffers and not using WC fifo, always replace the
invalid DMA address with the real one, otherwise allocation failures
could lead to the invalid DMA address being given to the NIC, and
that would cause the receive side to lockup.
it via pci_get_vpd_*() rather than always reading it for each device during
boot. I've left the tunable so that it can still be turned off if a device
driver causes a lockup via a query to a broken device, but devices whose
drivers do not use VPD (the vast majority) should no longer result in
lockups during boot, and most folks should not need to tweak the tunable
now.
Tested on: bge(4)
Silence from: jmg
one (hardware & global lock). This should address witness complaints that
a duplicate mutex is being acquired. Be sure to free the mutex to fix a
potential memory leak.
MFC after: 3 days
some devices (and not others). To get instances onto the iicbus, one
now needs hints or an identify routine. We also do not probe the bus
for devices because many iic devices cannot be safely probed (and when
they can, the probe order turns out to be somewhat difficult to get
right).
# I'm not 100% sure that the iicsmb removal is right. Please contact me if
# this causes difficulty.
- Change exca_activate_resource() to call BUS_ACTIVATE_RESOURCE() before
calling exca_(io|mem)_map() since the latter use rman_get_bus(tag|handle)
and the recent changes to nexus(4) mean that you need to activate a
resource before reading the bus tag and handle. This was true before,
but now the nexus(4) drivers on x86 and ia64 are more forceful about it.
Reviewed by: imp
DMA memory for a firmware load if it was the exact size needed, thus in the
common case the driver was constantly free'ing and reallocating the DMA
buffer and it would eventually begin to fail. With this fix, iwi0 reuses
the same buffer the entire time and no longer fails to load the firmware
after the machine has been up for a while.
MFC after: 1 week
