Bug 436456
|
Description
David
2008-03-07 11:22:55 UTC
Okay I have found the kernel is mis labeling the adapters. This server has 3 ethernet adapters. One on board SIS, the other 2 are external cards. For some reason it insists eth0 is now the SIS controller this IS NOT correct. The on board SIS is indeed eth2 Eth0 is really a 100MB realtek card and Eth1 is a 1GB realtek I found if I tell firestarter to use SIS adapter (eth0) it works but the ethernet cable is in the realtek 100MB card. I had to redo my network with eth0 saying its the SIS controller but its really the realtek.. This is going to be messy as when its fixed in the next kernel this will again break the network. So what is happening is eth0 is still eth0 (physically), but for some reason this kernel says its the SIS (eth2). So in networking I have got eth0 saying its the SIS onboard, but set to the IP address I use for the real realtek and the cable is in the realtek. I also experienced this problem after upgrading my kernel this morning. I removed and recreated my network device and I am back up and running. I am running the 64-bit kernel, and am using an nVidia Corporation MCP51 Ethernet Controller (rev a3). do you have HWADDR entries in all the /etc/sysconfig/networking/devices/ifcfg-eth* files ? (In reply to comment #2) > I also experienced this problem after upgrading my kernel this morning. I > removed and recreated my network device and I am back up and running. I am > running the 64-bit kernel, and am using an nVidia Corporation MCP51 Ethernet > Controller (rev a3). Do you have multiple ethernet controllers too? Dave yes I do have HWADDR in the 3 files in /etc/sysconfig/networking/devices/ Also its as I stated eth0 is truly the realtek card not the onboard SIS as networking with this kernel insists... But what I notice is number 0 and 2 don't have the name like 1 does... 0 # Please read /usr/share/doc/initscripts-*/sysconfig.txt # for the documentation of these parameters. GATEWAY=10.0.0.10 TYPE=Ethernet DEVICE=eth0 HWADDR=xxxxxxxxx BOOTPROTO=none NETMASK=255.0.0.0 IPADDR=10.0.0.1 ONBOOT=yes USERCTL=no PEERDNS=yes IPV6INIT=yes NM_CONTROLLED=no 1 # Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet DEVICE=eth1 BOOTPROTO=none BROADCAST=192.168.0.255 HWADDR=xxxxxxxx IPADDR=192.168.0.1 IPV6INIT=yes IPV6_AUTOCONF=yes NETMASK=255.255.255.0 NETWORK=192.168.0.0 ONBOOT=yes TYPE=Ethernet NM_CONTROLLED=no USERCTL=no PEERDNS=yes 2 # Please read /usr/share/doc/initscripts-*/sysconfig.txt # for the documentation of these parameters. TYPE=Ethernet DEVICE=eth2 HWADDR=xxxxxxxxx BOOTPROTO=none NETMASK=255.255.0.0 IPADDR=172.16.0.1 ONBOOT=no USERCTL=no PEERDNS=yes IPV6INIT=no NM_CONTROLLED=no ISTR Bill diagnosed a similar problem (if not the same) as this a few months back. Bill, any ideas ? I actually now have another server with two nics in it and its also got this problem. I have to reset the network card details and reset firestarter. I tried this over the phone (its a remote server) but cant get firestarter up yet. I will visit later. But this proves yet another working machine until this kernel and networking breaks to bits, this machine only has two nics. I have two network cards on board. I was not able to get even one of them to work. I don't need two network cards, so I disabled one of them in BIOS and now the other works fine. Everyone who has reported this bug: please reply with the exact module names used by each of your network adapters, (for example 8139too, sis900, etc.) Also please post the full set of boot messages (from /var/log/dmesg) from the old and new kernels. Created attachment 297516 [details]
This is off the new 2.6.24.3-12 kernel
My cards are: PCI card (true Eth1) # Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet PCI card (true Eth0) # Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ Onboard (true Eth2) # Silicon Integrated Systems (SIS) SiS900 PCI Fast Ethernet For my situation I still cant understand why the kernel now insists the SiS onboard is now Eth0, when it has always been the LAST PCI card. Its like now this kernel decides to put onboard PCI at a higher priority. This is a bad practice as regardless if anyone thinks onboard should go first not last, it has always been last since I started back on FC6 with every kernel and to suddenly change this breaks stuff big time. The problem for me, this is a gateway server serving WAN and bridging our web / ftp / dns and mailservers to the WAN. If you really need my /var/log/dmesg from the previous kernel I will have to schedule a time as it will put Eth0 back the the proper Realtek 8139 and break the network. What is in /etc/udev/rules.d/70-persistent-net.rules and does it match up with the original ifcfg-ethX files?
# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.
# Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:0c:6e:2b:c8:57", ATTR{type}=="1", NAME="eth2"
# Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:40:f4:a9:d5:4d", ATTR{type}=="1", NAME="eth1"
# Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:05:1c:1c:22:5f", ATTR{type}=="1", NAME="eth0"
Yes this is correct - see that Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ is eth0.... and the Sis is eth2.
Is the order meant to be backwards from eth2, eth1 and eth0 or this is not relevant?
From reading the dmesg output you posted, it *looks* like it correctly renamed the 8139too device to eth0 on boot. See: eth2: RealTek RTL8139 at 0xf89de000, 00:05:1c:1c:22:5f, IRQ 21 eth2: Identified 8139 chip type 'RTL-8100B/8139D' udev: renamed network interface eth2 to eth0 udev: renamed network interface eth0_rename to eth2 Is this not taking effect? Created attachment 297572 [details]
network config - eth0 - edit - hardware tab (note it carefully)
network config - eth0 - edit - hardware tab (note it carefully)
Created attachment 297573 [details]
network config - eth1 - edit - hardware tab (see this is correct)
Created attachment 297574 [details]
network config - eth2 - edit - hardware tab (note it carefully)
Created attachment 297575 [details]
This is the plain hardware tab out of networking, again note the reversed eth0 and eth2!
What's the output of 'ifconfig -a'? Created attachment 297667 [details]
outputs 2.6.23.15-137.fc8
I hope there is something useful within.
Created attachment 297668 [details]
outputs 2.6.24.3-12.fc8
Created attachment 297669 [details]
outputs 2.6.24.3-12.fc8 with only one network adapter
'Alias' - I see nothing wrong with your config or setup in either case. Yes your right. This is a bit confusing and was a waste of time, because I didn't reconfigure the configs with kernel 2.6.23.15-137.fc8 This was my fault. Sorry. Bill,
Here is dump of ifconfig -a as requested:
eth0 Link encap:Ethernet HWaddr 00:05:1C:1C:22:5F
inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.0.0.0
inet6 addr: fe80::205:1cff:fe1c:225f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2328233 errors:1 dropped:1 overruns:1 frame:0
TX packets:2703484 errors:0 dropped:0 overruns:1 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1143370458 (1.0 GiB) TX bytes:783084918 (746.8 MiB)
Interrupt:21 Base address:0xe000
eth1 Link encap:Ethernet HWaddr 00:40:F4:A9:D5:4D
inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::240:f4ff:fea9:d54d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2688392 errors:0 dropped:0 overruns:0 frame:0
TX packets:2373412 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:779606708 (743.4 MiB) TX bytes:1172915664 (1.0 GiB)
Interrupt:23 Base address:0x8000
eth2 Link encap:Ethernet HWaddr 00:0C:6E:2B:C8:57
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:23 Base address:0x8800
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:11860 errors:0 dropped:0 overruns:0 frame:0
TX packets:11860 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3854034 (3.6 MiB) TX bytes:3854034 (3.6 MiB)
See its weird ifconfig agrees that eth0 is the realtek 8139 WAN card and eth2 is
the onboard SiS (can see by the macs), but why does networking gui show them up
as reversed?
OK, so this is merely a system-config-network problem - the system is operating correctly with the right interface with the right address (at least, as much as it's configured.) Reassigning. *** Bug 437016 has been marked as a duplicate of this bug. *** *** Bug 436957 has been marked as a duplicate of this bug. *** (In reply to comment #26) > Bill, > > Here is dump of ifconfig -a as requested: > I assume that was from 2.6.24? If so please post what 2.6.23 says. It looks like HAL has the interface right but the rename was failing in 2.6.23. system-config-network somehow picked up the reversed names because HAL assumed the name change worked when it didn't. This should really be a HAL bug, because it didn't check if the rename was working?? Created attachment 297895 [details]
ifconfig -a dump for 3 kernels
I attached "ifconfig -a" dump for three kernels: 2.6.24.3-12.fc8,
2.6.23.15-137.fc8, and 2.6.20-1.2320.fc5 (the same hardware). This bug pops up
when 2.6.24.3-12.fc8 in use.
That seems the same for all three kernels, which implies the underlying infrastructure is working. Created attachment 297954 [details]
double device entry after reboot in "Network Configuration"
The "Network Configuration" dialog shows me third entry created automatically
on reboot for "third" *Active* device (duplicate of eth1). I have changed
nicknames manualy. Before the nickname change, with the default nicknames, the
third automatic entry was getting "eth1.bak" nickname generated.
The hardware tab has two entries where the "Descriptions" are switched between,
similar to the above.
Dear RedHat Guys/Ladies: My computer shows the bug with two on-board cards. I can make extra experiments if there is a chance that it could help you to figure out what is wrong. I have two spare PCI cards, spare PCI slots on the board, and enough cables. I can boot the computer with 1-2-3-4 cards and provide outputs if it can be useful, provided you tell me what you want exactly. This bug is especially annoying if you have both wired and wireless connections. If the interfaces gets switced, the wired network interface will get configuration options for the wireless card and vice versa. The drivers used according to lspci is: 02:02.0 Network controller: Intel Corporation PRO/Wireless 2200BG Network Connection (rev 05) 02:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VE (MOB) Ethernet Controller (rev 81) The wireless driver works if I set it up with iwconfig. (I haven't had a chance to test to set up the wired connection with ifconfig yet) installing kernel 2.6.24.3-34 did not help. I got the same results as I reported in bug #436957 It seems that 437619 describes the same problem. with the latest kernel update to 2.6.24.3-50.fc8 the problem on my computer had disappeared, but the same installation booted with previous kernel 2.6.24.3-34.fc8 shows the same described above problem. After installing 2.6.24.3-50 also the problems I reported in bug #436957 did not occur anymore. Jouk After installing 2.6.24.4-64 for x86_64 the problem still remains on my computer. I hope that the problem can be fixed soon. system-config-network-1.5.5-1.fc8 has been submitted as an update for Fedora 8 system-config-network-1.5.5-1.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update system-config-network'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-2995 system-config-network-1.5.5-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report. |