Collect together the components of several drivers and export eisa from
the i386-only area (It's not, it's on some alphas too). The code hasn't
been updated to work on the Alpha yet, but that can come later.
Repository copies were done a while ago.
Moving these now keeps them in consistant place across the 4.x series
as the newbusification progresses.
Submitted by: mdodd
packets into a single buffer, and set the DC_TX_COALESCE flag for the
Davicom DM9102 chip. I thought I had escaped this problem, but... This
chip appears to silently corrupt or discard transmitted frames when
using scatter/gather DMA (i.e. DMAing each packet fragment in place
with a separate descriptor). The only way to insure reliable transmission
is to coalesce transmitted packets into a single cluster buffer. (There
may also be an alignment constraint here, but mbuf cluster buffers are
naturally aligned on 2K boundaries, which seems to be good enough.)
The DM9102 driver for Linux written by Davicom also uses this workaround.
Unfortunately, the Davicom datasheet has no errata section describing
this or any other apparently known defect.
Problem noted by: allan_chou@davicom.com.tw
makes it a little easier to notice that parity checking an 8bit sram
isn't working.
Turn on scb and internal data-path parity checking for all pci chips types.
We were only doing this for ultra2 chips.
After clearing the parity interrupt status, clear the BRKADRINT. This
avoids seeing a bogus BRKADRINT interrupt after external SCB probing
once normal interrupts are enabled.
controllers will run at U2 speeds until I can complete the U160 support
for this driver.
Correct a termination buglet for the 2940UW-Pro.
Be more paranoid in how we probe and enable external ram, fast external
ram timing and external ram parity checking. We should now work on
20ns and 8bit SRAM parts.
Perform initial setup for the DT feature on cards that support it.
Factorize and clean up code. Use tables where it makes sense, etc.
Add some delays in dealing with the board control logic. I've never
seen this code fail, but with the ever increasing speed of processors,
its better to insert deterministic delays just to be safe. This stuff
is only touched during probe and attach, so the extra delay is of no
concern.
driver seems relatively functional, but could use some souping up,
particularly in the performance area. This has both NetBSD and FreeBSD
attachment code and a fair amount of effort has been put into making
it easy to port to different *BSD platforms.
The basic design is a one tfd per mbuf transmit (with no transmit
related interrupts- tfds are gc'd as needed). The receive ring
uses a 2K buffer per rfd with a +2 byte adjust for the ethernet
header (so the payload is aligned). There's support that *almost*
works for doing large packets- the rfd chaining code works, but there's
some problem with getting good checksums at the IP reassembly level
(ditto for doing short tfd's too).
The chip has support for TCP checksums insertion for transmit and
TCP checksum calculation on receive (for both you have to do some
appropriate backoff && twiddling), but this isn't in place.
This is nearly entirely reverse engineered from the released Intel
driver, so there's a lot of "We have to do this but do not know why"
stuff. There is somebody who has the chip specs who works in FreeBSD
but they're being a bit standoffish about even sharing hints which
is somewhat annoying. It's also apparent that all I had to work with
were the first rev boards.
This driver has been lightly tested on intel && alpha, but only
point-to-point. There may be some issues with switches- use of
boot time environment variables that override EEPROM settings
(e.g., 'set wx_ilos=1' which inverts the sense of optical signal
loss) may help with this.
I had this out for review for three weeks, and nobody said anything
negative or positive, ergo, this checkin has no 'reviewed by' field
which I would have preferred.
down, the dc driver and receiver can fall out of sync with one another,
resulting in a condition where the chip continues to receive packets
but the driver never notices. Normally, the receive handler checks each
descriptor starting from the current producer index to see if the chip
has relinquished ownership, indicating that a packet has been received.
The driver hands the packet off to ether_input() and then prepares the
descriptor to receive another frame before moving on to the next
descriptor in the ring. But sometimes, the chip appears to skip a
descriptor. This leaves the driver testing the status word in a descriptor
that never gets updated. The driver still gets "RX done" interrupts but
never advances further into the RX ring, until the ring fills up and the
chip interrupts again to signal an error condition. Sometimes, the
driver will remain in this desynchronized state, resulting in spotty
performance until the interface is reset.
Fortunately, it's fairly simple to detect this condition: if we call
the rxeof routine but the number of received packets doesn't increase,
we suspect that there could be a problem. In this case, we call a new
routine called dc_rx_resync(), which scans ahead in the RX ring to see
if there's a frame waiting for us somewhere beyond that the driver thinks
is the current producer index. If it finds one, it bumps up the index
and calls the rxeof handler again to snarf up the packet and bring the
driver back in sync with the chip. (It may actually do this several times
in the event that there's more than one "hole" in the ring.)
So far the only card supported by if_dc which has exhibited this problem
is a LinkSys LNE100TX v2.0 (82c115 PNIC II), and it only seems to happen
on one particular system, however the fix is general enough and has low
enough overhead that we may as well apply it for all supported chipsets.
I also implemented the same fix for the 3Com xl driver, which is apparently
vulnerable to the same problem.
Problem originally noted and patch tested by: Matt Dillon
probes are at the 'chip' level and will get overridden by pcic_p if it is
compiled in. It's still nice to get the better probe message if it's not...
Requested by: imp
is an application space macro and the applications are supposed to be free
to use it as they please (but cannot). This is consistant with the other
BSD's who made this change quite some time ago. More commits to come.
frames would be handled incorrectly due to bad usage of m_pullup() in
the case where the frame wraps from the end of the receive buffer back
the beginning.
Also, when manually extending small packets to pad them to the minimum
frame length during transmission, zero out the pad area to make some
really paranoid people happy.
the 3c450-TX HomeConnect. Like the 3cSOHO100-TX OfficeConnect, this NIC
uses the same ASIC as the 3c905B/3c905C but is targeted for a particular
market segment (home users). It is somewhat less expensive than the
3c905B/3c905C ($49, according to the 3Com web site), comes with its
own custom driver kit and is bundled with various goofy Windows software
packages designed to demonstrate the niftyness of home networking (networked
game demos, etc...).
Changes are:
- Add PCI ID to list in if_xlreg.h.
- Update xl_devs table in if_xl.c.
- Update xl_choose_xcvr() to consider the HomeConnect the
same as all the other 10baseT/100baseTX cards.
- Add a flag DC_TX_INTR_ALWAYS which causes the transmit code to
request a TX done interrupt for every packet. The PNIC seems to need
this to insure that the sent TX buffers get reaped in a timely fashion.
- Try to unreset the SIA as soon as possible after resetting the whole
chip.
- Change dcphy to support either 10/100 or 10Mbps only NICs. The
built-in 21143 ethernet in Compaq Presario machines is 10Mbps only
and it doesn't work right if we try to advertise 100Mbps modes during
autoneg. When restricted to only 10mbps modes, it works fine.
Note that for now, I detect this condition by checking the PCI
subsystem ID on this NIC (which has a Compaq vendor/device ID).
Yes, I know that's what the SROM is supposed to be for. I'm deliberately
ignoring the SROM wherever possible. Sue me.
The latter two fixes allow if_dc to work correctly with the built-in
ethernet on certain Compaq Presario boxes. There are liable to be quite
a few people using these as their home systems who might want to try
FreeBSD; may as well be nice to them.
Now if anybody out there has an Alpha miata with 10Mbps ethernet and
can show me the output from pciconf -l on their system, I'd be grateful.
used to edit the old-style isa_devtab config tables to insert a mapping
for a pci device into the isa tables so that the wdc driver could probe
it later. This has been #if 0'd since April.
attaching to the device via chip*, use the newbus nomatch method to report
the device. This leaves them unattached so that a driver can be easily
loaded to grab them later.
background ]
Rename sys/pci/pci_ioctl.h to sys/sys/pciio.h to make it easier for
userland programs to use this interface. Reformat the file, and add a
BSD-style copyright to it.
Add a new man page for pci(4). The PCIOCGETCONF, PCIOCREAD, and PCIOCWRITE
ioctls are documented, but the PCIOCATTACHED ioctl is not documented
because it is not implemented.
Change includes of <pci/pci_ioctl.h> to <sys/pciio.h> or remove them
altogether. In many cases, pci_ioctl.h was unused.
Reviewed by: steve
- Convert to using TX descritor polling similar to the xl driver (the
ST201 is a clone of the 3c90xB chipset and offers the same transmit
polling scheme). This should reduce TX overhad a little.
- Make sure to reset PHY when switching mode, as in the starfire driver.
- Fix instances of free() that should be contigfree().
- Remove dead code.
case. The idea is to reduce how often we call mii_tick(), however currently
it may not be called often enough, which prevents autonegotiation from
being driven correctly.
This should improve the chances of successfully autonegotiating media
settings on non-MII 21143 NICs. (Still waiting for confirmation from
some testers, but the code is clearly wrong in any case.)
Don't arbitrarily limit the initiator ID of the card to something <= 7.
Fix a bug in the checksum code that would incorrectly prevent a valid
checksum of zero. (cp)
Don't touch rely on seeprom data when configuring termination. We may
not have seeprom data. (cp)
Treat all ULTRA2 capable adapters the same way when reading or writing
the BRDCTL register. We previously only did this correctly for aic7890/91
chips. This should correct some problems with termination settings on
aic7896/97 adapters. (cp)
Changes marked with "(cp)"
Pointed out by: Chuck Paterson <cp@bsdi.com>
before selecting a mode. The Seeq PHY chips on the Adaptec cards that
use the AIC-6915 controller seem to need it in order to get them to
change modes correctly.
This corrects a problem that I noticed where my ANA-62022 board failed
to correctly program the full duplex bit in the macconfig1 register
when the interface was brought up. Running ifconfig sf0 would mask this
problem in some cases because polling the PHY status would cause the
miibus code to notice that full duplex was now needed and the statchg
callback would be invoked to configure the duplex setting. However it
would still get it wrong other times.
Also changed sf_miibus_statchg() to program the IPG register to match
the duplex setting in accordance with Adaptec manual's recommendations
(0x15 for full duplex, 0x11 for half duplex).
which it replaces. The new driver supports all of the chips supported
by the ones it replaces, as well as many DEC/Intel 21143 10/100 cards.
This also completes my quest to convert things to miibus and add
Alpha support.
device_add_child_ordered(). 'ivars' may now be set using the
device_set_ivars() function.
This makes it easier for us to change how arbitrary data structures are
associated with a device_t. Eventually we won't be modifying device_t
to add additional pointers for ivars, softc data etc.
Despite my best efforts I've probably forgotten something so let me know
if this breaks anything. I've been running with this change for months
and its been quite involved actually isolating all the changes from
the rest of the local changes in my tree.
Reviewed by: peter, dfr
by identifying the version in the PCI drivers.
The OHCI driver just presets this to 1.0 as it is not specified in the
PCI registers anywhere. This should be revisited once USB 2.0 is in
wide spread use.
