can see the results of SPI negotiation w/o being overwhelmed
with other crap).
+ For U320 devices, check against both Settings *and* DV flags before
deciding whether we need to skip actual SPI settings for a device.
+ Go back to creating a 'physical disk' side of a raid/passthru bus that
is limited to the number of maximum physical disks. Actually, this isn't
probably *quite* right yet for one RAID volume, and if we ever end up
with finding a device that supports more than one RAID volume (not likely),
it probably won't quite be right either.
The problem here is that the creating of this 'physical' passthru sim is
just a cheap way to leverage off the CAM midlayer to do our negotiation
for us on the subentities that make up a RAID volume. It almost causes
more trouble than it is worth because we have to remember which side
we're talking to in terms of forming commands and which target ids are
real and so on. Bleah.
+ Skip trying to actually do SPI settings for the RAID volumes on the
real side of the raid/passthru bus pair- this just confuses the issue.
The underlying real physical devices will have the negotiation performed
and the Raid volume will inherit the resultant settings. At the sime time,
non-RAID devices can be on the same real bus, so *do* perform negotiations
with them.
+ At the end of doing all of the settings twiddling, *ahem*, remember to
go update the settings on the card itself (dunno how this got nuked).
At this point, negotiations *seem* to be being done (again) correctly for
both RAID volumes and their subentities. And they seem to be *mostly*
now right for other non-RAID entities on the same bus (I ended up with
3 out of 8 other disks still at narror/async- haven't the slightest
idea why yes).
Finally, negotiations on a normal bus seem to work (again).
There's still more work coming into this area, but we're in the
final stretch.
the passed target id is one of the RAID VolumeID. This result
is used to decide whether to try and do actual SPI negotiations
on the real side of the raid/passthru bus pair. The reason we
check this is that we can have both RAID volumes and real devices
on the same bus.
USBD_FORCE_SHORT_XFER to ensure that we actually build and execute
a transfer. This means that the various alloc_sqtd_chain functions
will always construct a transfer, so it is safe to modify the
allocated descriptors on return. Previously there were cases where
a zero length transfer would cause a NULL dereference.
Reported by: bp
- Reduce the number of RX and TX buffers bfe uses so that it does not use more
bounce buffers than busdma is willing to allow it to use
See if_bfe.c for comments on why this is now safe to do.
Also use BUS_DMA_ALLOCNOW to be on the safe side.
2. Look for the Descriptor Error, and Descriptor Protocol Error flags from
the card, and down the interface if we detect either.
#1 (along with fixes to busdma) makes sure that this card works in all
memory situations. Prior to this change, it was just luck that 512 count
RX/TX lists were properly aligned. Now we can use any size of RX/TX lists
and still have them properly aligned.
#2 ensures that we don't get into an endless interrupt storm if busdma fails
us. Descriptor Protocol Error would occur if we misaligned the TX/RX rings,
and Descriptor Error would occur if we tried to give the card descriptors
or rings with addresses > 1G. Trying to reinitialize the card isn't going
to fix these errors, hence we don't try.
host controllers to avoid the need to allocate any multi-page
physically contiguous memory blocks. This makes it possible to use
USB devices reliably on low-memory systems or when memory is too
fragmented for contiguous allocations to succeed.
The USB subsystem now uses bus_dmamap_load() directly on the buffers
supplied by USB peripheral drivers, so this also avoids having to
copy data back and forth before and after transfers. The ehci and
ohci controllers support scatter/gather as long as the buffer is
contiguous in the virtual address space. For uhci the hardware
cannot handle a physical address discontinuity within a USB packet,
so it is necessary to copy small memory fragments at times.
lost one set to a peninsula power failure last night. After
this, I can see both submembers and the raid volumes again,
but speed negotiation is still broken.
Add a mpt_raid_free_mem function to centralize the resource
reclaim and fixed a small memory leak.
Remove restriction on number of targets for systems with IM enabled-
you can have setups that have both IM volumes as well as other devices.
Fix target id selection for passthru and nonpastrhu cases.
Move complete command dumpt to MPT_PRT_DEBUG1 level so that just
setting debug level gets mostly informative albeit less verbose
dumping.
but large parts are rewritten by matk and tanimura.
This is old code, it's not maintained since 2003. We also don't have a
maintainer for this! Yuriy Tsibizov took it and uses it in his emu10kx
driver. Since the emu10kx driver will enter the tree "soon" (some bugs
have to be fixed after Yuriy return from his holidays), I add it here
already.
This also contains some changes to emu10k1 and cmi, so if you're lucky,
you can now make some kind of use of midi with those soundcards.
To all those poor souls which don't have such a card: feel free to send
patches, we don't have a maintainer for this.
To those which miss a specific feature in the midi code: feel free to
submit patches, we don't have a maintainer for this.
Oh, did I already told that it would be nice if someone would take care
of it? Maintainer with midi equipment wanted! :-)
If you get LOR's, submit a PR and notify multimedia@ please. If you get
panics, submit a PR with a backtrace (compile the sound system into your
kernel instead of using modules in this case) and notify multimedia@
please.
Written by: matk, tanimura
Submitted by: "Yuriy Tsibizov" <Yuriy.Tsibizov@gfk.ru>
Based upon: code from NetBSD
but large parts are rewritten by matk and tanimura.
This is old code, it's not maintained since 2003. We also don't have a
maintainer for this! Yuriy Tsibizov took it and uses it in his emu10kx
driver. Since the emu10kx driver will enter the tree "soon" (some bugs
have to be fixed after Yuriy return from his holidays), I add it here
already.
This also contains some changes to emu10k1 and cmi, so if you're lucky,
you can now make some kind of use of midi with those soundcards.
To all those poor souls which don't have such a card: feel free to send
patches, we don't have a maintainer for this.
To those which miss a specific feature in the midi code: feel free to
submit patches, we don't have a maintainer for this.
Oh, did I already told that it would be nice if someone would take care
of it? Maintainer with midi equipment wanted! :-)
If you get LOR's, submit a PR and notify multimedia@ please. If you get
panics, submit a PR with a backtrace (compile the sound system into your
kernel instead of using modules in this case) and notify multimedia@
please.
Written by: matk, tanimura
Submitted by: "Yuriy Tsibizov" <Yuriy.Tsibizov@gfk.ru>
Based upon: code from NetBSD
This used to make syscons switch to vty0 when we entered DDB but this
was lost in the KDB shuffle. We may want to bring it back down the road
but it should be done by calling cn_init_t/cn_term_t instead, possibly
with a flag argument saying "Debugger!"
other timeouts could not happen while suspending, including timeouts
for things like msleep. This caused the system to hang on suspend
when the cbb was enabled, since its suspend path powered down the
socket which used a timeout to wait for it to be done.
APM now creates a thread when it is enabled, and deletes the thread
when it is disabled. This thread takes the place of the timeout by
doing its polling every ~.9s. When the thread is disabled, it will
wakeup early, otherwise it times out and polls the varius things the
old timeout polled (APM events, suspend delays, etc).
This makes my Sony VAIO 505TS suspend/resume correctly when APM is
enabled (ACPI is black listed on my 505TS).
This will likely fix other problems with the suspend path where
drivers would sleep with msleep and/or do other timeouts. Maybe
there's some special case code that would use DELAY while suspending
and msleep otherwise that can be revisited and removed.
This was also tested by glebius@, who pointed out that in the patch I
sent him, I'd forgotten apm_saver.c
MFC After: 3 weeks
was done, I believe, to work around some cards having issues in the
suspend case. I think that this helped my Sony VAIO TS505 work better
when it had certain wireless cards in it and I did a apm -z. I've not
tested suspend/resume on other laptops in a long time, so I hope this
doesn't cause greif. Please let me know if it does.
of cases where we didn't take out the lock before setting or clearing
a bit. This apparently can lead to a race at kldunload time (at least
on my Turion64 laptop, never saw it on my Sony Vaio).
EHCI spec for linking in new qTDs into an asynchronous QH. This
requires that there is a qTD marked as not active and not halted
at the start of the QH's list, and the hardware will know to re-fetch
the qTD on each pass rather than just looking at the overlay qTD:
"The host controller must be able to advance the queue from the
Fetch QH state in order to avoid all hardware/software race
conditions. This simple mechanism allows software to simply link
qTDs to the queue head and activate them, then the host controller
will always find them if/when they are reachable."
This is achieved by keeping an "inactivesqtd" entry on the QH list,
and re-using it each time as the start of the next transfer, and
allocating a new qTD to become the next inactivesqtd. Then a new
transfer can be activated by just setting its "active" flag, which
avoids all the previous messing with overlay qTD state in
ehci_set_qh_qtd().
before starting exploring (4 seconds), and extend the wait period
if new USB buses are attached while waiting.
This works around a problem seen when there is more than one EHCI
controller in the system and you kldload usb.ko after the system
has booted. The problem is that usb.ko contains 3 separate PCI
drivers which get initialised one by one (uhci, ohci, ehci), and
when each driver is initialised, all PCI buses are re-probed after
just the addition of that driver. This means that there can be a
significant delay between the attaching of a companion controller
and the subsequent EHCI attach, so it is possible for the companion
controller's USB 1.x bus to be scanned before the EHCI driver gets
a chance to check if there is really a USB 2.x device connected.
- Rename REG_DL to REG_DLL and REG_DLH.
- Always treat DLL and DLH as two separate 8-bit registers instead of one
16-bit register.
Additionally, remove the probe for the high 4 bits of IER being 0 and don't
assume we can always read/write 0 to/from those bits.
These changes allow uart(4) to drive the UARTs on the Intel XScale PXA255.
Reviewed by: marcel
- Skip PnP devices as some wedge when trying to probe them as C-NET(98)S.
This fix makes le(4) actually work with the C-NET(98)S.
Reviewed by: marius
Tested by: Watanabe Kazuhiro < CQG00620 at nifty dot ne dot jp >
Be cognizant as to whether we're running 2KLogin f/w in target mode and
do the appropriate loopid load based upon that.
Do a first cut (seems to work, at least for amd64) at 64 bit target
mode for fibre channel cards. We could probably also do it for SPI
cards, but that's not supported right now.
- Linux ioctl support, with the other Linux changes MegaCli
will run if you mount linprocfs & linsysfs then set
sysctl compat.linux.osrelease=2.6.12 or similar. This works
on i386. It should work on amd64 but not well tested yet.
StoreLib may or may not work. Remember to kldload mfi_linux.
- Add in AEN (Async Event Notification) support so we can
get messages from the firmware when something happens.
Not all messages are in defined in event detail. Use
event_log to try to figure out what happened.
- Try to implement something like SIGIO for StoreLib. Since
mrmonitor doesn't work right I can't fully test it. StoreLib
works best with the rh9 base. In theory mrmonitor isn't
needed due to native driver support of AEN :-)
Now we can configure and monitor the RAID better.
Submitted by: IronPort Systems.
full, kick the binary blob to force it to complete any pending tx
completions.
- In the watchdog routine, only reset the chip if the blob doesn't complete
any pending tx completions rather than requiring it to complete all of
the pending tx completions.
Submitted by: Nathan Whitehorn <nathanw@uchicago.edu>
MFC after: 2 weeks
lnc(4) on PC98 and i386. The ISA front-end supports the same non-PNP
network cards as lnc(4) did and additionally a couple of PNP ones.
Like lnc(4), the C-bus front-end of le(4) only supports C-NET(98)S
and is untested due to lack of such hardware, but given that's it's
based on the respective lnc(4) and not too different from the ISA
front-end it should be highly likely to work.
- Remove the descriptions of le(4), which where converted from lnc(4),
from sys/i386/conf/NOTES and sys/pc98/conf/NOTES as there's a common
one in sys/conf/NOTES.
still should return BUS_PROBE_LOW_PRIORITY instead of BUS_PROBE_DEFAULT
in order to give pcn(4) a chance to attach in case it probes after le(4).
- Rearrange the code related to RX interrupt handling so that ownership of
RX descriptors is immediately returned to the NIC after we have copied
the data of the hardware, allowing the NIC to already reuse the descriptor
while we are processing the data in ifp->if_input(). This results in a
small but measurable increase in RX throughput.
As a side-effect, this moves the workaround for the LANCE revision C bug
to am7900.c (still off by default as I doubt we will actually encounter
such an old chip in a machine running FreeBSD) and the workaround for the
bug in the VMware PCnet-PCI emulation to am79000.c, which is now also
only compiled on i386 (resulting in a small increase in RX throughput on
the other platforms).
- Change the RX interrupt handlers so that the descriptor error bits are
only check once in case there was no error instead of twice (inspired
by the NetBSD pcn(4), which additionally predicts the error branch as
false).
- Fix the debugging output of the RX and TX interrupt handlers; while
looping through the descriptors print info about the currently processed
one instead of always the previously last used one; remove pointless
printing of info about the RX descriptor bits after their values were
reset.
- Create the DMA tags used to allocate the memory for the init block,
descriptors and packet buffers with the alignment the respective NIC
actually requires rather than using PAGE_SIZE unconditionally. This might
as well fix the alignment of the memory as it seems we do not inherit
the alignment constraint from the parent DMA tag.
- For the PCI variants double the number of RX descriptors and buffers
from 8 to 16 as this minimizes the number of RX overflows im seeing with
one NIC-mainboard combination. Nevertheless move reporting of overflows
under debugging as they seem unavoidable with some crappy hardware.
- Set the software style of the PCI variants to ILACC rather than PCnet-PCI
as the former is was am79000.c actually implements. Should not make a
difference for this driver though.
- Fix the driver name part in the MODULE_DEPEND of the PCI front-end for
ether.
- Use different device descriptions for PCnet-Home and PCnet-PCI.
- Fix some 0/NULL confusion in lance_get().
- Use bus_addr_t for sc_addr and bus_size_t for sc_memsize as these are
more appropriate than u_long for these.
- Remove the unused LE_DRIVER_NAME macro.
- Add a comment describing why we are taking the LE_HTOLE* etc approach
instead of using byteorder(9) functions directly.
- Improve some comments and fix some wording.
MFC after: 2 weeks
Current code does not report link loss correctly - when link goes down,
mii_phy_tick() will notice that with up to mii_anegticks delay.
If link goes up during this delay then link flapping will be unnoticed
by driver.
2) mii_phy_add_media(): initialize sc->mii_anegticks for 10/100 media
3) Use MII_ANEGTICKS/MII_ANEGTICKS_GIGE defines instead of hardcoded values.
Approved by: glebius (mentor)
MFC after: 1 month
divisor. This allows us to set the line speed to the maximum
of 1/4 of the device clock.
o Disable the baudrate generator before programming the line
settings, including baudrate, and enable it afterwards.
was not checked at all. There is only one case when sc_clean_up()
can fail, because of wait_scrn_saver_stop(), but it doesn't hurt
to check anyway.
Reviewed by: rodrigc
Found by: Coverity Prevent
If the embedded controller exists before the sysresource devices, for
example, it will be attached first. Instead, let the normal device
order function work as we first desired. [1]
There still remained a problem where we couldn't allocate resources in
acpi0 that were passed up by the sysresource pseudo-devices. These
devices had to probe/attach first to give their resources to acpi, then
acpi would allocate them before probing/attaching other devices. To
work around this, we attach them from acpi_sysres_alloc(). A better
approach would be to implement multi-pass probe/attach in newbus but
that's a much bigger task.
Suggested by: jhb [1]
Hardware from: Centaur Technologies
MFC after: 1 week
to ensure we match the type signature; we cannot assume HAL_BUS_TAG
and HAL_BUS_HANDLE correspond to bus_space_tag_t and bus_space_handle_t
(should probably do this for HAL_SOFTC too but leave that for now)
MFC after: 1 month
- Fix bfe_encap so that it will pass the address of the mbuf back up to its
caller if/when it modifies it, as it does when doing a m_defrag on a mbuf chain.
- Make sure to unload the dmamap for ALL fragments of a packet, not just the first
- Use BUS_DMA_NOWAIT for all bus_dmamap_load calls so that the allocation of the
map is not delayed - this driver is not set up to handle such delays.
- Reduce the number of RX and TX buffers bfe uses so that it does not use more
bounce buffers than busdma is willing to allow it to use
With these changes, the driver now works properly for a user with a 2GB system,
and it also works on my system when the acceptable address range is lowered to 128MB.
Previously, both of these setups would act up after a few minutes of activity.
from the amr_linux. This simplifies the amr_linux shim and puts the
smarts into amr.c.
I tested this with 2 amr controllers in one box. It seems to work
okay with them.
o Properly use rman(9) to manage resources. This eliminates the
need to puc-specific hacks to rman. It also allows devinfo(8)
to be used to find out the specific assignment of resources to
serial/parallel ports.
o Compress the PCI device "database" by optimizing for the common
case and to use a procedural interface to handle the exceptions.
The procedural interface also generalizes the need to setup the
hardware (program chipsets, program clock frequencies).
o Eliminate the need for PUC_FASTINTR. Serdev devices are fast by
default and non-serdev devices are handled by the bus.
o Use the serdev I/F to collect interrupt status and to handle
interrupts across ports in priority order.
o Sync the PCI device configuration to include devices found in
NetBSD and not yet merged to FreeBSD.
o Add support for Quatech 2, 4 and 8 port UARTs.
o Add support for a couple dozen Timedia serial cards as found
in Linux.
OS dependent layer. Thus, the watchdog timer can go off when the tx
engine is working fine but the OS dependent layer just hasn't been called
to cleanup finished tx transactions. To workaround this, when the watchdog
fires, poke the binary blob to force it to flush any pending tx
completions. If this drops the pending tx count to zero then just return
without logging a message or resetting the chip.
This reportedly fixes the 'device timeout()' errors with at least several
NF4 nve(4) parts.
Submitted by: Nathan Alexander Whitehorn <nathanw@uchicago.edu> (code)
Submitted by: dg (inspiration for comment and explanation)
MFC after: 1 week
POSTWRITE to POSTREAD.
No guarantee that all busdma is usage is perfect, but this change (in
addition to scott's last two commits) makes if_bfe work with > 1GB of
memory in my laptop.
OpenBSD changes. With these changes, PHY part of the driver becomes
functional (it senses media changes and negotiates speed just fine),
previously it just hang with no PHY message, but no data goes through
interface (error message is "can not stop transfer of Tx/Rx descriptor).
Hopefully somebody with more clue/free time will be able to pick up
after me.
Changelog towards if_iwi.c 1.26 (some changes have been committed separately
in the mean time):
- add led support
- add firmware loading on demand
- auto-restart firmware when it crashes
- serialize operations sent to the firmware to reduce firmware crashes
- add power save operation support
- remove incorrect specification of tx power control capability
- add radio on/off switch support
- improve net80211 state machine operation
- recognize and handle beacon miss
- handle authentication and association failures better
- add shared key authentication
- fix ibss mode (many changes)
- fix wme (many changes)
- correct radiotap support (many changes)
- correct bus dma setup of s/g
- correct various locking issues
- fix monitor mode
- fix scanning (many changes)
- recover from wedged scan requests
- respect active channel list
- eliminate cases where interface was marked down on error
- don't treat parity errors as fatal
- reclaim mgt frames immediately from tx queue
- correct interrupt handling, ack early (from NetBSD)
- fix short/long preamble handling
Committed with RELENG_6 compat #if's, should compile in RELENG_6. Requires
net/iwi-firmware-kmod to function.
Much work done by: sam
Tested by: many (freebsd-net), ume, luigi
MFC after: 4 weeks
This driver was generously developed and donated by Highpoint.
It is enabled for i386 only at the moment. I will enable it for amd64
shortly.
Obtained from: HighPoint Technologies, Inc.
- MPSAFE. No more recursive lock required.
- bus_dma(9) conversion. I think it should work on all architectures.
- optimized Rx handler for each normal and jumbo frames. Previously
sk(4) used jumbo frame management code to handle normal sized
frames. As the handler needs an additional lock to protect jumbo
frame management structure from races, it used two lock operations
for each received packet. Now sk(4) uses single lock operation for
normal frame.(Jumbo frame still needs two lock operations as before.)
The hardware supports DMA scatter operations for Rx descriptors such
that it's possible to take advantagee of m_cljget(9) for jumbo frames.
However, due to a unknown reasons it resulted in poor performance on
sparc64. So I dropped m_cljget(9) approach. This should be revisited
since it would reduce one lock operation for jumbo frame handling.
- Tx TCP/Rx IP checksum offload support. According to the data sheet
of SK-NET GENESIS the hardware supports Rx IP/TCP/UDP offload.
But I couldn't make it work on my Yukon hardware. So Rx TCP/UDP was
disabled at the moment. It seems that newer Yukon chips can support
Tx UDP checksum offload too. But I need more documentation first.
- Added more wait time in reading VPD data. It seems that ASUS LOM
takes a very long time to respond VPD read signal.
- Added an additional lock for MII register access callbacks.
- Added more strict received packet validation routine. Previously it
passed corrupted packets to upper layers under certain conditions.
- A new function sk_yukon_tick() to handle auto-negotiation properly.
- Interrupt handler now checks shared interrupt source and protects
the interrupt handler from NULL pointer dereference which was caused
by odd status word value. The status word can returns 0xffffffff if
cable is unplugged while Rx/Tx/auto-negotiation is in progress.
- suspend/resume support(not tested).
- Added Rx/Tx FIFO flush routine for Yukon
- Activate Tx descriptor poll timer in order to protect possible loss
of SK_TXBMU_TX_START command. Previously the driver continuously issued
SK_TXBMU_TX_START when it notices pending Tx descriptors not processed
yet in interrupt handler. That approach would add additional PCI
write access overhead under high Tx load situations and it might fail
if the first SK_TXBMU_TX_START was lost and no interrupt is generated
from the first SK_TXBMU_TX_START command.
- s/printf/if_printf/, s/printf/device_printf/, Axe sk_unit in softc.
- Setting multicast/station address is now safe on strict-alignment
architectures.
- Fix long standing bug in VLAN header length setup.
- Added/corrected register definitions for Yukon.
(Register information from Linux skge driver.)
- Added Rx status definition for Marvell Yukon/XaQti XMAC.
(Rx status register information from Linux skge driver.)
- Update if_oerrors if we encounter watchdog error.
- callout(9) conversion
Special thanks to jkim who let me know RX status differences between
Yukon and XaQti XMAC.
It seems that there is still occasional watchdog timeout error but I
couldn't reproduce it and need more information to analyze it from
users.
Tested by: bz(amd64), me(i386, sparc64), current ML
Frank Behrens frank ! pinky ( sax $ de
Lower the minimum for memory mapped I/O from 32 bytes to 16 bytes.
This fixes bus enumeration on ia64 now that the Diva auxiliary
serial port is attached to.
channel number since we're not ready at the net80211 layer to deal with them;
note this mapping has to match what's done in ieee80211_mhz2ieee
MFC after: 3 days
controller as we use in boot blocks (querying status register until
bit 1 goes off). If that doesn't happed during reasonable period assume
that the hardware doesn't have AT-style keyboard controller. This makes
FreeBSD working almost OOB on MacBook Pro (still there are issues with
putting second CPU core on-line, but since installation CD comes with
UP kernel with this change one should be able to install FreeBSD without
playing tricks with hints). Other legacy-free hardware (e.g. IBM NetVista
S40) should benefit from this as well, but since I don't have any I can't
verify.
It should make no difference on the ordinary i386 hardware (since in
that case that hardware already would be having an issues with A20
routines in boot blocks). I don't know much about AT-style keyboard
controller on other platforms (and don't have dedicated access to one),
therefore, the code is restricted to i386 for now. I suspect that amd64
may need this as well, but I would rather leave this decision to someone
who knows better about the platform(s) in question.
I have tested this change on as many "ordinary i386 boxes" as I can get
my hands on, and it doesn't create any false negatives on hardware with
AT-style keyboard present.
MFC after: 1 month
This allows one to change the behavior of the driver pre-boot.
NOTE: This patch was made for DragonFly BSD by Sepherosa Ziehau.
PR: kern/94833
Submitted by: Devon H. O'Dell
Obtained from: DragonFly
MFC after: 1 month
end for isa(4).
o Add a seperate bus frontend for acpi(4) and allow ISA DMA for
it when ISA is configured in the kernel. This allows acpi(4)
attachments in non-ISA configurations, as is possible for ia64.
o Add a seperate bus frontend for pci(4) and detect known single
port parallel cards.
o Merge PC98 specific changes under pc98/cbus into the MI driver.
The changes are minor enough for conditional compilation and
in this form invites better abstraction.
o Have ppc(4) usabled on all platforms, now that ISA specifics
are untangled enough.
A slight difference of this chip from its previous siblings is that
it need a gentle "wake up" on every (full) DMA buffer completion to
avoid stalled interrupt handler.
Thanks to George Hartzell for permission on doing remote debugging.
Prime MFC candidate for 6.1-RELEASE. Please reply to this commit if
there are any objections (so I won't bug re@), since the changes
are too small and only specific to VT8251.
PR: i386/95949
Tested by: [1] George Hartzel
myself (remotely)
MFC after: 3 days
[1] http://lists.freebsd.org/pipermail/freebsd-multimedia/2006-April/004003.html
Pull in some target mode changes from a private branch.
Pull in some more RELENG_4 compilation changes.
A lot of lines changed, but not much content change yet.
