biosdevname v0.3.2

biosdevname v0.3.2

[Matt Domsch]

Bugfix update to biosdevname, now version 0.3.2.

The legacy code for reading the PCI IRQ Routing Table ($PIR) and the
PCMCIA information has been removed.  This means biosdevname will only
report BIOS-provided names if your system has SMBIOS 2.6 or higher and
has the information in Type 9 or Type 41.  This is in preparation for
widespread use, and will keep biosdevname from suggesting names on
systems that are well into or beyond their useful lifetime and
introducing an unexpected change of behavior on them.  Dell PowerEdge
10G and newer, HP ProLiant G6 and newer are known to have SMBIOS 2.6,
as do a number of desktop, laptop, and netbook-class systems as
reported on the fedora-devel mailing list.

This release also provides correct names for Intel and Broadcom
quad-port GigE cards that I've tried.  Format is pci<slot>#<port>.

Grab it here:
http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.2.tar.gz
http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.2.tar.gz.sign
git://linux.dell.com/biosdevname.git

This is already built in Fedora rawhide (will be 15), and I encourage
other distributions to pick it up as well.

On a related note, I've submitted a patch to dracut upstream to
include calls to biosdevname via udev.  This will let us use
BIOS-suggested names for network functionality during initramfs time,
such as finding your root file system on NFS or iSCSI.


Shortlog:

Matt Domsch (7):
      only match on smbios_type Ethernet, ignore sysfs index file for now
      PIRQ-ectomy, add pci_access pointer to state, pci_dev pointer instead of struct in pci_device
      PCMCIA-ectomy
      copy SMBIOS slot info to all matching domain/bus/device/functions
      skip bridges when setting index_in_slot
      fix RPM spec URL
      bump version


Thanks,
Matt

-- 
Matt Domsch
Technology Strategist
Dell | Office of the CTO

Re: biosdevname v0.3.2

[Ben Hutchings]

On Mon, 2010-12-06 at 08:06 -0600, Matt Domsch wrote:
> Bugfix update to biosdevname, now version 0.3.2.
> 
> The legacy code for reading the PCI IRQ Routing Table ($PIR) and the
> PCMCIA information has been removed.  This means biosdevname will only
> report BIOS-provided names if your system has SMBIOS 2.6 or higher and
> has the information in Type 9 or Type 41.  This is in preparation for
> widespread use, and will keep biosdevname from suggesting names on
> systems that are well into or beyond their useful lifetime and
> introducing an unexpected change of behavior on them.  Dell PowerEdge
> 10G and newer, HP ProLiant G6 and newer are known to have SMBIOS 2.6,
> as do a number of desktop, laptop, and netbook-class systems as
> reported on the fedora-devel mailing list.
> 
> This release also provides correct names for Intel and Broadcom
> quad-port GigE cards that I've tried.  Format is pci<slot>#<port>.
[...]

I tried this on a Supermicro board here, which doesn't have this
information.  eth0 and eth1 are LOM ports, eth2 and eth3 are on a NIC.
The debug output is:

BIOS device: 
Kernel name: eth2
Assigned MAC : 00:0F:53:01:41:14
Driver: sfc
Driver version: 3.0
Firmware version: 3.0.8.2217
Bus Info: 0000:01:00.0
PCI name      : 0000:01:00.0
PCI Slot      : Unknown
Index in slot: 7

BIOS device: 
Kernel name: eth3
Assigned MAC : 00:0F:53:01:41:15
Driver: sfc
Driver version: 3.0
Firmware version: 3.0.8.2217
Bus Info: 0000:01:00.1
PCI name      : 0000:01:00.1
PCI Slot      : Unknown
Index in slot: 8

BIOS device: 
Kernel name: eth0
Permanant MAC: 00:30:48:90:81:9E
Assigned MAC : 00:30:48:90:81:9E
Driver: e1000e
Driver version: 1.2.7-k2
Firmware version: 0.15-4
Bus Info: 0000:0d:00.0
PCI name      : 0000:0d:00.0
PCI Slot      : Unknown
Index in slot: 9

BIOS device: 
Kernel name: eth1
Permanant MAC: 00:30:48:90:81:9F
Assigned MAC : 00:30:48:90:81:9F
Driver: e1000e
Driver version: 1.2.7-k2
Firmware version: 0.5-7
Bus Info: 0000:0e:00.0
PCI name      : 0000:0e:00.0
PCI Slot      : Unknown
Index in slot: 10

It appears that 'unknown slot' is treated as a specific slot and all
devices with an unknown slot are given unique indices.  Perhaps this
doesn't matter in the end, since no name is generated when the slot is
unknown.

However, the 2 NIC ports do have their own indices (specified with the
dev_id attribute) and it should be possible to distinguish slots by
PCI/PCIe topology even though the name given won't correspond to any
markings on the motherboard.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: biosdevname v0.3.2

[Matt Domsch]

On Tue, Dec 07, 2010 at 06:16:22PM +0000, Ben Hutchings wrote:
> It appears that 'unknown slot' is treated as a specific slot and all
> devices with an unknown slot are given unique indices.  Perhaps this
> doesn't matter in the end, since no name is generated when the slot is
> unknown.

Yes on all counts.
 
> However, the 2 NIC ports do have their own indices (specified with the
> dev_id attribute) and it should be possible to distinguish slots by
> PCI/PCIe topology even though the name given won't correspond to any
> markings on the motherboard.

Tell me more about the dev_id attribute.  I'm happy to use it, but I
don't understand the rules around populating it.

Thanks,
Matt

-- 
Matt Domsch
Technology Strategist
Dell | Office of the CTO

Re: biosdevname v0.3.2

[Ben Hutchings]

On Tue, 2010-12-07 at 12:19 -0600, Matt Domsch wrote:
> On Tue, Dec 07, 2010 at 06:16:22PM +0000, Ben Hutchings wrote:
> > It appears that 'unknown slot' is treated as a specific slot and all
> > devices with an unknown slot are given unique indices.  Perhaps this
> > doesn't matter in the end, since no name is generated when the slot is
> > unknown.
> 
> Yes on all counts.
>  
> > However, the 2 NIC ports do have their own indices (specified with the
> > dev_id attribute) and it should be possible to distinguish slots by
> > PCI/PCIe topology even though the name given won't correspond to any
> > markings on the motherboard.
> 
> Tell me more about the dev_id attribute.  I'm happy to use it, but I
> don't understand the rules around populating it.

As I understand it, dev_id is supposed to distinguish net devices
corresponding to multiple ports on a single network controller.
However, a value of 0 could mean either 'unspecified' or 'first port' so
you would have to verify that multiple net devices for the same slot
have unique dev_id values before taking them into account.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: biosdevname v0.3.2

[Matt Domsch]

On Tue, Dec 07, 2010 at 06:41:22PM +0000, Ben Hutchings wrote:
> On Tue, 2010-12-07 at 12:19 -0600, Matt Domsch wrote:
> > On Tue, Dec 07, 2010 at 06:16:22PM +0000, Ben Hutchings wrote:
> > > It appears that 'unknown slot' is treated as a specific slot and all
> > > devices with an unknown slot are given unique indices.  Perhaps this
> > > doesn't matter in the end, since no name is generated when the slot is
> > > unknown.
> > 
> > Yes on all counts.
> >  
> > > However, the 2 NIC ports do have their own indices (specified with the
> > > dev_id attribute) and it should be possible to distinguish slots by
> > > PCI/PCIe topology even though the name given won't correspond to any
> > > markings on the motherboard.
> > 
> > Tell me more about the dev_id attribute.  I'm happy to use it, but I
> > don't understand the rules around populating it.
> 
> As I understand it, dev_id is supposed to distinguish net devices
> corresponding to multiple ports on a single network controller.
> However, a value of 0 could mean either 'unspecified' or 'first port' so
> you would have to verify that multiple net devices for the same slot
> have unique dev_id values before taking them into account.

Only a handful of drivers seem to populate dev_id that I can find:

[drivers/net]$ grep -r -- '->dev_id' *
cxgb4/t4_hw.c:		 adap->port[i]->dev_id = j;
mlx4/en_netdev.c:	 dev->dev_id =  port - 1;
sfc/siena.c:		 efx->net_dev->dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1;

My test system has none of these, so dev_id does have the expected
value of 0 for all ports, same card or whatever, but in all of these
drivers appear to use 0 to mean first port too.

So, I'm not sure how useful this field is in practice today.  Right
idea though...

Thanks,
Matt

-- 
Matt Domsch
Technology Strategist
Dell | Office of the CTO