+ Add boatloads of KASSERTs and *really* check out more locking
issues (to catch recursions when we actually go to real locking
in CAM soon). The KASSERTs also caught lots of other issues like
using commands that were put back on free lists, etc.
+ Target mode: role setting is derived directly from port capabilities.
There is no need to set a role any more. Some target mode resources
are allocated early on (ELS), but target command buffer allocation
is deferred until the first lun enable.
+ Fix some breakages I introduced with target mode in that some commands
are *repeating* commands. That is, the reply shows up but the command
isn't really done (we don't free it). We still need to take it off the
pending list because when we resubmit it, bad things then happen.
+ Fix more of the way that timed out commands and bus reset is done. The
actual TMF response code was being ignored.
+ For SPI, honor BIOS settings. This doesn't quite fix the problems we've
seen where we can't seem to (re)negotiate U320 on all drives but avoids
it instead by letting us honor the BIOS settings. I'm sure this is not
quite right and will have to change again soon.
Radeon memmap code, which with a new DDX driver and DRI drivers should fix
long-term stability issues with Radeons. Also adds support for r200's
ATI_fragment_shader, r300 texrect support and texture caching fixes, i915
vblank support and bugfixes, and new PCI IDs.
The real problem was that ioctl handlers needed to call amr_wait_command()
with the list lock held. This not only solves the completion race, it also
prevents bounce buffer corruption that could arise from amr_start() being
called without the proper locks held.
Discussed with: ps
MFC After: 3 days
the completion of the command can occur before tsleep is called and
the command ends up blocking forever since the wakeup has already
been called.
Submitted by: ups
new chips and improves support for already supported ones.
Some details, important for future merges:
- if_em.c merged manually, viewing diff between new vendor
driver and previous one.
- if_em_hw.h dropped in from vendor, and then restored revisions
1.16, 1.17, 1.18.
- if_em_hw.c dropped in from vendor, and then two liner change made,
that restores support for two rare chips.
the NS8250 class driver. The UART has FIFOs if sc_rxfifosz>1, so
test for that instead.
While here properly initialize sc_rxfifosz and sc_txfifosz in the
case the UART doesn't have FIFOs.
There's something strange going on with async events. They seem
to be be treated differently for different Fusion implementations.
Some will really tell you when it's okay to free the request that
started them. Some won't. Very disconcerting.
This is particularily bad when the chip (FC in this case) tells you
in the reply that it's not a continuation reply, which means you
can free the request that its associated with. However, if you do
that, I've found that additional async event replies come back for
that message context after you freed it. Very Bad Things Happen.
Put in a reply register debounce. Warn about out of range context
indices. Use more MPILIB defines where possible. Replace bzero with
memset. Add tons more KASSERTS. Do a *lot* more request free list
auditting and serial number usages. Get rid of the warning about
the short IOC Facts Reply. Go back to 16 bits of context index.
Do a lot more target state auditting as well. Make a tag out
of not only the ioindex but the request index as well and worry
less about keeping a full serial number.
a different register shift and is fed by a different clock than
we use for UltraSPARC hardware. To deal with this, the regshft and
rclk fields in the class structure are removed and bus frontends
now pass the right regshft and rclk to the probe function where
they're put in the BAS and passed in to subordinate drivers.
--------------------
- Seal the fate of long standing memory leak (4 years, 7 months) during
pcm_unregister(). While destroying cdevs, scan / detect possible
children and free its SLIST placeholder properly.
- Optimize channel allocation / numbering even further. Do brute cyclic
checking only if the channel numbering screwed.
- Mega vchan create/destroy cleanup:
o Implement pcm_setvchans() so everybody can use it freely instead
of implementing their own, be it through sysctl or channel auto
allocation.
o Increase vchan creation/destruction resiliency:
+ it's possible to increase/decrease total vchans even during
busy playback/recording. Busy channel will be left alone, untouched.
Abusive test sample:
# play whatever...
#
while : ; do
sysctl hw.snd.pcm0.vchans=1
sysctl hw.snd.pcm0.vchans=10
sysctl hw.snd.pcm0.vchans=100
sysctl hw.snd.pcm0.vchans=200
done
# Play something else, leave above loop running frantically.
+ Seal another 4 years old bug where it is possible to destroy (virtual)
channel even when its cdevs being referenced by other process.
The "First Come First Served" nature of dsp_clone() is the main
culprit of this issue, and usually manifest itself as dangling
channel <-> process association. Ensure that all of its cdevs
are free from being referenced before destroying it (through
ORPHAN_CDEVT() macross).
All these fixes (including previous fixes) will be MFCed, later.
to avoid possible device unregister race (impossible to reproduce, yet
possible).
- Extra sanity check to ensure proper parent channel is being selected.
- Reset parent channel once all of its children gone.
controllers typically have multiple channels and support a number
of serial communications protocols. The scc(4) driver is itself
an umbrella driver that delegates the control over each channel
and mode to a subordinate driver (like uart(4)).
The scc(4) driver supports the Siemens SAB 82532 and the Zilog
Z8530 and replaces puc(4) for these devices.
