Bug 133150 - x86 and AMD64 kernel detect identical eth's in different order
Summary: x86 and AMD64 kernel detect identical eth's in different order
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Brian Maly
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-09-21 22:17 UTC by Joshua Jensen
Modified: 2007-11-30 22:07 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-03 18:53:55 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Joshua Jensen 2004-09-21 22:17:59 UTC
Description of problem:

On our Rackable Opteron servers, the i686 kernel detects the left-most
tg3 10/100/1000 interface is eth0, the identical NIC on the right is
eth1.  However, the AMD64 version of RHEL3 reverses this order.  This
is true during the installation of RHEL3 and afterwards.

Is this a known problem in the kernel?  What is the fix?

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

RHEL3

Comment 1 David Miller 2004-09-22 02:44:06 UTC
The x86_64 kernel and the i386 kernel probe for PCI
controllers and busses in a different order.

An x86_64 platform export will have to determine whether
1) it is even possible to make x86_64 match i386
   behavior
2) whether that is even desirable

I am not such an export so I'm removing myself from the CC:


Comment 2 Ernie Petrides 2004-09-22 03:13:24 UTC
Ok, reassigning to JimP.


Comment 3 Jim Paradis 2004-09-28 17:41:23 UTC
The RHEL3 i686 and x86_64 kernels use different mechanisms to probe
the PCI bus (i686 probes the bus directly, x86_64 uses ACPI tables). 
As a result the default enumeration of network devices may be different.

If you are going to be going back and forth between the two OSs and
want to force a particular enumeration, you can have the devices
renamed at system startup just prior to being configured.  One way to
do this is to use the GUI net configurator (Main Menu | System
Settings | Network) and   click on the "Hardware" tab.  You can then
edit the entries and set their names to your liking.

Alternatively, you can edit the
/etc/sysconfig/network-scripts/ifcfg-eth* files.  Add to each a line
of the form "HWADDR=xx:xx:xx:xx:xx:xx" specifying the MAC address of
the interface you want to correspond to that particular name.

Closing as WONTFIX since a workaround is available.


Comment 4 Joshua Jensen 2004-09-28 20:03:29 UTC
This isn't a workaround when kickstarting.  There isn't
/etc/sysconfig/anything on the box if linux isn't yet installed.

Think about it from an enterprises perspective.  You have 300+ Opteron
servers.  You have many system admins over the globe.  You have a
standard wiring policy, where you "plug the cable into the leftmost
eth port".  eth0 is always the one on the left, except when you try to
load kickstart with AMD64 RHEL3.  Then kickstarting doesn't work.

I know that changing the way the kernel does things shouldn't be taken
lightly, but if both probing the ACPI tables and probing directly
work, why not just use one method?  Is the difference in  methods
really needed?

Comment 5 Joshua Jensen 2005-01-24 18:38:36 UTC
What is the status of this.  If it can't be changed in either of
kernels, perhaps we should just close this bug.

Comment 6 Joshua Jensen 2005-02-11 20:13:42 UTC
???

Comment 7 Red Hat Bugzilla 2007-03-18 22:25:40 UTC
User jparadis@redhat.com's account has been closed

Comment 8 Joshua Jensen 2007-10-03 18:16:15 UTC
hello?

Comment 9 Brian Maly 2007-10-03 18:53:55 UTC
The development cycle for RHEL3 is long past. Closing this issue accordingly.


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