So here's an interesting one after one reboot. All configured and enabled on boot but only one is plugged in to the switch.
ifcfg-eth0 - realteak 8139 Fibre w/ HWADDR ifcfg-eth1 - 82545EM (onboard) w/ HWADDR - plugged in, 192 network ifcfg-eth2 - 82545EM (onboard) w/ HWADDR ifcfg-eth3 - 82545EM (onboard) w/ HWADDR dmesg shows: e1000: eth0: e1000_probe: Intel PRO/1000 eth1: Realtek RTL8139 at 0xf88ae400, 00:e0:b3:10:35:43 eth1: Identified 8139 chip type 'RTL-8139C' eth1000: eth2: e1000_probe: Intel PRO/1000 eth1000: eth3: e1000_probe: Intel PRO/1000 eth0: link up, 100Mbps, full-duplex, lpa 0x4181 E1000: eth1: e1000_watchdog_task, NIC Link is Up 100 Mbps ... ADDRCONF(NETDEV_UP): eth2: link is not ready ADDRCONF(NETDEV_UP): eth3: link is not ready eth0: no IPV6 routers present eth1: no IPV6 routers present Hwconf show: eth0 - 8139too eth1 - 82545EM (onboard) eth3 - 82546GB (port of dual nic addon) eth2 - 82546GB (port of dual nic addon) Modprobe.conf file: alias eth0 e1000 alias eth1 e1000 alias eth2 e1000 alias eth3 8139too The interesting thing is that if I ping 192 network, it returns good ping. So The fact the /var/log/messages (dmesg) tells me that eth1 is the realtek and it even gives the correct MAC address, one would be lead to believe that it would load the Realteak driver to eth1; be it that we tell it in the modprobe.conf to load the realtek driver to eth0. And after a bunch more rebooting (I think I've reboot these boxes over 200 times and rebuilt it like 50 times...) -- it would seems that if you include HWADDR in the ifcfg, everything works fine except that you can't trust /var/log/messages and modprobe.conf is ignored. Does this sound right to everyone? Would anyone care to volunteer to open a bugzilla report (believe it or not, I don't actually have a bugzilla account!)? (BTW, there are more responses below; quoted) Thanks, Dan Long PDSS CCTT > -----Original Message----- > Behalf Of Bogdan Costescu > > While not having tested RHEL 5.2 yet, I think that the most > likely cause is not the PCI device detection but the order in > which modules are loaded - with udev there is no fixed > loading order guaranteed, or at least that's my impression. > > > I'm afraid you're stuck with using HWADDR in the ifcfg-eth* files > > Be happy that these exist and you don't have to write udev rules ;-) We considered udev rules. I think most of them are in the 70 or 75-network.rules? We do use udev rules for some other stuff for our application. > -----Original Message----- > On Behalf Of John Haxby > > We suspect that this random behaviour will > become the norm in future. That's very unforunate. Our particular environment -- hardware tech do hardware and software tech do software. Currently when a NIC fails, the the hardware tech replaces it (same brand, same slot) and everything is okay. If there is no "fix" and when we move forward, I guess we would need to get software tech involved. Big head-ache -- either new contract or contract rewrites ... plus release notes and new documentation ... sigh ... > -----Original Message----- > On Behalf Of Bernd Bartmann > > On Thu, Jun 26, 2008 at 8:31 AM, Zavodsky, Daniel wrote: > > Hello, > > Actually after upgrading from 5.1 to 5.2 the problem occurs on > > our machines too. We have to add HWADDR lines for each net > > interface into the config files. 5.1 did not have this problem. > > We have the same problem here, but even if we set HWADDR set > inferfaces get mixed up at each reboot. > In our case we have the via.rhine module for eth0 and the > sundance module for a 4-port network card, i.e. eth1 - eth4. > > Also, the problem seems to be somehow related to the init > scripts and not to the kernel as the same problem now occurs > if we go back to the last 5.1 kernel. We saw this problem in 5.1 and downloaded 5.2 in hopes that it was resolved. Obviously it has not. But if you rebuilt the whole machine with 5.1 instead of just going back to the old kernel, do you see the problem? > Did someone already open a bugzilla ticket on this issue? I have not but I also didn't check bugzilla .... Has anyone opened one or check?. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dan Long > Sent: Wednesday, June 25, 2008 3:32 PM > To: Red Hat Enterprise Linux 5 (Tikanga) discussion mailing-list > Subject: RE: [rhelv5-list] Vexing Behavior: RHEL 5.2 > (2.6.18-92) Random NICEnumeration Between Reboots > > Correction: The 'dmesg' output does not match that of the > hwconf file. > As a matter of fact, working on the assumption that there is > no solution to our problem and that embedding HWADDR in ifcfg > is the only option -- we left HWADDR in place; what we found > was that the hwconf file does stay consistent (hurray!) but > the dmesg still changes between reboots (BOOO!). > > Thanks, > > Dan > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dan Long > Sent: Wednesday, June 25, 2008 9:32 PM > To: Red Hat Enterprise Linux 5 (Tikanga) discussion mailing-list > Subject: RE: [rhelv5-list] Vexing Behavior: RHEL 5.2 > (2.6.18-92) Random NICEnumeration Between Reboots > > Correction: The 'dmesg' output does not match that of the > hwconf file. > As a matter of fact, working on the assumption that there is > no solution to our problem and that embedding HWADDR in ifcfg > is the only option -- we left HWADDR in place; what we found > was that the hwconf file does stay consistent (hurray!) but > the dmesg still changes between reboots (BOOO!). > > Thanks, > > Dan > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dan Long > Sent: Wednesday, June 25, 2008 2:43 PM > To: rhelv5-list@redhat.com > Subject: [rhelv5-list] Vexing Behavior: RHEL 5.2 (2.6.18-92) > Random NICEnumeration Between Reboots > > Moving from RHEL 4 U3 to RHEL 5.2 (2.6.18-92). This is a > really odd problem and we have NO idea what could be causing > it -- we do not have this problem in RHEL 4 U3. > > The problem that we are encountering on RHEL 5 is that if we > remove the HWADDR from the ifcfg-eth* file, we get random NIC > enumeration between reboots. We have 4 NICs (1 on-board > (Intel 82545EM), 1 fibre (Realtek > 8139), and a dual-nic add-on (Intel 82546GB). Fresh RHEL 5 > installation and manually configuring the network settings > via ifcfg-eth we would have : > > The ifcfg-eth* files: > # Card Manufacturer/Description > DEVICE= > HWADDR= > ONBOOT= > IPADDR= > NETMASK= > > And the modprobe.conf file: > alias eth0 8139too > alias eth1 e1000 > alias eth2 e1000 > alias eth3 e1000 > > The hwconf file: > eth0 - realtek > eth1 - 82545EM > eth2 - 82546GB > eth3 - 82546GB > > But after a reboot the hwconf file would have: > eth0 - 82545EM > eth1 - realtek > eth2 - 82546GB > eth3 - 82546GB > > As expected, the modprobe.conf and the ifcfg-eth* stays the same. > "dmesg |grep eth" follows the hwconf file. > > In RHEL4 we use modprobe.conf to assign the realtek to eth3 > with the 'alias' parameter. As you can see, this can be a > problem when ifcfg-eth0 is configured for network-A and > ifcfg-eth3 is assigned to network-B but after a reboot they > are swapped around. > > Not only that but successive reboots rearranges the > enumeration in other > orders (the realtek is on eth1 or the 82545EM is on eth3). After > several days of reading and searching the various forums, I > have not seen a single instance of this problem. The closest > instance seems to > be: > http://linux.dell.com/files/whitepapers/nic-enum-whitepaper-v3.pdf > > However, the whitepaper describes an issue where the > enumeration is different when the hardware changes. Where as > our problem has no hardware or software changes other > rebooting the system. As such using the kernel parameter > 'pci=bfsort' or 'pci=nobfsort' has no effect on our problem. > I have tried another computer with just two NICs (one onboard > and one fibre) and same problem occurs; some reboots changes > the order others doesn't. > > We wish to avoid hard coding MAC addresses to the NICs. > > Any suggestions or ideas or need more information? Thanks! > > > Sincerely, > > Dan Long > PDSS CCTT _______________________________________________ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
