Bug 6940 - Outdated tulip driver
Outdated tulip driver
Status: CLOSED DEFERRED
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
6.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Cristian Gafton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-11-12 01:10 EST by Chris Ricker
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-11-15 11:28:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Chris Ricker 1999-11-12 01:10:16 EST
The tulip driver shipped with the kernel in 6.1 doesn't work with some
newer clones (it failed on a Macronix (PMAC) card--the card is found, the
driver loads, but it fails to establish a link).  Upgrading to 0.91g from
Donald Becker's web page fixes that problem.
Comment 1 Bill Nottingham 1999-11-15 11:28:59 EST
Unfortunately, the newer driver breaks some of the older cards.
We're looking into ways to solve this.
Comment 2 Chris Ricker 1999-11-16 10:10:59 EST
Yeah, I know.  So far the best idea I've had is to install both drivers.  Call
one tulip.o, and the other tulip-0.91.o, or whatever.  Go ahead and alias the
tulip.o by default, but have the other one there and alternatively insmod'able
(during install, if you're doing the install via net) / alias'able (after the
system is up and running).  The main problem is that, without the new driver
installed, people are in the Catch-22 of needing the new driver so they can get
the new driver (or vice-versa for old real Tulips if you default to the new
tulip driver).  If one's not going to work for everything, that's fine as long
as you document it, but have the other one around *somewhere* so that people who
are going to need it can have it.

Alternately, you could do a couple of *really* ugly things, like ask the person
which tulip driver to use during the install, or else leave tulip-0.89 in as the
tulip driver, and hack the tulip-0.91 in as pnic.o, and make tulip.o only
recognize older cards and pnic.o recognize all the newer almost-but-not-quite
tulip clones.
Comment 3 Bill Nottingham 1999-11-16 11:14:59 EST
Actually, there's a tulip driver disk available at
people.redhat.com/notting/tulip

You can boot the installer with 'linux dd' and it will use this driver
instead. Unfortunately, I've yet to hear any confirmation that the driver
disk works, so I can't release it more generally yet....
Comment 4 Chris Ricker 1999-11-22 00:08:59 EST
Stupid me--I forgot RH had the supplemental driver disk option (certainly a lot
more elegant than what Debian's talked about doing for that card, which is an
entire separate package a la pcmcia-cs drivers ;-).  At any rate, I've tried the
supplemental driver disk on three machines, and it worked on all of them.  One
suggestion:  "rename" it.  In the modinfo file right now, you've got

DEC 21040, most 21*40 Ethernet

which is the same name as the other driver.  That means both show up on the
list, and people have to guess by order which one is which....  Other than that,
it seemed good to go.
Comment 5 Pekka Savola 1999-11-22 09:48:59 EST
I'd like to add something to the discussion too.  We have some tulip clones
here, and the old 0.89H breaks their speed/duplexity if you don't use
autonegotiation.

It's impossible to get 100/ Full-Duplex without modifying the driver and
recompiling it.  Passing relevant options (options=5 full_duplex=1) when
loading the module don't work.

This is only caused by some tulip chips, it seems.  All these problems were
fixed when we moved to 0.91.  I really hope that version would come in the
distribution in at least _some_ form.

Has Donald Becker / tulip-devel mailing list been notified about the driver
problems (concerning older tulip cards) ?

Note You need to log in before you can comment on or make changes to this bug.