interfaced via the PCM framework.
This manual page was obtained from NetBSD, and the required
changes were made to adapt it to our uaudio driver.
Pre-cursor review: joe@
* Add MLINKS for:
-> Soundblaster emu10k1(4) Driver [points to pcm(4)]
-> Avance Logic ALS400 Driver [points to pcm(4)]
We should not need separate manual page for each of these
drivers; instead, linking them to pcm(4) manual page is
simpler, and new device lists can be easily added to the
said manual page.
* While I am here, sort out mdoc(7) entries in ${MAN}.
list of supported controllers into a list.
Note that the 53C875A has not been included in the list of supported
devices, since this controller does not seem to be supported by the
version of the sym(4) driver currently in FreeBSD.
PR: docs/55557
Submitted by: Lukas Ertl <l.ertl@univie.ac.at> (original version)
MFC after: 1 week
53C875A omission reviewed by: silence from -scsi and groudier
o Remove entries for 1510, 152x and 1535. These are supported, for some value
of supported, by the aic driver.
o Add notes about 1542-CP being plug and play, but it can still conflict with
other resources because all the resources it uses are set with the onboard
BIOS.
dcons(4): very simple console and gdb port driver
dcons_crom(4): FireWire attachment
dconschat(8): User interface to dcons
Tested with: i386, i386-PAE, and sparc64.
FreeBSD supports. None of them support an alternate formats, except
the alpha (which prints extra register information).
# if we get a mips port, we can put the mips case back to document the
# actual behavior.
ebay. Also have notes for my recent experiences with 3com pcmcia
cards (mostly this or that doesn't work). Also look at the strings
that are claimed to be supported in the bus specific front ends. Note
that the 3C569* are CBUS.
has been supported for the last 10 months. [1]
- Make the device list compact, since it is getting rather large.
Reported by: David Magda <dmagda@magda.ca> [1]
MFC after: 2 weeks
which are based on the AR5212 and should just work (not verified).
Add Proxim Skyline 4032, the PCI version of th e4030.
Add revision suffix 'B' to D-Link DWL-G520/G650 entries, in order
to indicate that revision A1 cards are not supported by this driver
(both A1 and B1/B2 cards are sold in identical boxes).
Explicitly point out the existence of unsupported DWL-G520/G650
(rev. A1) cards in the CAVEATS section.
Approved by: sam
written by Stuart Walsh and Duncan Barclay (with some kibbitzing by
me). I'm checking it in on Stuart's behalf.
The BCM4401 is built into several x86 laptop and desktop systems. For the
moment, I have only enabled it in the x86 kernel config because although
it's a PCI device, I haven't heard of any standalone NICs that use it. If
somebody knows of one, we can easily add it to the other arches.
This driver uses register/structure data gleaned from the Linux
driver released by Broadcom, but does not contain any of the code
from the Linux driver itself. It uses busdma.
rl(4) driver and put it in a new re(4) driver. The re(4) driver shares
the if_rlreg.h file with rl(4) but is a separate module. (Ultimately
I may change this. For now, it's convenient.)
rl(4) has been modified so that it will never attach to an 8139C+
chip, leaving it to re(4) instead. Only re(4) has the PCI IDs to
match the 8169/8169S/8110S gigE chips. if_re.c contains the same
basic code that was originally bolted onto if_rl.c, with the
following updates:
- Added support for jumbo frames. Currently, there seems to be
a limit of approximately 6200 bytes for jumbo frames on transmit.
(This was determined via experimentation.) The 8169S/8110S chips
apparently are limited to 7.5K frames on transmit. This may require
some more work, though the framework to handle jumbo frames on RX
is in place: the re_rxeof() routine will gather up frames than span
multiple 2K clusters into a single mbuf list.
- Fixed bug in re_txeof(): if we reap some of the TX buffers,
but there are still some pending, re-arm the timer before exiting
re_txeof() so that another timeout interrupt will be generated, just
in case re_start() doesn't do it for us.
- Handle the 'link state changed' interrupt
- Fix a detach bug. If re(4) is loaded as a module, and you do
tcpdump -i re0, then you do 'kldunload if_re,' the system will
panic after a few seconds. This happens because ether_ifdetach()
ends up calling the BPF detach code, which notices the interface
is in promiscuous mode and tries to switch promisc mode off while
detaching the BPF listner. This ultimately results in a call
to re_ioctl() (due to SIOCSIFFLAGS), which in turn calls re_init()
to handle the IFF_PROMISC flag change. Unfortunately, calling re_init()
here turns the chip back on and restarts the 1-second timeout loop
that drives re_tick(). By the time the timeout fires, if_re.ko
has been unloaded, which results in a call to invalid code and
blows up the system.
To fix this, I cleared the IFF_UP flag before calling ether_ifdetach(),
which stops the ioctl routine from trying to reset the chip.
- Modified comments in re_rxeof() relating to the difference in
RX descriptor status bit layout between the 8139C+ and the gigE
chips. The layout is different because the frame length field
was expanded from 12 bits to 13, and they got rid of one of the
status bits to make room.
- Add diagnostic code (re_diag()) to test for the case where a user
has installed a broken 32-bit 8169 PCI NIC in a 64-bit slot. Some
NICs have the REQ64# and ACK64# lines connected even though the
board is 32-bit only (in this case, they should be pulled high).
This fools the chip into doing 64-bit DMA transfers even though
there is no 64-bit data path. To detect this, re_diag() puts the
chip into digital loopback mode and sets the receiver to promiscuous
mode, then initiates a single 64-byte packet transmission. The
frame is echoed back to the host, and if the frame contents are
intact, we know DMA is working correctly, otherwise we complain
loudly on the console and abort the device attach. (At the moment,
I don't know of any way to work around the problem other than
physically modifying the board, so until/unless I can think of a
software workaround, this will have do to.)
- Created re(4) man page
- Modified rlphy.c to allow re(4) to attach as well as rl(4).
Note that this code works for the sample 8169/Marvell 88E1000 NIC
that I have, but probably won't work for the 8169S/8110S chips.
RealTek has sent me some sample NICs, but they haven't arrived yet.
I will probably need to add an rlgphy driver to handle the on-board
PHY in the 8169S/8110S (it needs special DSP initialization).
