Bug 167500 - eth1 activates itself
eth1 activates itself
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-03 06:53 EDT by drago01
Modified: 2015-01-04 17:21 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-21 05:41:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
sysreport output (430.41 KB, application/x-bzip2)
2005-09-07 02:06 EDT, drago01
no flags Details
sysreport output (when messages are in dmesg) (393.69 KB, application/x-bzip2)
2005-09-21 15:46 EDT, drago01
no flags Details
firewall script (14.86 KB, text/plain)
2005-09-27 11:12 EDT, drago01
no flags Details

  None (edit)
Description drago01 2005-09-03 06:53:22 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de-DE; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6

Description of problem:
I have two network cards in my system eth0 (forcedeth) and eth1 (r8169).
I use eth0 for my internet connection and have no problems with it.
eth1 is used  for internal network but not often.
When I use it I plug in the cable so I deactivated "active device on boot".
So far it seems to work.
But after sometime the card gets activated and I have such messages in dmesg:
...
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
....
When I use system-config-network the card is activated. 
I can confirm that it does not get active during boot (so no initscript/system-config-network bug)
I am not using Networkmanager.
"Allow user to enable/disable this card" is set to on.


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

How reproducible:
Sometimes

Steps to Reproduce:
1. boot up
2. do anything
3. look at dmesg after some time and you will see this messages.
4. look at system-config-network and you will see that the card is activated.
  

Actual Results:  see above

Expected Results:  nic should only be active when I enable it.

Additional info:

I am using FC4 x86_64.
This problem happens with all FC4 kernels.
Comment 1 John W. Linville 2005-09-06 11:22:04 EDT
I suspect that kudzu is loading that module as part of its probing process, 
and perhaps that module has a bug w.r.t. being unloaded...hmmm... 
 
Please attach the output of running "sysreport"...thanks! 
Comment 2 drago01 2005-09-07 02:04:27 EDT
This can't be the prpblem, because kudzu is disabled.
I am using the firestarter firewall from fc extras (which uses iptables).
Will attach the sysreport output when its finished.
Comment 3 drago01 2005-09-07 02:06:26 EDT
Created attachment 118540 [details]
sysreport output
Comment 4 John W. Linville 2005-09-07 10:20:08 EDT
The driver is being loaded by rc.sysinit.  It happens between "storage" and    
"network" in the line that looks like this:    
    
   Initializing hardware... storage network audio done [ OK ]   
   
When the driver is opened (i.e. "up"), it starts a timer to check the link 
state of the device.  If the link state is invalid, he resets the PHY and 
tries again.  This timer is responsible for printing the messages you are 
seeing.  If you plug-in the network (but don't do anything else) does the 
message go away?  When the messages stop, does eth1 have an IP address?  
 
Your ifconfig data shows that the device is "down" and has no IP address.   
In that case, the timer should never have been activated in the first place 
and the message should have never appeared.  Could you send another sysreport?  
This time, be absolutely sure to wait until the messages have started 
appearing before starting sysreport...thanks! 
Comment 6 drago01 2005-09-08 06:34:22 EDT
ok will send you a sysreport when the message come again...
will also try to plug in a cable to see if it goes away...
the problem is that sometimes they come immediately after boot ... sometimes
after some hours and sometimes never...
Comment 7 drago01 2005-09-17 01:55:26 EDT
the messages seems to be gone dunno why.
(still using the same set of packages and same hw)
Comment 8 John W. Linville 2005-09-19 10:06:38 EDT
Hmmm...well, it is hard to analyze a problem that has disappeared... :-)  
  
I'm moving this to CANTFIX for now.  If the problem reappears, feel free to  
reopen this issue with the information requested in comment 4.  Thanks! 
Comment 9 drago01 2005-09-21 15:43:55 EDT
it happend again... I also have found this in dmesg:
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
Losing some ticks... checking if CPU frequency changed.
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
r8169: eth1: PHY reset until link up
...
sysreport output will be attached after this comment.
Comment 10 drago01 2005-09-21 15:46:25 EDT
Created attachment 119095 [details]
sysreport output (when messages are in dmesg)
Comment 11 drago01 2005-09-21 15:50:21 EDT
when I plug in a cable it says:
r8169: eth1: link up
and the message stops.
Comment 12 drago01 2005-09-24 05:37:25 EDT
same problem in 2.6.13-1.1525_FC4
Comment 13 John W. Linville 2005-09-27 10:40:33 EDT
The sysreport info from comment 10 indicates that eth1 is "up", with an IP 
assigned, etc.  If this occurs with no link plugged-in, you will see the 
messages in question. 
 
It seems clear that something is invoking "ifup eth1" (or the equivalent) for 
this to happen.  I don't know what triggers that.  Perhaps you have a cron job 
or some other script that is doing that? 
 
I'm pretty sure (100%) that the kernel is not invoking "ifup eth1".  Can you 
narrow-down what else is happening that might invoke "ifup eth1"? 
Comment 14 drago01 2005-09-27 10:47:26 EDT
I don't have any cron job that does ifup eth1 (why should I create such one?)
I am not using Networkmanager/ifplugd or any other such service.
The only network related settings that I have made are the firestarter firewall
and the settings in system-config-network.
Comment 15 John W. Linville 2005-09-27 11:06:31 EDT
"cron job or some other script" -- I have no idea what you might have on your   
system or what kinds of convenience scripts you might have.  I was only trying   
to make a helpful suggestion.   
   
The behaviour you have observed is expected with the driver in question when   
it is marked as "up" without the cable plugged-in.  This is not a kernel   
issue.  Given that, I was hoping you might provide further information to help   
me to redirect this issue to someone appropriate.  
  
I know nothing about the Firestarter software.  Upon initial inspection, it  
seems at least possible that it might be activating your network ports.  Have  
you tried disabling Firestarter?  
Comment 16 drago01 2005-09-27 11:12:43 EDT
Created attachment 119299 [details]
firewall script

Firestarte is a firewall based on iptables which is in FC Extras.
I have attached the script so that you can see if anything in it can be causing
this.
Comment 18 Bill Nottingham 2005-09-27 14:29:24 EDT
What version of initscripts do you have? Also, does it go away if you add the
hardware address of the cards to your ifcfg file?
Comment 19 drago01 2005-09-28 12:09:47 EDT
I am using initscripts-8.11.1-1.
Have added the mac address to the ifcfg file...
Will report if its gone or not...
Comment 20 drago01 2005-09-28 13:42:06 EDT
happend again with the mac addr in ifcfg:
-----------------
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
IPV6INIT=no
ONBOOT=no
USERCTL=yes
PEERDNS=yes
TYPE=Ethernet
DEVICE=eth1
BOOTPROTO=none
NETMASK=255.255.255.0
IPADDR=192.168.0.1
HWADDR=00:11:09:e9:9b:d2
-----------
this time it seems to happend on boot:
---------------------
agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
eth1: PHY reset until link up
ip_tables: (C) 2000-2002 Netfilter core team
ip_conntrack version 2.1 (4095 buckets, 32760 max) - 336 bytes per conntrack
w83627hf 2-0290: Reading VID from GPIO5
eth1: PHY reset until link up
NET: Registered protocol family 10
Disabled Privacy Extensions on device ffffffff8051fae0(lo)
IPv6 over IPv4 tunneling driver
eth1: PHY reset until link up
eth0: no IPv6 routers present
eth1: no IPv6 routers present
eth1: PHY reset until link up
eth1: PHY reset until link up
application mixer_applet2 uses obsolete OSS audio interface
eth1: PHY reset until link up
eth1: PHY reset until link up
eth1: PHY reset until link up
eth1: PHY reset until link up
eth1: PHY reset until link up
eth1: PHY reset until link up
eth1: PHY reset until link up
eth1: PHY reset until link up
eth1: PHY reset until link up
-------------
Comment 21 Bill Nottingham 2005-09-28 13:48:09 EDT
And, presumably at this point, it has an IP?

Unfortunately, it's somewhat tricky to determine where it's being brought up from.

One way could be adding a call at the top of ifup-eth that dumps the process
tree (ps axf) to a file in /dev (which should always be writable.)

I.e., change:

if [ "${BOOTPROTO}" = "bootp" -o "${BOOTPROTO}" = "dhcp" ]; then
    DYNCONFIG=true
fi

# load the module associated with that device

to:
if [ "${BOOTPROTO}" = "bootp" -o "${BOOTPROTO}" = "dhcp" ]; then
    DYNCONFIG=true
fi

ps axf > /dev/ifup.$$

# load the module associated with that device

If you could then attach all the ifup.$$ that are available when this issue
happens, we might then be able to determine what's spawning ifup.
Comment 22 drago01 2005-09-28 13:53:36 EDT
yes it gets an IP....
will try your suggestion now..
Comment 23 drago01 2005-09-28 14:00:07 EDT
this seems to create an unreadable file in /dev/ (for eth0 this time eth1 is
still down)
cat /dev/ifup.18
cat: /dev/ifup.18: No such file or directory
Comment 24 Bill Nottingham 2005-09-28 14:02:53 EDT
Shouldn't be unreadable. Hmm. Does it just have permissions to only be read by root?
Comment 25 drago01 2005-09-28 14:12:47 EDT
tryed as root...
 stat /dev/ifup.18
stat: cannot stat `/dev/ifup.18': No such file or directory
no messages in /var/log/audit/audit.log (so no selinux issue)
Comment 26 Bill Nottingham 2005-09-28 15:17:32 EDT
If it doesn't exist, where are you getting the .18 filename from?
Comment 27 drago01 2005-09-29 12:02:35 EDT
I got it by using cat /dev/ifu<tab>
Comment 28 Bill Nottingham 2005-09-29 13:29:39 EDT
So, there's no other /dev/ifup*  files? I don't see how it would make an
unreadable one.
Comment 29 Dave Jones 2005-09-30 03:08:21 EDT
Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (2.6.13.2). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.

Thanks.
Comment 30 Dave Jones 2005-11-10 15:14:03 EST
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.

Thank you.
Comment 31 drago01 2006-01-21 05:41:44 EST
the bug seems to be fixed now (dunno what was causing it)

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