[5278] in RedHat Linux List
On supported hardware (was Re: 3com Bommerang netcard)
daemon@ATHENA.MIT.EDU (Sheldon E. Newhouse)
Wed Nov 20 10:20:55 1996
Date: Wed, 20 Nov 1996 10:09:08 -0500 (EST)
From: "Sheldon E. Newhouse" <sen1@math.msu.edu>
To: redhat-list@redhat.com
cc: tintype@zedalis.com
In-Reply-To: <Pine.LNX.3.95.961120074728.6123A-100000@ninja.zedalis.com>
Resent-From: redhat-list@redhat.com
Reply-To: redhat-list@redhat.com
These messages show clearly one of the main problems which still exists
for Linux:
Many of the main hardware manufacturers do not build drivers for it.
Perhaps it is unreasonable to expect that Don Becker will build and
test a driver for each new card that comes out. Unfortunately we can
bet that the hardware manufacturers will make damn sure that their
hardware runs under Microsoft products.
I think it is time for definite action. Just as some companies
(Buslogic in particular) are now cooperating with the Linux
world, we should be able to make strong financial statements to the other
manufacturers. We now have a reasonable (at least to me) hardware and
software base.
Some suggestions:
1. As new products become available *and* tested, they get added to
the Hardware HOW-TO. It is very important that this be kept up-to-date.
The Linux Hardware HOW-TO is now dated 14 Nov, 1995, and is not
up-to-date. It especially does not warn users about the Adaptec
problems.
Right now, AFAIK, problems such as those found with the Adaptec cards can
only be realized by going to the appropriate news-group (or is it mailing
list?). It is unreasonable to expect people to check many lists to find what
is well supported.
We need to have a place where tried and tested hardware is listed.
Up-to-date Hardware HOW-TO could be the place.
Should there be another place?
Perhaps we should have a list of recommended systems.
This might make some dent in the hardware world.
2. Companies that don't supply specs and don't cooperate with Linux
should be explicitly mentioned, avoided, *and* written to. Hardware
sellers (especially those of full systems) should be told that their
hardware will not be bought because they don't support Linux.
I know this is not easy to do, but we have a good enough base now to
start trying. Otherwise will we just continue to have the same lags
and frustrations dealing with new hardware.
My $.02.
-sen
> Date: Wed, 20 Nov 1996 08:15:38 -0500 (EST)
> From: Stephen Zedalis <tintype@zedalis.com>
> Reply-To: redhat-list@redhat.com
> To: redhat-list@redhat.com
> Cc: Lars.Tolle@uni-c.dk
> Subject: Re: 3com Bommerang netcard
> Resent-Date: Wed, 20 Nov 1996 08:14:47 -0500
> Resent-From: redhat-list@redhat.com
>
>
> On Wed, 20 Nov 1996, Lars Tolle wrote:
>
> > I am running RH4.0 on 2 100Mhz Pentium machines these have the new 3COM
> > bommerang netcard (3c900 series).
> > I installed them with an other card. The build a kernel which supported
> > the 3c59x netcard, but before i compiled the kernel I got the 3c59x.c file
> > from the net, which should support the 3c900 cards.
> > But now both of the machines is randomly loosing the connections to the
> > network.
> > The machines is running as news-servers so there is ALOT of net-traffic.
> > When i boot the machine i get the following messages in my logs:
> >
> > ==========================================================
> > kernel: eth0: vortex_open() irq 11 media status 8822.
> > kernel: eth0: Media selection timer tick happened, MII.
> > kernel: eth0: Media MII is has no indication, 8822.
> > kernel: eth0: Media selection timer finished, MII.
> > kernel: eth0: Transmitter access conflict.
> > ==========================================================
> >
> > And this messages is being printed to stderr all the time:
> >
> > eth0: Transmitter access conflict.
> >
> > I also have another machine with the same setup, but this is my own, so
> > there is not the same amount of net-traffic. This machine NEVER goes down,
> > except when i screw up :-)
> >
> > Any help is appreciated...
>
> We had the same problem with the boomerang cards. It doesn't matter what
> driver you have at this point. What we found is that even if you use the
> supplied software disk to lock access at one transfer rate, that the
> driver despite what options you give, puts the driver in autosense mode.
> Since you can't lock the port, you get periodic changes from one transfer
> rate to another (10-100-10). It is worse on heavily loaded
> machines (like news boxes) Although the messages are annoying, you can
> turn them off (until you get new cards) by using a -c 1 option to kerneld
> when you start up. If you have a smart switch connected to these cards
> you can see the problem at 100BaseTx where you get several FCS and
> alignment errors. You can also verify, that even after locking the card
> via EEPROM and/or the driver options, that the card will still autoswitch
> if put in a differently configured port. Also from your messages above,
> if you follow the instructions given with the driver, it does NOT behave
> like the vortex cards and the card starts with the MII interface instead
> of a fixed 100BaseTX transciever. We were not successful with any of the
> drivers provided by Don Becker and he does not respond to our email.
>
> We have switched to SMC EtherPower 10/100 9332DST cards. At 100BaseTx,
> they appear to be much faster cards than the 3Com at the same speed.
> However, they also have several problems. First, the (tulip) drivers are
> written by Don Becker. Same support issues. Second, it appears that
> the driver was written primarily for 100BaseTx and it was assumed that
> it would work with 10BaseT. Our testing shows severe problems at 10BaseT.
> We get several overrun frame buffer error messages if we try to run the
> cards at 10BaseT full duplex. One plus is that the driver comes with the
> kernel, the minus is that there have been several tulip.c patches in the
> latest set of kernels.
>
> Bottom line. We have not found ANY good solution for 10BaseT full duplex.
> Seems like full duplex was added to 10BaseT as an afterthought, and it is
> also hard to find switches/hubs that support it. Too bad, many network
> collision problems could be solved by going full and may not have required
> 100 Mbps. If you are using 10BaseT half duplex, stick with the tried and
> true 3Com 3C509s or whatever you are used to using. If you are using
> 100BaseTx, the SMC cards work quite well. Avoid any mixed environment.
> N-way autosensing DOES NOT work well, if at all at this time. Realize
> that all my comments are directed toward Linux as an operating system and
> may not apply to the Bill-derived operating system imitations.
>
>
>
>
> --
> PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
> ________________________________________________________________________
> http://www.redhat.com/RedHat-FAQ http://www.redhat.com/RedHat-Errata
> http://www.redhat.com/RedHat-Tips http://www.redhat.com/mailing-lists
> ------------------------------------------------------------------------
> To unsubscribe: mail -s unsubscribe redhat-list-request@redhat.com < /dev/null
>
>
---------------------------------------------------------------------------
| Sheldon E. Newhouse | e-mail: sen1@math.msu.edu |
| Mathematics Department | |
| Michigan State University | telephone: 517-355-9684 |
| E. Lansing, MI 48824-1027 USA | FAX: 517-432-1562 |
---------------------------------------------------------------------------
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
________________________________________________________________________
http://www.redhat.com/RedHat-FAQ http://www.redhat.com/RedHat-Errata
http://www.redhat.com/RedHat-Tips http://www.redhat.com/mailing-lists
------------------------------------------------------------------------
To unsubscribe: mail -s unsubscribe redhat-list-request@redhat.com < /dev/null
