ANNOUNCE: bios_dev_name tool, 0.1 release

Thu Nov 30 14:29:55 CST 2006

Hi Michael,

  Granted and sorry to be ignorant but the 9th gen machines were the
only Dell servers I've worked with that had this particular quirk. In
any case thanks for anything that fixes this because it does confuse
people.

regards,
Greg

On Thu, 2006-11-30 at 14:13 -0600, Michael_E_Brown at dell.com wrote:
> There is no generic way to fix this problem in hardware. The problem is
> defined as "I have a printed label on the back of the system that I need
> to match with an OS name." That OS could be a Windows (2000, 2003, XP,
> vista) or Linux (2.4, 2.6) or some other OS and each OS uses different
> ordering rules for how it searches the PCI bus and names the devices.
> The physical way that you lay out the PCB for one OS can break the other
> OS, depending on the variations in how each scans the PCI bus.
> 
> There is no way in hardware to make sure that all the possible
> variations on software look up the hardware in the same way. The best we
> can do is define a BIOS extention that would let us program this (paper
> label to hardware) mapping and use a tool like bios_dev_name to set the
> OS name.
> --
> Michael
> 
> > -----Original Message-----
> > From: linux-poweredge-bounces at dell.com 
> > [mailto:linux-poweredge-bounces at dell.com] On Behalf Of Greg Dickie
> > Sent: Wednesday, November 29, 2006 6:28 PM
> > To: Domsch, Matt
> > Cc: linux-poweredge-Lists
> > Subject: Re: ANNOUNCE: bios_dev_name tool, 0.1 release
> > 
> > 
> > Thanks for all these options Matt but I have to ask the 
> > obvious "couldn't it have been fixed in hardware?" (clearly 
> > I've been in software too long ;-)
> > 
> > Greg 
> > 
> > On Wed, 2006-11-29 at 17:15 -0600, Matt Domsch wrote:
> > > You may recall several months ago a problem I faced, where the 
> > > BIOS-given name for an ethernet device (e.g. "Gb1") didn't 
> > map to the 
> > > expected and obvious Linux device name (e.g. eth0), but 
> > instead mapped 
> > > to another name (e.g. eth1).  This was highly confusing to system 
> > > admins with such hardware.
> > > 
> > > Since then, I've developed 3 separate "fixes" - each more 
> > generic than 
> > > the last.
> > > 
> > > 1) a kernel patch in 2.6.19-rc3, which implements a "pci=bfsort"
> > >    option, to force the kernel to enumerate devices in a 
> > breadth-first
> > >    manner; by default disabled on all but a few Dell 
> > systems.  This is
> > >    the "brute force" method, and while handy, isn't very 
> > extensible or
> > >    flexible.
> > > 
> > > 2) name_eths (http://linux.dell.com/files/name_eths), a set 
> > of scripts
> > >    that modifies on-disk config files
> > >    (/etc/sysconfig/network-scripts/ifcfg-eth* HWADDR lines 
> > on Red Hat
> > >    / Fedora systems; /etc/udev/rules.d/30-net_persistent_names rules
> > >    on SLES/OpenSuSE).  This uses the BIOS PCI IRQ routing 
> > table to get
> > >    the list of embedded vs add-in devices, and assigns names to the
> > >    embedded devices first (breadth-first if there are several), then
> > >    to the add-ins, in PCI slot number ascending order (breadth-first
> > >    if there are several devices in the same slot, e.g. a 
> > multiport NIC
> > >    card) and works quite well, except in a diskless 
> > environment where
> > >    you can't read/write config files.
> > > 
> > > so now, option 3:
> > > 
> > > 3) bios_dev_name (http://linux.dell.com/files/bios_dev_name) -
> > >    intended to be a udev helper.  For example, something like:
> > > 
> > > KERNEL=="eth*", ACTION=="add", 
> > PROGRAM="/usr/sbin/bios_dev_name -i %k", NAME="%c"
> > > 
> > > which, given the kernel's name for a device, retreives the 
> > > BIOS-expected name, and sets it to that.  Alternately, it can be 
> > > integrated into SuSE's rename_netiface script as 
> > demonstrated in the 
> > > patch included in the release.  As a udev helper, it doesn't need 
> > > config files to accomplish its work.
> > > 
> > > Right now #1 uses a hard-coded breadth-first search 
> > algorithm; #2 uses 
> > > the PCI IRQ routing table and breadth-first.  #3 is the same as #2 
> > > algorithm-wise, but is written in C rather than perl/shell 
> > to be more 
> > > available as a udev helper.
> > > 
> > > In the future, the SMBIOS Working Group has a proposal to 
> > add explicit 
> > > BIOS device naming assignments to the SMBIOS tables.  This will let 
> > > the OS query SMBIOS directly to find out the name a given device 
> > > "should" have (from the BIOS perspective).  I expect 
> > bios_dev_name to 
> > > be able to take advantage of this when included in the spec and 
> > > implemented in system BIOS.
> > > 
> > > It's also expected that additional device types will be handled, 
> > > rather than only ethernet devices.  That'll depend on need.
> > > 
> > > bios_dev_name is released under the GNU GPL v2.
> > > http://linux.dell.com/files/bios_dev_name/bios_dev_name-0.1.tar.gz
> > > 
> > http://linux.dell.com/files/bios_dev_name/bios_dev_name-0.1.tar.gz.sig
> > > n
> > > 
> > > 
> > > Feedback welcome.
> > > 
> > > Thanks,
> > > Matt
> > > 
> > --
> > Greg Dickie
> > just a guy
> > Maximum Throughput
> > 
> > _______________________________________________
> > Linux-PowerEdge mailing list
> > Linux-PowerEdge at dell.com
> > http://lists.us.dell.com/mailman/listinfo/linux-poweredge
> > Please read the FAQ at http://lists.us.dell.com/faq
> > 
> 
> _______________________________________________
> Linux-PowerEdge mailing list
> Linux-PowerEdge at dell.com
> http://lists.us.dell.com/mailman/listinfo/linux-poweredge
> Please read the FAQ at http://lists.us.dell.com/faq
-- 
Greg Dickie
just a guy
Maximum Throughput