Skip to contentSkip to conversation

Bogus names on vmware

DISCUSSION Stephen Hemminger 1 participant 1 message Nov 20, 2015 2 messages not in the archive ACPI

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): 20151021084158.6b650224@xeon-e3

A message that is not in the archive (sent off-list or not yet received): 20151021161755.GA15833@gardel-login

#2 lore raw
Quoted 32 lines · On Wed, 21 Oct 2015 18:17:56 +0200 Lennart Poettering <[email protected]>…
Quoted 2 lines · Stephen Hemminger

Do you have any recommendations on how to deal with VMware borkage of the ACPI firmware index?

Hmm, shouldn't the kernel filter such crappy data out already? I mean, if we work around crappy firmware, why should that happen in userspace? So far that was always a kernel job...

Any specific reason you assume that 0xffff is a good cutoff point?

Quoted 21 lines

https://communities.vmware.com/message/2378360

My proposal is to just add special case:

src/udev/udev-builtin-net_id.c +1 -1
index 6e7e127..b8c6f47 100644
@@ -133,7 +133,7 @@ static int dev_pci_onboard(struct udev_device *dev, struct netnames *names) {
         size_t l;
         char *s;
         const char *attr;
-        int idx;
+        unsigned long idx;
 
         /* ACPI _DSM  -- device specific method for naming a PCI or PCI Express device */
         attr = udev_device_get_sysattr_value(names->pcidev, "acpi_index");
@@ -143,8 +143,9 @@ static int dev_pci_onboard(struct udev_device *dev, struct netnames *names) {
         if (!attr)
                 return -ENOENT;
 
Quoted 8 lines

src/udev/udev-builtin-net_id.c static int dev_pci_onboard(struct udev_device *dev, struct netnames *names) { · line 151

Quoted 8 lines
src/udev/udev-builtin-net_id.c +2 -1
+        /* vmware returns bogus values */
         idx = strtoul(attr, NULL, 0);
-        if (idx <= 0)
+        if (idx == 0 || idx > 0xffff)
                 return -EINVAL;
 
         /* kernel provided port index for multiple ports on a single PCI function */

Sorry for the long latency, for some reason this ended up in Spam.

The kernel could filter but I suspect the ACPI developers would consider it a valid value. I made up 0xffff as a mask assuming 64K slots is more than any normal ACPI would return.

VMware has other issues, there concept of PCI addresses is equally borked (unique)
http://goo.gl/uhGEj8

Copying the ACPI kernel list on this.