Description of Problem: Attempting an NFS install in Multia, connection to
the NFS server is never made because of the choice of driver module for the
builtin NIC (tulip).
Version-Release number of selected component (if applicable): alpha-72-beta1
How Reproducible: Attempt NFS-based install on Multia/UDB connected via
10MBit twisted-pair Ethernet.
Steps to Reproduce:
Actual Results: Network connection is attempted, using the "tulip" driver,
but is unsuccessful due to driver inability to run the builtin hardware.
The user is unable to choose a different driver.
Expected Results: Normal NFS install, which works quite well on other NICs.
Additional Information: Multia/UDB is notorious for it's deployment of the DEC
Tulip hardware, and usually requires the DE4X5 driver instead of the TULIP one.
If "expert" mode could be used to flag that the user would like to be asked
what network driver should be chosen, it would provide the opportunity to
choose the DE4X5 one before it is too late.
This bug is probably related to #58677, which has a status of CURRENT_RELEASE.
Does this mean it's fixed?
I'm running into a similar problem with the tulip driver. I've installed 7.2 as
a server on an alpha DS10L (tulip driver is the default). Our network is
100MBit Fast, and I can access it fine. However, if I add a 10MBit repeater
between my alpha and the network, I lose access to the network and the repeater
lights indicate a collision every second or so.
So I shut down the network, unload the tulip driver, load de4x5, and start up
the network, and my access is back. If I remove the repeater and go back to
100MBit access I'm also fine. Seems like the tulip driver's got a bug with
10MBit access, which is unfortunate given that it's the default driver.
his has always been an issue.
The problem lies in the MII link layer which the card fails to negotiate
In the current release the installer provides the 'noprobe' option and you can
select which network driver to use. It's not elegant but it's less hassle for
the end user. Whats really annoying is that this bug shows up in certain chip
foundry revisions and not in others.