Why renaming of network interfaces is not working as expected with Mellanox infiniband card?

Issue

• With Mellanox infiniband card why renaming of my interfaces is not working as expected?
• Trying to rename network interfaces, after booting the system has an interface named renameX, why is this?

$grep Hwaddr ifconfig 
eth1      Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:01  
eth2      Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:02  
eth3      Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:03  
rename4   Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:04

• Why udev fails to rename interface.
• The sysfs directory of my network card is not properly accessable:

# pwd
 /sys/bus/pci/devices/0000:90:00.0/net
# ls -l
ls: cannot access eth7: No such file or directory
total 0
d????????? ? ?    ?    ?            ? eth7
drwxr-xr-x 5 root root 0 Apr  3 14:31 eth8

• Trying to manually rename Mellanox NIC interfaces fails:

# ip link set dev eth7 name eth9
RTNETLINK answers: No such file or directory

• We performed a firmware upgrade on our Mellanox cards and have since had a problem with the eth* naming. Our servers have Intel 10Gb cards (igb) and Mellanox 10GB and Infiniband cards (mlx4_core). Before the new firmware our cards where assigned as follows:

eth0 - intel
eth1 - intel
eth2 - Mellanox
eth3 - Mellanox

• Since the firmware upgrade we get the following:

eth0 - intel
eth1 - Mellanox (uninitialised)
eth2 - Mellanox
rename5 - intel

• I believe this has to do with the fact that since the firmware upgrade the Mellanox card initialise quicker than the Intel cards. The reverse was the case before hand. I've tried several steps to resolve this:

1) Remove /etc/udev/rules.d/70-persistent-net.rules and reboot
2) Repeat the above, but with the additional removal of /dev/.udev
3) Manually modify the 70-persistent-net.rules file to map correct mac addresses to interfaces
4) Add HW_ADDR=[mac] to all ifcfg-eth* 

• None of the above work. My only idea left to be modprobe the nic drivers in the order I want them, i.e. igb and mlx4_core, with a sleep between each load (say about 5 secs) but I'm not 100% of the best route to take for this.
• FYI, I found this - Solution #25102 - but this solution does not resolve my issue.