Description of problem: http://marc.theaimsgroup.com/?l=linux-kernel&m=115774419608542&w=2 Problem: New Dell PowerEdge servers have 2 embedded ethernet ports, which are labeled NIC1 and NIC2 on the chassis, in the BIOS setup screens, and in the printed documentation. Assuming no other add-in ethernet ports in the system, Linux 2.4 kernels name these eth0 and eth1 respectively. Many people have come to expect this naming. Linux 2.6 kernels name these eth1 and eth0 respectively (backwards from expectations). I also have reports that various Sun and HP servers have similar behavior. Patch in the URL above, as well as ongoing discussion as to whether or not it should really be applied. DaveJ has participated in the thread. I'd like to see this patch applied for FC6 so people with new x9xx PowerEdge servers and FC6 won't have the mis-enumeration. I also expect you'll want the extra testing FCtest brings to this issue before applying it for RHEL5. Separately, I'm still working on a tool that could let anaconda and the initscripts/udev do the proper naming, and hope to have something usable this week or so. Thanks, Matt
I still have the same concerns about breaking existing setups. I want to see this sit in -mm for a while before we put it in Fedora.
I expect this would also re-order the list of storage devices that Anaconda would see? If it is, and it now sees the same storage devices as the BIOS sees as first, that would be good. Or is this only for network devices?
It's not only for NICs, no. However, we have EDD and unique MBR signatures anaconda can use already to solve the storage problem.
davej, what if instead we made it a kernel command line option to enable with default being disabled? Rather than default enabled with option 'pci=nosort', I could easily default disabled, with option 'pci=bfsort'. How would you feel about that for FC6? Thanks, Matt
sounds safe to me.
Matt, I think that the patch would benefit upstream kernel as well. If possible, please post it on LKML as well.
IMHO this is a udev problem. We already have pci=reverse btw but be aware that several drivers turn out to make mistakes about device ordering if you do this, and I suspect a pci=nosort would have a similar failure set.
I've already gotten failure reports when this hit -mm. :-( I've asked it be dropped again from there. I'm going to proceed down a different path, which is to let the kernel do its thing, but let a udev helper / anaconda-callable library app return the "right" name as BIOS would see it. Then it's pretty easily extensible. First pass sorts the ethernet devices by embedded vs add-in; subsort PCI breadth-first. Enumerate all embeddeds, then enumerate devices in the slots 1..N, breadth-first in the slots. Second pass will require an SMBIOS spec extension (which I've got BIOS guys on the SMBIOS committee, so that should happen), to let BIOS explicitly give its naming for each device. Then the app can use that info if available (falling back otherwise) to do the naming. I'll close this request for now, as #204945 is open following this userspace solution.
Re-opening, now that a modified version has been in -mm since 2006-09-30. http://marc.theaimsgroup.com/?l=linux-mm-commits&m=115958255609603&w=2 This adds pci=bfsort and pci=nobfsort (the default), and uses DMI entries to enable it for the 4 affected Dell systems for their default. Should be safe for everyone that way.
Created attachment 137863 [details] linux-2.6-pci-bfsort.patch Here's a re-diff of the patch against the FC6-devel rawhide kernel. Had to fix up only the Documentation/kernel-parameters.txt file as upstream has a new pci= entry that 2.6.18 doesn't yet.
I'm fine with this request landing in the 2.6.19 update kernel for FC6 when that's released as it was in upstream for 2.6.19. Then this can be closed.