Commit Graph

69 Commits

Author SHA1 Message Date
Bill Paul
57fc9d5aa7 Small tweak: just reset the transmit block instead of doing a global reset
in xl_init(). This achieves the effect that I wanted without totally
resetting the chip.
1999-10-25 20:52:32 +00:00
Bill Paul
b08cfb55ef Make some small tweaks:
- When setting/clearing promisc mode, just update the filter, don't
  reset the whole interface.

- Call xl_init() in xl_ifmedia_upd() when setting miibus media modes. This
  fixes a problem with the 3c905B-COMBO where switching from 10base5/AUI
  or 10base2/BNC to a 10/100 mode doesn't always work right.

- Attempt to reset the interface in xl_init() so that we know we're getting
  the receive and transmit rings reset properly.
1999-10-14 21:49:17 +00:00
Bill Paul
784733e9ec Change contigmalloc() lower memory bound from 1MB to 0 to improve
chances of allocations succeeding on systems with small amounts of
RAM.

Pointed out by: bde
1999-09-25 17:29:02 +00:00
Bill Paul
98a229f65e As suggested by phk, unconditionalize BPF support in these drivers. Since
there are stubs compiled into the kernel if BPF support is not enabled,
there aren't any problems with unresolved symbols. The modules in /modules
are compiled with BPF support enabled anyway, so the most this will do is
bloat GENERIC a little.
1999-09-23 03:32:57 +00:00
Bill Paul
9e4c647c74 Tweak these for what I hope is the last time: change the DRIVER_MODULE()
declaration for the interface driver from "foo" to "if_foo" but leave the
declaration for the miibus attached to the interface driver alone. This
lets the internal module name be "if_foo" while still allowing the miibus
instances to attach to "foo."

This should allow ifconfig to autoload driver modules again without
breaking the miibus attach.
1999-09-22 06:08:11 +00:00
Bill Paul
3d927b9b51 Close PR #13665. I managed to figure out the problem, no thanks to the
submitter, who *still* hasn't bothered to answer me back.

The thing which the submitter completely failed to mention is that
his 3c900B-TPO card has the transceiver selection in the EEPROM set
to "auto." You can tweak the setting using the 3C90XCFG.EXE utility
that 3Com provides with the card. I'm not sure if it's supposed to
default to auto or if the user fiddled with it. Currently, the xl
driver only does autoselection for 10/100 NICs (i.e. those with NWAY
autonegotiation capabilities). For the 10baseT, 10base5, 10base2,
10baseFL and 100baseFX cards, the driver sets the default media to
whatever the EEPROM transceiver selector says. The problem is that
the "auto" selection is mistakenly identified as "10/100 NWAY
autoselection mode" and this is not handled correctly: the default
media ends up being chosen as 100baseTX, which doesn't work because
we've only added 10baseT media types to the ifmedia word. This leads
to a panic in ifmedia_set() (something else which the submitter never
bothered to mention).

A workaround for this is to re-run the 3C90XCFG.EXE utility and change
the transceiver selection to something besides "auto." I have also
patched the driver to watch for the "auto" setting in the non-miibus
case and select a reasonable default based on the card type instead of
falling through to 100baseTX and exploding.

PR:		misc/13665
1999-09-20 20:26:14 +00:00
Bill Paul
0355003f26 Un-do the changes to the DRIVER_MODULE() declarations in these drivers.
This whole idea isn't going to work until somebody makes the bus/kld
code smarter. The idea here is to change the module's internal name
from "foo" to "if_foo" so that ifconfig can tell a network driver from
a non-network one. However doing this doesn't work correctly no matter
how you slice it. For everything to work, you have to change the name
in both the driver_t struct and the DRIVER_MODULE() declaration. The
problems are:

- If you change the name in both places, then the kernel thinks that
  the device's name is now "if_foo", so you get things like:

if_foo0: <FOO ethernet> irq foo at device foo on pcifoo
if_foo0: Ethernet address: foo:foo:foo:foo:foo:foo

  This is bogus. Now the device name doesn't agree with the logical
  interface name. There's no reason for this, and it violates the
  principle of least astonishment.

- If you leave the name in the driver_t struct as "foo" and only
  change the names in the DRIVER_MODULE() declaration to "if_foo" then
  attaching drivers to child devices doesn't work because the names don't
  agree. This breaks miibus: drivers that need to have miibuses and PHY
  drivers attached never get them.

In other words: damned if you do, damned if you don't.

This needs to be thought through some more. Since the drivers that
use miibus are broken, I have to change these all back in order to
make them work again. Yes this will stop ifconfig from being able
to demand load driver modules. On the whole, I'd rather have that
than having the drivers not work at all.
1999-09-20 19:06:45 +00:00
Bill Paul
fac1f39b19 Grrr. Okay, changing the devnames was a bad idea. Put them back the way
they were.
1999-09-20 08:47:11 +00:00
Bill Paul
b95a9362a0 Fix the strings in the driver_t structs so that they match the new names
in the DRIVER_MODULES() declarations. *sigh*
1999-09-20 08:14:39 +00:00
David E. O'Brien
abad681b03 Goofed and didn't change the second DRIVER_MODULE() linking these with
the miibus.

Noticed by:	wpaul
1999-09-20 07:50:10 +00:00
David E. O'Brien
bd8a15ce8a Change the name we register with DRIVER_MODULE() to include the leading
"if_".

Reviewed by:	msmith, wpaul
1999-09-20 06:50:52 +00:00
Bill Paul
1b4226d3e4 Add an alternate transmit strategy for 3c90xB adapters based on the transmit
strategy used in the 3Com Linux driver. The new strategy is to use transmit
descriptor polling -- that is, the NIC polls the descriptors to see when
new packets are available for transmission. The advantage to the new scheme
is that no register accesses are needed in the transmit routine. The old
scheme requires several register accesses to stall the TX engine, update the
TX DMA list pointer register, then unstall the TX engine. Hopefully the new
scheme will provide improved transmit performance with less CPU overhead.

This only affects the 3c90xB or 3c90xC cards, not the 3c90x cards. This
means the original 3c900 and 3c905 cards are unaffected. Newer cards include
the 3c900B series, the 3c905B, 3c980, 3c980B, 3c905C and 3c905C, and the
3cSOHO100-TX OfficeConnect.
1999-09-20 00:24:11 +00:00
Bill Paul
58454ee28c Dangit: mispelled TORNADO in one place. 1999-09-15 07:20:59 +00:00
Bill Paul
81569a614d 3Com has produced their own Linux driver for the 3c90x/3c90xB series cards.
It's GPL'ed of course, but looking over it tonight I learned of Yet Another
Fast EtherLink XL Adapter: the 3c980C server adapter. This is basically
an updated version of the 3c980 that uses the Tornado ASIC instead of the
earlier Hurricane ASIC. The only change here is to add the new PCI device
ID (0x9805) and corresponding table entries.
1999-09-15 07:19:34 +00:00
Peter Wemm
518dee7dbb Add a pointer to "controller miibus0" for people who will not read the
commit messages or GENERIC and insist on running -CURRENT.
It probably won't work, but it's worth a try.
1999-09-08 15:01:58 +00:00
Bill Paul
499d0ac7aa Just when I thought it was safe. In the original 3c905-TX NICs, the
external NatSemi PHY chip was programmed to respond to MII address 24.
In the 3c905B ASICs, the transceiver is internal but it's still mapped
to MII address 24. But *some* 3Com 3c905B ASIC revisions map the
transceiver control registers to *all* MII addresses (0 through 31).
The miibus code probes for PHYs at all MII addresses and because of
this unusual behavior, it will attempt to map the same PHY registers
several times over, which doesn't work.

Naturally, the 3c905B NIC that I tested happened not to exhibit this
behavior.

The fix is to tweak xl_miibus_readreg() and xl_miibus_writereg()
to only respond when attempting to read from MII address 24. This
is safe to do since the 3Com documentation indicates that the PHY
and/or internal transceiver will always be mapped to address 24,
and there are no 3Com XL NICs with more than one PHY.
1999-09-01 03:16:21 +00:00
Bill Paul
1ef8fbeabf Convert the 3Com XL driver to miibus. This one is a little tricky
due to the fact that there are non-MII cards supported by the same
driver and I don't have all of the cards available for testing. There's
also the 3c905B-COMBO which has MII, AUI and BNC media ports all in one
package. Supporting the COMBO is difficult because we have to add the
10base5 and 10base2 media types to the same ifmedia struct as the
MII-attached types, however there is no way to force the miibus and
child PHYs into existence before xl_attach() completes, so there is
no ifmedia struct available in xl_attach(). What we do inistead is
use the mediainit method as a callback: when a child PHY is attached,
it calls the miibus mediainit routine which selects a default media.
This routing also calls the NIC driver's mediainit method (if it
implements one) at which point we can safely add the other media
types.
1999-08-29 15:52:19 +00:00
Peter Wemm
c3aac50f28 $Id$ -> $FreeBSD$ 1999-08-28 01:08:13 +00:00
Bill Paul
b32ba21dfd Small tweak: in xl_rxeof(), rxstat should be u_int32_t, not u_int16_t. 1999-08-19 03:47:18 +00:00
Bill Paul
5a58e7fbc6 Minor tweak for last commit: insert extra delay between issuing master
reset and RX/TX resets.
1999-08-02 21:57:57 +00:00
Bill Paul
9a65a1c94d Perform an RX reset and TX reset in xl_reset() along with the master
reset command.

I observed some anomalous behavior while testing a 3c905C with a
Dell PowerEdge 4300/500 dual PIII 500Mhz system. The NIC would seem
to work correctly most of the time but would sometimes fail to receive
certain packets, in particular NFS create requests. I could mount
an NFS filesystem from the PowerEdge and do an ls on it, but trying
to do a "touch foo" would hang. Monitoring traffic from another host
revealed that the client was properly sending an NFS create request
but the server was not receiving it. It *did* receive it when I
ran the same test with an Intel fxp card.

I don't understand the exact mechanics of this strange behavior, but
resetting the receiver and transmitter seems to get rid of it. I used
to perform an RX and TX reset in xl_init(), but stopped doing it there
because on 3c905B and later cards this causes the autoneg session to
restart, which would lead to the NIC waiting a long time before exchanging
traffic after being brought up the first time. Apparently the receiver
and transmitter resets should be performed at least once when initializing
the card.

Hopefully this will cure problems that people have been having with the
3c905C -- this was the only strange behavior that I have observed with
the 3c905C so far which does not appear with the 3c905B or 3c905.
1999-08-02 21:06:16 +00:00
Bill Paul
5c9e5de3e3 Some more small newbus cleanups. Remember to free all resources in case
of failures in foo_attach(), simplify iospace/memspace things a little.
1999-07-23 02:06:57 +00:00
Bill Paul
a02be1be5b Well, it seems that loading a PCI driver module after the system has
been booted works too -- very neat. However I don't want the system to
stop for 5 seconds when the MII autoprobe is triggered in the xl and
tl drivers since that's lame. Instead, only use the hard delay when
we've been cold booted. If not, use the timeout mechanism instead.
(The SysKonnect driver doesn't use the same autonegotiation scheme, so
no change is required there.)
1999-07-22 18:10:20 +00:00
Bill Paul
137424578b Small tweak to newbus changes: return error status on failure correctly
in xl_attach() (not a problem if the attach never fails, but if it does
the function would still return 0, which is wrong).
1999-07-22 03:59:22 +00:00
Bill Paul
d1b67c3735 Convert the xl driver to newbus. It is now possible to make this driver
into a loadable module, and all of the platform dependencies are gone
(except for the alpha_XXX_dmamap() thing, which is another issue -- I
still don't know how to use the busdma stuff with a network driver).

Also increase the delay in xl_reset(); testing on a 486/66 with a 3c905C
shows that reading the EEPROM fails immediately after a reset. Waiting
a little longer after the reset completes seems to fix it.
1999-07-20 21:23:17 +00:00
Bill Paul
bedf427650 Grrr.... forgot one line from the previous fix. 1999-07-08 00:42:02 +00:00
Bill Paul
24e82101e0 Fix a potential race condition that can occur in xl_start(). If the NIC
clears out the transmit queue and zeroes the downlist pointer register,
but xl_txeof() isn't called before xl_start() tries to queue more packets,
xl_start() will think that the DMA is still in progress and not update
the downlist register again, thus causing packets to sit in the transmit
queue forever.

Patch provided by: Russell T Hunt <alaric@MIT.EDU>
1999-07-07 21:49:14 +00:00
Dag-Erling Smørgrav
6b5ca0d83e Rename bpfilter to bpf. 1999-07-06 19:23:32 +00:00
Peter Wemm
820f359d7e Change the cast in pci_map_port() from u_short * to pci_port_t * so it
compiles cleanly on the Alpha.  (On the alpha, the port type is an int,
not a short).
Cast a couple of pointers to ints via 'uintptr_t' rather than 'unsigned
int' since uintptr_t is long (64 bit) on Alpha, as are pointers.
1999-07-02 04:17:16 +00:00
Bill Paul
7ac97baa2c Change the warning message issued if pci_map_port() fails. I think this
happens if you have a BIOS with a 'Plug & Play OS' setting and you leave
it set to 'Yes.' This is wrong for FreeBSD (and LoseNT): it should be set
to 'No.' Apparently it's still possible to map the iobase of the NIC and
have the card work by reading the config space manually (which is what
the driver does if pci_map_port() fails) but we need to warn the user to
do fix their machine anyway. Anyway, warn the user to check the 'Plug &
Play OS' setting in their BIOS if mapping the io space fails.
1999-06-01 19:04:23 +00:00
Bill Paul
042d207492 Whoops, forgot to update xl_mediacheck() to account for the 3c905C. 1999-05-30 18:11:47 +00:00
Bill Paul
a62accda5a Head for the hills friends and neighbors, 3Com has yet another 3c90X
chipset. First you thrilled to the 3c905, then you trembled at the
3c905B, now gaze in wonder at: the 3c905C! This appears to be another
3c90X series chip called the Tornado (PCI ID 0x10B7/0x9200) and should
be equivalent (from the driver API perspective) to the 3c905B, so all
we have to do is add the PCI ID to the list.
1999-05-30 18:09:17 +00:00
Peter Wemm
579f45fa60 Simplify the COMPAT_PCI_DRIVER/DATA_SET hack. We can add:
#define COMPAT_PCI_DRIVER(name,data) DATA_SET(pcidevice_set,data)
.. to 2.2.x and 3.x if people think it's worth it.  Driver writers can do
this if it's not defined.  (The reason for this is that I'm trying to
progressively eliminate use of linker_sets where it hurts modularity and
runtime load capability, and these DATA_SET's keep getting in the way.)
1999-05-09 17:07:30 +00:00
Bill Paul
b346e4e2e4 Dynamically increase TX start threshold if TX underruns are detected. 1999-05-05 17:05:07 +00:00
Bill Paul
36d3e45587 Fix the media selection for the 3c900B-FL 10baseFL adapter. It actually
uses the AUI port with an on-board AUI to 10baseFL transceiver, not the
10baseT port like I had earlier suspected. The 3c900B-FL should be properly
supported now.
1999-05-04 20:52:30 +00:00
Bill Paul
0a9766ee3a Bunch of updates:
- Try to unbreak what I broke by screwing with the tx queuing again.
  I'm waiting for a few more people to test out this code and report back
  before I move it into current. Hopefully it will be soon. Basically I
  reverted to the old TX queuing strategy.

- Add experimental support for the 3c900B-FL (10mbps ST fiber). The card
  should be detected properly and the 10baseFL mode supported, but again
  I'm still waiting for word from a tester to see if this actually works.
  It shouldn't affect the other cards though; all the differences are in
  media selection.

- Set the TX start threshold register to get better performance.

- Increase the size of the RX and TX rings. UDP performance was pretty
  bad because the TX ring was too small. Should be substantially better
  now (I can saturate the link with either TCP or UDP now).

- Change some of the #defines to reflect proper 3Com ASIC names (boomerang,
  cyclone, krakatoa, hurricane).

- Simplify and reorganize interrupt handler; ack all interrupts right
  away and then process them. This avoids a potential race condition.
  (Noted by Matt Dillon.)

- Reorganize the bridging code to eliminate using a goto to jump into
  the middle of an if() {} clause. Sorry, that just made my brain itch.

- Use m_adj() in xl_rxeof().

- Make the payload alignment in xl_newbuf() the default (instead of
  just conditionally defined for the alpha) to improve NFS performance
  (avoids need for nfs_realign()).
1999-04-30 16:15:43 +00:00
Peter Wemm
96b3554e5c Use COMPAT_PCI_DRIVER() for registration if it exists. This shouldn't
hurt the driver portability to 3.x too much for where drivers are shared.
1999-04-24 20:17:05 +00:00
Peter Wemm
6182fdbda8 Bring the 'new-bus' to the i386. This extensively changes the way the
i386 platform boots, it is no longer ISA-centric, and is fully dynamic.
Most old drivers compile and run without modification via 'compatability
shims' to enable a smoother transition.  eisa, isapnp and pccard* are
not yet using the new resource manager.  Once fully converted, all drivers
will be loadable, including PCI and ISA.

(Some other changes appear to have snuck in, including a port of Soren's
 ATA driver to the Alpha.  Soren, back this out if you need to.)

This is a checkpoint of work-in-progress, but is quite functional.

The bulk of the work was done over the last few years by Doug Rabson and
Garrett Wollman.

Approved by:	core
1999-04-16 21:22:55 +00:00
Guy Helmer
93c0b05959 Add bridging support (tested in 3.1-RELEASE by Steven Vetzal
<svetzal@icom.ca>).
1999-04-16 01:56:06 +00:00
Bill Paul
ae1a2d45d9 - Close PR #11136: add PCI ID for another new cyclone device: the
3c900B-TPC (twisted pair and coax). Treated similarly to the
  3c900B-COMBO, except no AUI port.

- Fix media selection so that it's possible to select the AUI and BNC
  ports on the 3c905B-COMBO. This board is now fully supported.

- Change TX queueing strategy to hopefully be more efficient by avoiding
  register accesses in xl_start(). Should provide small performance
  improvement and a little better reliability.
1999-04-15 03:18:33 +00:00
Bill Paul
980e28f69a Add support for the 3cSOHO100-TX, which is a "hurricane" chipset
(cut-down version of the "cyclone" for the small office/home office
"cheap bastard" market). Basically the same as a 3c905B but without
Wake-on-LAN, ROM socket, etc...
1999-04-12 20:38:45 +00:00
Bill Paul
863e79b09e Some small updates:
- Wait longer for the reset to complete in xl_attach() to try and avoid
  'command never completed' warnings.

- Clean up a few odds and ends in xl_attach().

- Add PCI ID for the 3c905B-COMBO (a new card). Right now this is
  treated as a 3c905B; I need to dig up one of these cards for testing
  before I can make the AUI and BNC ports work.

- Add a hack to force reading the I/O address directly from the PCI
  registers if pci_map_port() fails. I SHOULD NOT HAVE TO DO THIS:
  SOMEBODY WITH MORE PCI CLUES THAN I SHOULD INVESTIGATE WHY THIS
  HAPPENS.
1999-04-11 17:44:44 +00:00
Bill Paul
11ebc6f0fa Shorten device names so that the pci probe lines don't exceed 80 chars
and wrap to a second line.

Put 'command never completed' message inside #ifdef DIAGNOSTIC/#endif to
stop people worrying about it (it's harmless).
1999-03-31 15:45:15 +00:00
Bill Paul
8fe2c75e31 Make the xl and pn drivers work on FreeBSD/alpha and add them to
sys/alpha/conf/GENERIC.

Note: the PNIC ignores the lower few bits of the RX buffer DMA address,
which means we have to add yet another kludge to make it happy. Since
we can't offset the packet data, we copy the first few bytes of the
received data into a separate mbuf with proper alignment. This puts
the IP header where it needs to be to prevent unaligned accesses.

Also modified the PNIC driver to use a non-interrupt driven TX
strategy. This improves performance somewhat on x86/SMP systems where
interrupt delivery doesn't seem to be as fast with an SMP kernel as
with a UP kernel.
1999-03-27 20:41:25 +00:00
Bill Paul
69807449d7 Remove call to DELAY() from xl_wait(), since xl_wait() is in the
interrupt handler codepath. Having the delay there didn't really
accomplish much anyway.
1999-02-26 08:39:24 +00:00
Bill Paul
021f8bcb89 Do not issue RX and TX reset commands in xl_stop() and xl_init(). On the
3c905B, the RX and TX reset commands also reset the cyclone chip's internal
PHY, which causes it to restart its autonegotiation session. This takes a
second or two to complete, which makes the interface seem to stop responding
for a few seconds every time you do something that reinitializes it.

Issuing the RX and TX resets on the older 3c905 boomerang adapters doesn't
cause any delay because the boomerang chip requires an external PHY.

This should fix the problem where people doing network installs via 3c905B
cards experience a delay after the interface is first initialized, among
other things.
1999-02-11 23:59:29 +00:00
Bill Paul
e8354668bd Remember to initialize ifp->if_snd.ifq_maxlen. 1999-02-01 21:25:52 +00:00
Bill Paul
7ceecbe4ef Fix a small bug in xl_start(): when queuing a packet onto the end of
an existing chain, don't forget to move xl_tx_tail to point to the new
tail end.
1998-12-24 17:50:34 +00:00
Matthew Dillon
2cbe36f725 probe function changed from returning char * to const char *. 1998-12-14 06:37:37 +00:00
Bill Paul
6ab0ab275d Silence gcc -Wall -ansi -pedantic and fix minor bug in xl_txeof().
Pointed out by: Eivind
1998-12-10 16:18:43 +00:00