Re: Ethernet card config - Bering
David Dannemiller <[email protected]>
| Newsgroups | gmane.linux.drivers.realtek.devel |
|---|---|
| Message-ID | <B96F449F.41AA%[email protected]> |
> From: Donald Becker <[email protected]> > Date: Thu, 1 Aug 2002 14:35:45 -0400 (EDT) > Hmmm, your system doesn't use a module dependency list. That's not a > problem, I just didn't know that other such systems were out there. > > In the Scyld system we use similar explicit module loading rather than > implicit dependencies, however the static load list is generated > automatically. I'm running the Bering version of LEAF - a 1-floppy Linux router/firewall. http://leaf.sourceforge.net/mod.php?mod=userpage&menu=904&page_id=21 The rtl8139.o and pci-scan.o are your source code compiled by Jacques Nilo and available at: http://leaf.sourceforge.net/devel/jnilo/bering/latest/contrib/drivers/scyld/ >>> What is the packet count when this happens? ('cat /proc/net/dev/') >> The file /proc/net/dev is size zero. > > This is a pseudo-file for reporting statistics. It's size will be zero > until you read it. That's why I recommend using 'cat' -- some versions > of 'more' and 'less' try to read the file size before showing the contects. > > We need the packet count to find if the very first packet had a transmit > problem, or some subsequent packet could not be transmitted. Someday maybe I'll learn to follow instructions. cat /proc/net/dev produces: Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed lo: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 dummy0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth0: 0 0 0 0 0 0 0 0 0 0 0 4 0 0 0 0 eth1: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > Acutally, the error message output above is sufficient. > MII #32 registers are: 1100 782d 0000 0000 01e1 45e1 0001 0000. > The key point is that you still have link beat with a link partner that > reports 45e1 capability. > > I am a little curious about the board version and EEPROM contents. The > link partner 45e1 capability means that the switch support flow control, > but the NIC isn't advertising flow control. Most recent rtl8139 chips > should support flow control. > > This relevant because flow control could stop the transmitter long > enough to (incorrectly) trigger a transmit timeout. A lot of what you're saying is Greek to me, but I understand the "board version" part. :-) Both cards are D-Link model DFE-530TX+. 00:50:ba:42:c7:b0 is Rev.C1, purchased fall 2000 00:50:ba:cc:67:58 is Rev.D2, purchased last week How can I dump the EEPROM contents? The documentation on the older card lists the following features: IEEE 802.3u standard for 100 Mbps IEEE 802.3 standard for 10Mbps PCI 2.1 Bus (Bus Master) etc. There is no mention of flow control. It has been working fine in this same computer for 1 1/2 years. The documentation on the newer card is useless - dummied down with lots of Windows installation screen shots. Features listed on the box are: 32-bit PCI Local Bus Master Architecture IEEE 802.3 10Base-T & IEEE 802.3u 100Base-TX Compliant Supports IEEE 802.3x Flow Control Supports Half and Full Duplex Supports NWAY Auto-Negotiation Plug and Play Installation Boot ROM Support Wake-On-LAN PCI 2.2 > Some PCI slots don't support bus masters. That's easy to understand and > avoid. > Worse, some PCI motherboards (e.g. Abit) share one set of bus master > signals between two slots. So a bus master card will work in either > slot, but you cannot plug in two bus masters that are simultaneously > active. The PCI and ISA slots are on a riser board. There are 2 ISA slots, 1 PCI slot, and 1 slot that can swing either PCI or ISA. A Compaq sticker on the board says: Replace with COMPAQ Spare RISER BOARD [188820-001] Etched on the bottom of the riser board is: TOPSEARCH TS-M-8VOC 94V-0 and some more numbers. I sure appreciate the help. Thank you. DPD