Such RAID controllers are actually just IDE controllers with a BIOS that
can create RAID volumes and write the configuration info to config blocks
on the disks. The BIOS can do I/O to these volumes, and the OS must
understand the config blocks and implement RAID in software in order to be
able to use these volumes.
Only SPAN (simple concatenation) and RAID0 are supported at this time,
and writing back config blocks is also not supported at this time. Currently,
only the Promise configuration scheme is supported, although supporting
the Highpoint scheme should not be too difficult.
In any case, this is sufficient to use the Promise RAID0 volume (thus
preserving the win2k AS installation) on this new Intel server I have.
Thanks to Soren Schmidt for doing the work in FreeBSD; it made this
task much easier. The config block parsing code is adapted from his
work.
IDE controllers, which are more-or-less compatible with the
AMD controllers.
XXX Need to determine the correct timing value for the nForce2
XXX at Ultra133, so we cap it at Ultra100, for now.
a series of Y2k-compliant multiplexed-bus RTC chips. At the lowest levels,
the DS1687 and successors are register-compatible with the MC146818(A) and
DS1287, but also provide Y2k-safe date storage and other extra bits, like a
silicon serial number and larger amounts of NVRAM.
allocate a static buffer, which is added at the end of short packets
to pad the buffer to ETHER_MIN_LEN - ETHER_CRC_LEN.
While I'm there fix 2 bugs:
in qeinit(), unload the right dmamap if bus_dmamap_load fails
in qestart, don't dmamap_load the mbuf if its len is 0.
Tested on simh-vax.
Add cpp definitions for the DMA control register fields needed for
5703/5704 configuration on PCI-X.
Add softc copy of internal"local control" register clobbered by reset.
quirk on all 5700 revision B devices. (These fixes have not been
tested against NetBSD recently; committing the fix and the enable separately
gives us flexibility about which fixes get pulled into the NetBSD-1.6 branch.)
* Add support for 5704C dual-channel chip with integral copper PHY (tested)
and 5704S dual-channel SERDES/TBI gbic (untested). Add PHY DSP patch
for 5704.
* Update PHY DSP-code patch for bcm5401 to match latest Linux driver.
* Add PHY DSP-code patch for 5703 (untested).
* Update onchip buffer tunables to recommended values from Linux drivers.
* Disable MWI access. This chip family cannot hanlde PCI stalls
in the middle of an MWI burst. The driver has heuristics to detect PCI
line size, but under load, some PCI bridges may force stalls which
the attach-time heruistics do not catch. Some PCI bridges never
do this, so maybe it should be a tunable option.
* bcm5700 rev Bx chips have a race condition, where updating the
Tx producer pointer goes un-noticed by the chip. Workaround is to
write the new producer-pointer value twice.
* bcm5700 chips rev Bx wedge up if given DMA descriptors of
eight bytes or less. Once hit, only reovery is a watchdog timeout/reset.
If the offending packet is retransmitted, the chip will wedge again...
Check for teeny fragments in a Tx request, and either fold the
teeny chunk residue into an adjacent mbuf, or m_dup the entire buffer.
(NB: quirk not yet enabled; in-place folding tested only on FreeBSD.)
* Add workaround for revision Bx bcm5700: chip bugs in decoding
of PCI register writes may leave the hardware in (partial) powersave state,
such that writes to "indirect" registers do not work.
Explicitly force chip into D0 state at attach time.
* Accessing PHY registers with the bge chip in autopoll mode, when
link-state is the process of changing, may cause the bge chip to
assert PCI errors. Workaround: when doing miibus register access,
save autopoll state, disable around access, and restore autopoll state.
NB: issuing PHY resets may give a window where the problem still occurs.
* Increase Tx interrupt-coalescing thresholds, to reduce Tx-done interrupts.
XXX should it be ETHER_MIN_LEN - ETHER_CRC_LEN ?
XXX2 we assume there are enouth space in the mbuf for the padding bytes.
But other places in the code assumes this already.
auich_set_rate() modified audio_params::sample_rate to actual
sample rate though auich_set_params() rejected sample rates
other than some specific rates. For example, setting 8000Hz
with auich_set_params() modified sample_rate to 7998Hz in the
case of overclocked AC97 codec, and calling auich_set_params()
again returned with EINVAL because sample_rate was 7998Hz and
auich_set_params() rejected 7998Hz.
For now, auich_set_params() never modify audio_params::sample_rate.
and the back end Bluetooth device driver. The device driver now
allocates a suitable buffer on behalf of the bthci driver, and bthci
fills the buffer before despatch.
This saves an ugly temporary allocation (in bthci) and memory copy (in
the USB driver) per write, and also works better with the
sockets-based interface I'm experimenting with.
Uploaded scripts work better if they are little endian, as the
card's engine expects, so convert to le first.
Also clean up attach routine a bit (use pa_id and PCI_REVISION
instead of fetching it ourselves).
This makes the driver work on my macppc G4, it can decode and
display video and tuner input. Sound does not seem to work, but
this may be my wonky formac bktr-for-macintosh card.
unless ACPI_FDC_DEBUG
array returned from _FDE contains UINT32 values, not UINT8; also change
the magic number '14' to '5 * sizeof(UINT32)' for clarity
remove XXX for the tape presence comment; it's Just Okay to not use the info
fdc_acpi_getknownfds(): if fdc_acpi_nvtotype() returns NULL, don't
attempt to attach the drive at all
XXX not tested
which is safer than the loop there used to be here.
wi_mwrite_bap: if wi_write_bap fails, don't keep on going: this
way you avoid writing garbage to the radio. First time you see
an odd-length mbuf, copy the remainder of the chain to sc_txbuf
and from there to the MAC. This way, you do not read an mbuf past
the end of its data (occasionally you will cross a page doing
that!) and you avoid expensive, excess seeks in the radio's own
buffer chain.
wi_rx_intr: clamp the frame length told to us by the driver to the
most bytes we can fit in our mbuf cluster.
I am still getting e-mails from my testers telling me how much
better this makes things.
XXX - need to move this (as well as the equivalent sparc stuff added
recently) outa here into sbus_machdep or something. We should not need
to know details of the actual bus_space implementation here.
* Improve acpi interrupt fixup a bit
* Source is an array, don't compare it to NULL, instead
look for an empty string to denote a link-device-less
entry.
* For root PCI busses, try to use the _BBN method to get
numbering right.
* Add acpi_md_callback() function for MD handling after the init,
but before * at acpi probing.
actually functional driver. It provides a local HCI interface to the
HCI-over-USB interface on standards-compliant Bluetooth USB devices.
Currently this device can be attached to the bthci driver for direct user-land
access to the device.
actually functional driver. It provides user access through a character
device to a Bluetooth HCI capable driver.
The device interface is the same (open/read/write) as the RAW HCI socket
(socket/recv/send) interface provided by the Linux and FreeBSD netgraph
Bluetooth stacks. This allows a (very small) number of diagnostic programs to
be trivially ported and actually work.
temperature to sysmon; in the near future we should be associating devices
in this thermal zone with this device so we can do active or passive
cooling on a zone-by-zone basis.
- Windows put the chip in suspended mode, make sure we unsuspend
it. 1.43, by Takefumi SAYO <stake@po.shiojiri.ne.jp>
- Detect the revision of the Rhine chip we're using, and force reset
when the chip supports it. 1.65, by silby@freebsd.org
jmcneill