[1559] in linux-net channel archive
Re: SMC Ether Power PCI
daemon@ATHENA.MIT.EDU (G.W. Wettstein)
Sat Dec 30 20:26:21 1995
From: greg@wind.rmcc.com (G.W. Wettstein)
Date: Sat, 30 Dec 1995 06:07:49 CST
In-Reply-To: retsam@sluh.edu
"SMC Ether Power PCI" (Dec 29, 9:07am)
To: retsam@sluh.edu
Cc: linux-net@vger.rutgers.edu
On Dec 29, 9:07am, retsam@sluh.edu wrote:
} Subject: SMC Ether Power PCI
>
> Hi,
Good morning Jacque, hopefully I can be of some assistance.
> Does anyone know if Linux supports the Ether power PCI
> Ethernet adapter? I recently purchased one because I heard that linux
> did support it. I've re compiled my kernel to include all the SMC
> cards but it didnt mention the etherpower and Linux did not recognize
> the card. Is there a kern patch or something that I can get to use
> this card? Any information would be greatly appreciated!!!
You probably are experiencing the same problems that we recently ran
into. It would appear that SMC has subtlely changed the EtherPower
line of cards. This is causing some difficulty and confusion in the
community.
When my team began vending PCI ethernet cards our primary concern was
the need for them to be supported by the Linux kernel. I spoke with
Donald Becker about the issue and he spoke highly of the SMC
EtherPower card. The original versions were based on the 21040
chipset by DEC which was codenamed the 'tulip' chip.
We just vended three additional workstations from Gateway 2000 and of
course specified the EtherPower cards. We installed one machine about
three weeks ago and when it was booted it began complaining about an
unknown PCI device on the bus. This was with the 1.2.13 kernel which
had the 21040/tulip driver compiled into it. It quickly became
apparent which device was unknown when ifconfig was unable to
configure the eth0 interface.
After opening the computer and examining the card it quickly became
apparent what the difficulty was. Clearly stamped on the chip was the
fact that the chipset had been changed to the 21041. We went through
the packing materials and sure enough there was a one page blurb which
stated that the appearance of the card was different and that we
should load the 'latest' Novell/Window drivers for optimum
performance.
There would appear to be two problems with using the 21041 based SMC
cards in the stock 1.2.13 kernel. First of all the device is not
recognized by the PCI code in the kernel and secondly the stock
21040/tulip driver in the kernel does not recognize the 21041 based
boards. I have heard comments that Donald has updated sources for the
tulip driver available through his web site. I have not investigated
this and have not heard of anyone having success with these drivers
and the new versions of the SMC boards.
I have heard comments that people are suggesting using the de4x5
drivers for these boards. The comments in de4x5.c in the 1.2.13
kernel sources indicate that support has been included for the 21041
chipsets. I have not tried this and have not heard of this being a
satisfactory solution. If the de4x5.c driver can support these boards
there still may be a problem with the fact that they are not
recognized as a known PCI device by the kernel.
The 1.3.x series of kernels does have PCI support for the SMC 21041
based boards. I attempted to compile this kernel with de4x5.c driver
support but as of the mid-1.3.4x series the drivers sources had not
been updated in face of the multicast changes. This causes
compilation to fail.
If memory serves me correctly I do remember seeing diffs in recent
kernel patches which addressed the compile problems with the de4x5.c
drivers. I have not attempted to compile a recent kernel with support
for these devices enabled. We solved the problem by the decidedly
low-tech but high-efficiency scheme of pulling the board and sticking
in a spare SMC-Ultra card.
I haven't had time to futz with the problem since then. There is a
real need to get the other two machines on-line in the near future so
I will have to re-address the issue since we only have one spare
SMC-Ultra card left... :-) If no one else comments I will post a note
describing what needs to be done to get these cards working.
If our congressional leaders can't get anything else done they should
at least consider passing a new technology law. This law would make
it illegal for manufacturers to change chipsets or fundamental
low-level behavior of an add-in card without renaming the product.
I say this rather whimsically but with a note of seriousness. I can't
even begin to count the number of times that we have been burned by a
problem like this. In this day and age when there seem to be so many
subtle differences and potentials for problems it almost seems like
misrepresentation for manufacturers to re-engineer a product and not
change the name. Our site depends heavily on purchasing devices with
proven track records, having them suddenly fail in this fashion
diminishes this trust level.
Hopefully all this is of assistance to others who are experiencing
this problem. A pleasant holiday weekend to everyone who is listening
via the network list.
> Jacque Bussey
>
> St. Louis University Hospital
> Information Systems
Greg
}-- End of excerpt from retsam@sluh.edu
As always,
Dr. G.W. Wettstein Oncology Research Div. Computing Facility
Roger Maris Cancer Center INTERNET: greg@wind.rmcc.com
820 4th St. N.
Fargo, ND 58122
Phone: 701-234-7556
----------------------------------------------------------------------
`The truest mark of a man's wisdom is his ability to listen to other
men expound their wisdom.' -- GWW
