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.
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!
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.
Created attachment 118540 [details] sysreport output
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!
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...
the messages seems to be gone dunno why. (still using the same set of packages and same hw)
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!
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.
Created attachment 119095 [details] sysreport output (when messages are in dmesg)
when I plug in a cable it says: r8169: eth1: link up and the message stops.
same problem in 2.6.13-1.1525_FC4
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"?
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.
"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?
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.
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?
I am using initscripts-8.11.1-1. Have added the mac address to the ifcfg file... Will report if its gone or not...
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 -------------
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.
yes it gets an IP.... will try your suggestion now..
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
Shouldn't be unreadable. Hmm. Does it just have permissions to only be read by root?
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)
If it doesn't exist, where are you getting the .18 filename from?
I got it by using cat /dev/ifu<tab>
So, there's no other /dev/ifup* files? I don't see how it would make an unreadable one.
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.
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.
the bug seems to be fixed now (dunno what was causing it)