DEC 21x4x Ethernet Network Driver (QNX)
Net.tulip [-A] [-B] [-H media_code] [-c chipset] [-d] [-F] [-I pci_index] [-i irq] [-l log_net_id] [-M] [-m mac] [-n tx_num_retries] [-o] [-P] [-p io_port] [-r media_rate] [-s] [-t tx_retry_ticks] [-v] [-w wirespeed] [-Z] &
These settings will load the corresponding media block from the SROM, provided the block is present in the SROM. The card will operate only in the media specified. If the block isn't present, the driver will attempt autodetection of the media. Note that you can use the tdump program to check if the media block is present.
The highest level of verbose output is used mainly as a debugging tool. For example, if you do a netinfo -L1 > 1, the regular output of netinfo will be directed to the file 1, and extra debugging information from the driver will appear on your screen.
The -Z option will override the SROM and insert default values -- this could either enable/disable your media. |
The Net.tulip driver should be treated as a completely new version of the Net.Ether21x4x driver and as such has a few known limitations (see release notes). |
Net.tulip supports all cards currently supported via Net.Ether21x4x, including the following DEC chipsets: 21040, 21041, 21140, 21142/21143 and their various steppings.
SROM support has been added for all standard SROM formats from the early 21041 compact format through to the latest 4.05 format from Digital.
Note that this version of the driver can be identified via sin versions and should be reported as 4.24F or later.
The Net.tulip driver uses the generic PHY support provided by the MDI interface in QNX. This includes specific support for the following PHYs (as well as generic support for all other PHY chips):
If Net.tulip gets the link speed wrong, disconnect a cable to cause a link down in a couple of seconds. Then reconnect the cable -- this should return you to the correct link (and force autonegotiation to occur again).
Net.tulip implements a link detection algorithm if no link is found. This can sometimes cause an incorrect link to be chosen between autonegotiation partners. Upon removal of a link, Net.tulip will then attempt to autonegotiate, getting the correct link this time round.
If a PHY is used and you specify link speed/duplex settings at the command line, the hardware will be configured to those settings -- the PHY will report a valid link even if there isn't one! In other words, when you force link speed/duplex settings, you disable the PHY's autodetection/negotiation features. |
Here are the main options you'd use for this driver:
Start two cards in a system, specifying a PCI index (1) and logical network ID (2) for the second card:
Net & ./Net.tulip -v & ./Net.tulip -I1 -l2 -vv &
Start a 21140-based card using IRQ 10:
Net & ./Net.tulip -c 21140 -i10 &
Set different speeds for two cards:
Net & ./Net.tulip -w100 -v & # 100bT ./Net.tulip -w10 -I1 -l2 -v & # 10bT
Set media codes for two cards:
Net & ./Net.tulip -H0 -vv & # 10bT ./Net.tulip -H6 -I1 -l2 -v & # 100bT4
If the Net.tulip driver prints the following message on startup:
Rx DMA Workaround in Effect
then your network card may suffer from a known receive-process-hang problem. In 99.9% of the cases, normal operation will remain totally unaffected and everything will be okay. However, on some machines with older PCI chipsets, Net.tulip performance can be severely degraded.
You can tell if your machine is affected by running the card under network load and monitoring the output from netinfo at the end. If you see the following message, you know you're affected:
tulip ( rx) Rx Overflow Errata, discarding pkts
The cause of the problem is PCI DMA overruns, which result in corrupt Rx data packets (which then must be discarded, causing Protocol timeouts).
Most of the chips in the DEC family 21140 through to 21143 are subject to this problem (newer chips to a much lesser degree). Contact Digital for more information.