Bug 111610 - Tulip (Dec 21140) will not pick up DHCP when booting
Tulip (Dec 21140) will not pick up DHCP when booting
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
1
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Garzik
Brian Brock
:
: 111609 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-06 03:26 EST by Eric Wiens
Modified: 2013-07-02 22:16 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-29 15:48:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Workaround (136.29 KB, patch)
2004-02-23 17:56 EST, Kasper Dupont
no flags Details | Diff

  None (edit)
Description Eric Wiens 2003-12-06 03:26:17 EST
Description of problem:
My nic would not pick up an IP address.  I found that if I unpluged my
network cable and then pluged it back in I could then get it to work.
 Once plugged back in I could use the "Network" tool found under
systems settings to "Activate" the nic.  If I tried to activate the
nic before unplugging the network card it would not work.

I tried unpluging and then plugging back in the network cable at the
grub boot menu before linux booted.  It didn't help.  I have used
Win98SE and W2K with this nic just fine.

I found one way to get around it was to go and edit my modules.conf
and add:
"options tulip options=4"
then it picked an IP up just fine after boot.  Unfortunatly it appears
to be running in 10Mbit 1/2duplex.  

The second way to get it to work is once booted to run:
"mii-tool -r" to get the card to do an auto-negotiation all over
again.  Once this is done I can re-activate the nic.

My nic is connected to a Dlink DSS-8+ switch.

I did a tcpdump to see what was going on when it didn't work.  My DHCP
server is on 192.168.0.1.  I don't know much about the low level DHCP
workings but it would appear that it finds an IP of 192.168.0.195.  Or
at leasts that's what this machines IP seems to always be:


Version-Release number of selected component (if applicable):


How reproducible:
Every time

Steps to Reproduce:
1. Install linux.  Doesn't seem to matter which distro.  Today I used
Fedora 1
2. No firewall, selected use DHCP during install.
3. Tried to surf the net
  
Actual results:
Checked to see if an IP was assigned to nic. 

Expected results:
No IP assigned to Nic

Additional info:
TCPDump when NIC has no IP and I try to do an manual activation with
out unpluging the network cable:
CP Dump when not working:
16:24:56.849312 > 0:60:67:36:21:4f 344:
16:25:03.007887 > 0:60:67:36:21:4f 344:
16:25:22.007942 > 0:60:67:36:21:4f 344:
16:25:30.007886 > 0:60:67:36:21:4f 344:
16:25:44.007961 > 0:60:67:36:21:4f 344:
16:25:58.007889 > 0:60:67:36:21:4f 344:
16:26:10.007887 > 0:60:67:36:21:4f 344:
16:26:21.007887 > 0:60:67:36:21:4f 344:
16:26:23.092709 arp who-has 192.168.0.1 tell 192.168.0.195
16:26:24.087653 arp who-has 192.168.0.1 tell 192.168.0.195
16:26:25.087655 arp who-has 192.168.0.1 tell 192.168.0.195
16:26:26.087685 192.168.0.195 > 192.168.0.195: icmp: host 192.168.0.1
unreachable [tos 0xc0]
16:26:26.087709 192.168.0.195 > 192.168.0.195: icmp: host 192.168.0.1
unreachable [tos 0xc0]
16:26:26.087718 192.168.0.195 > 192.168.0.195: icmp: host 192.168.0.1
unreachable [tos 0xc0]

Regular syslog info:
Dec  6 00:28:46 localhost kernel: SCSI subsystem driver Revision: 1.00
Dec  6 00:28:46 localhost kernel: inserting floppy driver for
2.4.22-1.2115.nptl
Dec  6 00:28:46 localhost kernel: Floppy drive(s): fd0 is 1.44M
Dec  6 00:28:46 localhost kernel: FDC 0 is a post-1991 82077
Dec  6 00:28:46 localhost kernel: Linux Tulip driver version
0.9.15-pre12 (Aug 9, 2002)
Dec  6 00:28:46 localhost kernel: PCI: Found IRQ 4 for device 00:0d.0
Dec  6 00:28:46 localhost kernel: PCI: Sharing IRQ 4 with 00:04.2
Dec  6 00:28:46 localhost kernel: PCI: Sharing IRQ 4 with 00:04.3
Dec  6 00:28:46 localhost kernel: PCI: Sharing IRQ 4 with 00:09.0
Dec  6 00:28:46 localhost kernel: tulip0:  EEPROM default media type
Autosense.
Dec  6 00:28:46 localhost kernel: tulip0:  Index #0 - Media 10baseT
(#0) described by a 21140 non-MII (0) block.
Dec  6 00:28:46 localhost kernel: tulip0:  Index #1 - Media 100baseTx
(#3) described by a 21140 non-MII (0) block.
Dec  6 00:28:46 localhost kernel: tulip0:  Index #2 - Media
10baseT-FDX (#4) described by a 21140 non-MII (0) block.
Dec  6 00:28:46 localhost kernel: tulip0:  Index #3 - Media
100baseTx-FDX (#5) described by a 21140 non-MII (0) block.
Dec  6 00:28:46 localhost kernel: tulip0:  MII transceiver #1 config
3100 status 782d advertising 05e1.
Dec  6 00:28:47 localhost kernel: eth0: Digital DS21140 Tulip rev 34
at 0xc8903000, 00:60:67:36:21:4F, IRQ 4.
Dec  6 00:28:47 localhost kernel: ip_tables: (C) 2000-2002 Netfilter
core team
Dec  6 00:28:47 localhost kernel: Linux Tulip driver version
0.9.15-pre12 (Aug 9, 2002)
Dec  6 00:28:47 localhost kernel: PCI: Found IRQ 4 for device 00:0d.0
Dec  6 00:28:47 localhost kernel: PCI: Sharing IRQ 4 with 00:04.2
Dec  6 00:28:47 localhost kernel: PCI: Sharing IRQ 4 with 00:04.3
Dec  6 00:28:47 localhost kernel: PCI: Sharing IRQ 4 with 00:09.0
Dec  6 00:28:47 localhost kernel: tulip0:  EEPROM default media type
Autosense.
Dec  6 00:28:47 localhost kernel: tulip0:  Index #0 - Media 10baseT
(#0) described by a 21140 non-MII (0) block.
Dec  6 00:28:47 localhost kernel: tulip0:  Index #1 - Media 100baseTx
(#3) described by a 21140 non-MII (0) block.
Dec  6 00:28:47 localhost kernel: tulip0:  Index #2 - Media
10baseT-FDX (#4) described by a 21140 non-MII (0) block.
Dec  6 00:28:47 localhost kernel: tulip0:  Index #3 - Media
100baseTx-FDX (#5) described by a 21140 non-MII (0) block.
Dec  6 00:28:47 localhost kernel: tulip0:  MII transceiver #1 config
1000 status 782d advertising 05e1.
Dec  6 00:28:47 localhost kernel: eth0: Digital DS21140 Tulip rev 34
at 0xc8903000, 00:60:67:36:21:4F, IRQ 4.
Dec  6 00:28:47 localhost kernel: ip_tables: (C) 2000-2002 Netfilter
core team
Dec  6 00:28:47 localhost kernel: eth0: Setting full-duplex based on
MII#1 link partner capability of 45e1.

Here's what it looks like when I add "options tulip options=4" to my
modules.conf and then it works when booting:
Dec  6 00:01:33 localhost kernel: Linux Tulip driver version
0.9.15-pre12 (Aug 9, 2002)
Dec  6 00:01:33 localhost kernel: PCI: Found IRQ 4 for device 00:0d.0
Dec  6 00:01:33 localhost kernel: PCI: Sharing IRQ 4 with 00:04.2
Dec  6 00:01:33 localhost kernel: PCI: Sharing IRQ 4 with 00:04.3
Dec  6 00:01:33 localhost kernel: PCI: Sharing IRQ 4 with 00:09.0
Dec  6 00:01:33 localhost kernel: tulip0: Transceiver selection forced
to 10baseT-FDX.
Dec  6 00:01:33 localhost kernel: tulip0:  EEPROM default media type
Autosense.
Dec  6 00:01:33 localhost kernel: tulip0:  Index #0 - Media 10baseT
(#0) described by a 21140 non-MII (0) block.
Dec  6 00:01:33 localhost kernel: tulip0:  Index #1 - Media 100baseTx
(#3) described by a 21140 non-MII (0) block.
Dec  6 00:01:33 localhost kernel: tulip0:  Index #2 - Media
10baseT-FDX (#4) described by a 21140 non-MII (0) block.
Dec  6 00:01:33 localhost kernel: tulip0:  Index #3 - Media
100baseTx-FDX (#5) described by a 21140 non-MII (0) block.
Dec  6 00:01:33 localhost kernel: tulip0:  MII transceiver #1 config
3100 status 782d advertising 05e1.
Dec  6 00:01:33 localhost kernel: eth0: Digital DS21140 Tulip rev 34
at 0xc8903000, 00:60:67:36:21:4F, IRQ 4.
Dec  6 00:01:33 localhost kernel: ip_tables: (C) 2000-2002 Netfilter
core team
Dec  6 00:01:33 localhost kernel: Linux Tulip driver version
0.9.15-pre12 (Aug 9, 2002)
Dec  6 00:01:33 localhost kernel: PCI: Found IRQ 4 for device 00:0d.0
Dec  6 00:01:33 localhost kernel: PCI: Sharing IRQ 4 with 00:04.2
Dec  6 00:01:33 localhost kernel: PCI: Sharing IRQ 4 with 00:04.3
Dec  6 00:01:33 localhost kernel: PCI: Sharing IRQ 4 with 00:09.0
Dec  6 00:01:33 localhost kernel: tulip0: Transceiver selection forced
to 10baseT-FDX.
Dec  6 00:01:33 localhost kernel: tulip0:  EEPROM default media type
Autosense.
Dec  6 00:01:33 localhost kernel: tulip0:  Index #0 - Media 10baseT
(#0) described by a 21140 non-MII (0) block.
Dec  6 00:01:33 localhost kernel: tulip0:  Index #1 - Media 100baseTx
(#3) described by a 21140 non-MII (0) block.
Dec  6 00:01:33 localhost kernel: tulip0:  Index #2 - Media
10baseT-FDX (#4) described by a 21140 non-MII (0) block.
Dec  6 00:01:33 localhost kernel: tulip0:  Index #3 - Media
100baseTx-FDX (#5) described by a 21140 non-MII (0) block.
Dec  6 00:01:33 localhost kernel: tulip0:  MII transceiver #1 config
0100 status 7809 advertising 05e1.
Dec  6 00:01:33 localhost kernel: eth0: Digital DS21140 Tulip rev 34
at 0xc8903000, 00:60:67:36:21:4F, IRQ 4.
Dec  6 00:01:33 localhost kernel: ip_tables: (C) 2000-2002 Netfilter
core team
Dec  6 00:01:33 localhost kernel: eth0: Using user-specified media
10baseT-FDX.
Comment 1 Eric Wiens 2003-12-06 03:30:03 EST
*** Bug 111609 has been marked as a duplicate of this bug. ***
Comment 2 Harald Hoyer 2004-01-29 09:46:13 EST
seems to be a driver issue... reassigning to kernel
Comment 3 Kasper Dupont 2004-02-12 13:59:03 EST
I see the same symptoms but with a different version of the Tulip
Chips. It is a litle strange, because the 21140 works fine for me.

Digital DS21143 Tulip rev 65 doesn't work
Digital DS21140 Tulip rev 34 works fine

Known workaround. Copy the Tulip driver source from Red Hat 7.1 and
compile against Fedora Core 1 kernel headers. The resulting module
works with both revisions.
Comment 4 Kasper Dupont 2004-02-23 17:56:31 EST
Created attachment 97968 [details]
Workaround

Here is the patch I have used to work around the bug. It reverts the tulip
driver to the version used in Red Hat 7.1, the only 2.4 kernel I managed to
find with a working tulip driver. The patch is not intended to be a solution to
the problem, but merely a workaround and hopefully a help to identify the cause
of the problem. I have tested the patch with kernel-2.4.22-1.2166.nptl and
kernel-2.4.22-1.2174.nptl, on three different computers with two different
Tulip chipset revisions.
Comment 5 David Lawrence 2004-09-29 15:48:19 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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