Tue Sep 1 12:34:15 1998
The big problem I had was with TX timeouts when trying to use the the
card in 100BaseTX mode. It would work for a little while and then things
would freeze for awhile. When I looked the syslog file, I would see the
TX timeouts messages. There was a more minor problem in that any time
one of my systems did something that caused a large number of packets to
be received by a system i.e. FTP upload, I would get a continuous flow
of "PCI Bus error" messages in my /var/log/messages file.
The problem turned out to be that the documentation for the SMC83c170
chip was wrong regarding what bit was the real PCI Data Parity Error
bit. Because of the incorrect documentation from SMC, drivers before
v1.02 were looking at the "RX Early Threshold Crossed" bit instead. This
caused the driver to "spew" out a continous flow of "PCI Bus error"
Until I got version 1.02 of the driver, I had to fallback to a 10BaseT
hub. When running the SMC card in 10BaseT mode, I no longer had any
problems with TX timeout errors although I still had alot of "PCI Bus
Error" messages spewing to the syslog.
I have two SuSE Linux systems and two Win95 systems currently using the
SMC9432TX cards and I'm using a 3Com TP800 OfficeConnect hub which is
non-switching straight 100BaseTX. On the Linux side of things, one
system runs under a 2.0.33 kernel on an ASUS SP97-V motherboard with an
AMD K6-300 processor. The other system runs under a 2.0.35 kernel on an
ASUS P/I-XP6NP5 motherboard with a PPro 200 processor. I had to upgrade
to a newer kernel on the second system because of SCSI timeout problems
with the AIC7xxx driver on my AHA2940UW controller.
I notice that I get a link light on the card and on the hub a few
seconds after I power up a system. I pulled one of my Win95 systems
away from the wall so I could see the back of the card and when I
powered the system up, the 100BaseTX light comes on before the link
light. This would tend to indicate that the card negotiates either a
10BaseT or 100BaseTX connection shortly after powerup.
Heres the changes from the Epic 100 webpage:
v1.02 of 8/5/98
Found the real "PCI Data Parity Error". The '170 chip manual is wrong.
That bit is really "Rx Early Threshold Crossed", just like on the '175.
Compounding the problem, the Rx threshold value register is broken. The
solution is to always ignore that interrupt bit.
Fixed the media monitor timer to set FD when needed.
Ralf Tschiersch wrote:
> Dear Anthony,
> you posted that a problem eith epic100.o was directly solved with the
> author's help. I also have problems in getting my EtherpowerII 10/100 to
> work and want to ask you, what change to the driver made the effort for
> you? I mailed to the epic Mailinglist, but with no effect :-(
> I include my posting to comp.os.linux.networking and it would be nice if
> you could help me.
> Greetings from Aachen, Germany
> >From firstname.lastname@example.orgTue Sep 1 08:48:22 1998
> Date: Mon, 31 Aug 1998 19:05:30 +0200 (MET DST)
> From: Ralf Tschiersch <email@example.com>
> To: firstname.lastname@example.org
> Subject: Etherpower II: Flashing LED, no Contact
> Hello -
> I have Problems getting a 9432TX to work in any System. The environment:
> - Kernel is Linux 2.0.27, 2.0.29 or 2.0.33 (regardless),
> - Mainboards are Gigabyte GA586SG or several HX/TX Chipset types
> - epic100.o comes from v1.02 or v.1.04, both compiled well, no errors
> - cabling tested with several approved CAT5-cables
> - connection tried to the following devices:
> * Switches at 100Mbit, 10Mbit and one with autonegotiating
> * one Hub at fixed 10Mbit
> * crossover-cables to another Host running Ne2000-Clone at 10Mbit
> In any machine I tried there was a Ne2000-Clone as eth0 running fine for
> years (...).
> I have also payed attention to the PCI-Slot and BIOS IRQ-Handling, but
> everywhere I try I get (in messages)
> Aug 31 18:29:43 calvin kernel: epic100.c:v1.02 8/5/98 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/epic100.html
> Aug 31 18:29:43 calvin kernel: eth1: SMC EPIC/100 (chip ID 0005) at 0x6000, IRQ 10, 00:e0:29:0f:81:65.
> Aug 31 18:29:43 calvin kernel: eth1: MII transceiver #3 found, control 3000 status 7809 advertising 01e1 negotiated 0001.
> Aug 31 18:29:43 calvin kernel: PCI latency timer (CFLT) is 0x20.
> and (in syslog)
> Aug 31 18:29:43 calvin kernel: EEctrl is 61.
> Aug 31 18:29:43 calvin kernel: e000EEctrl is 61.
> Aug 31 18:29:43 calvin last message repeated 14 times
> (this message several Times).
> All I can see is the syslog-message and the onboard LED flashing
> 100, Link, 100, none, 100, Link, 100, none, 100, ...
> No TX/RX, no stable Link... the Device can be configured via ifconfig,
> but neither switch nor hub nor crossover-card comes up with an active
> link (indeed, they also blink in the same order/speed!)
> What went wrong? I have compiled the diagnostic programs but the output
> is not very, hum, sharp for me.
> I suppose the card is defective in the transceiver-area onboard, but what
> tools do I have to find out clearly?
> Any help would be greatly appreciated, If I have to provide any other
> data, I will do so.
> Thanks in advance -
> Aachen, Germany
| To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the
| body of the mail, include only the text:
| unsubscribe this-list-name email@example.com
| You will be unsubscribed as speedily as possible.