IPXE Error (Unsupported NIC/Intel)

[Fr3DBr]

Hi, guys.

Currently now using the last ipxe version, I am having this issue where the NIC can't be configured.

Would you know why ?

Sincerely,

Fred

---

Here is the screenshot :





This is a HP DL360p Server w/ Intel NIC.

[mcb30]

(2014-10-30 12:04)Fr3DBr Wrote:  Currently now using the last ipxe version, I am having this issue where the NIC can't be configured.

Would you know why ?

As suggested by the error message, take a look at http://ipxe.org/err/040ee1.

Michael

[Fr3DBr]

(2014-10-30 13:49)mcb30 Wrote:  

(2014-10-30 12:04)Fr3DBr Wrote:  Currently now using the last ipxe version, I am having this issue where the NIC can't be configured.

Would you know why ?

As suggested by the error message, take a look at http://ipxe.org/err/040ee1.

Michael

Hi, thanks for your input.

I've did what you've suggest, but no luck yet

[mcb30]

(2014-10-30 14:05)Fr3DBr Wrote:  I've did what you've suggest, but no luck yet

Unfortunately my psychic powers are at a low ebb today and I am unable to magically guess what is wrong with your setup. You are going to have to provide some actual diagnostic information. For example: what does "ifstat" show after a manual "dhcp" attempt? Does your DHCP server see the DHCP request? Does your DHCP server respond with a DHCP offer?

Michael

[Fr3DBr]

(2014-10-30 14:10)mcb30 Wrote:  

(2014-10-30 14:05)Fr3DBr Wrote:  I've did what you've suggest, but no luck yet

Unfortunately my psychic powers are at a low ebb today and I am unable to magically guess what is wrong with your setup. You are going to have to provide some actual diagnostic information. For example: what does "ifstat" show after a manual "dhcp" attempt? Does your DHCP server see the DHCP request? Does your DHCP server respond with a DHCP offer?

Michael

Michael, we have other servers which are working fine. The DHCP Helper is implemented in the network and if we use that same network port, for another server (that is a bit older than this one), it works fine with ipxe, just 'this model' is refusing to work.

Also, we have another server of the same type, but one generation before this one we received yesterday and it also works fine !

Check the screenshot, there is something strange there, because in the DHCP, the mac address shows as :AC (nic 0) but the ipxe loader, thinks nic 0 is :AF which is nic 4, why that happens ?

---

The problem is exactly the one I mention, the i350 driver seems to be ordering the NICs in the wrong way, and then I have issues, because the MAC in the DHCP Boot Loader is one, but in IPXE Loader it is another, hence why the DHCP Lease is not obtained during the "configuration step". :/

---

Here is ifstat in IPXE (with ISO booting, instead of PXE Booting as before).

---

Indeed the MAC/Interface Ordering is incorrect (as shown above) but not sure how to fix that.

[mcb30]

(2014-10-30 14:14)Fr3DBr Wrote:  The problem is exactly the one I mention, the i350 driver seems to be ordering the NICs in the wrong way, and then I have issues, because the MAC in the DHCP Boot Loader is one, but in IPXE Loader it is another, hence why the DHCP Lease is not obtained during the "configuration step". :/

---

OK, this is now useful information. If you add a DHCP reservation for the 38:ea:a7:14:7c:af address, does iPXE successfully obtain an address?

Michael

[Fr3DBr]

(2014-10-30 15:13)mcb30 Wrote:  

(2014-10-30 14:14)Fr3DBr Wrote:  The problem is exactly the one I mention, the i350 driver seems to be ordering the NICs in the wrong way, and then I have issues, because the MAC in the DHCP Boot Loader is one, but in IPXE Loader it is another, hence why the DHCP Lease is not obtained during the "configuration step". :/

---

OK, this is now useful information. If you add a DHCP reservation for the 38:ea:a7:14:7c:af address, does iPXE successfully obtain an address?

Michael

Yes, it does. Looks like to be an enumeration issue between the MAC Relationship and the PCI Device ID. (I am not a driver developer, but I guess that's a way to describe that).

Sincerely,

Fred

[mcb30]

(2014-10-30 15:23)Fr3DBr Wrote:  

Quote:OK, this is now useful information. If you add a DHCP reservation for the 38:ea:a7:14:7c:af address, does iPXE successfully obtain an address?

Yes, it does. Looks like to be an enumeration issue between the MAC Relationship and the PCI Device ID. (I am not a driver developer, but I guess that's a way to describe that).

OK; glad that we've eliminated any functional problems in driving the NIC.

Could you try building with DEBUG=intel? This will show some additional information about the source of the MAC addresses.

Thanks,

Michael

[Fr3DBr]

(2014-10-30 15:59)mcb30 Wrote:  

(2014-10-30 15:23)Fr3DBr Wrote:  

Quote:OK, this is now useful information. If you add a DHCP reservation for the 38:ea:a7:14:7c:af address, does iPXE successfully obtain an address?

Yes, it does. Looks like to be an enumeration issue between the MAC Relationship and the PCI Device ID. (I am not a driver developer, but I guess that's a way to describe that).

OK; glad that we've eliminated any functional problems in driving the NIC.

Could you try building with DEBUG=intel? This will show some additional information about the source of the MAC addresses.

Thanks,

Michael

I am not able to build it from here, but is there any way to do it using the iso image available in the website ?

Sincerely,

Fred

---

Nvm, I'll try to find a way to build it and report back

[Fr3DBr]

Hey, I'm back.

This is the screenshot of debug mode :



Look the auto-loaded MAC and the EEPROM MAC, soooooo strange.

[Fr3DBr]

Linux and DHCP Loader are considering that "Auto Loaded MAC", but the ipxe, is considering the EEPROM MAC which is not working correctly.

[mcb30]

(2014-10-30 17:09)Fr3DBr Wrote:  Look the auto-loaded MAC and the EEPROM MAC, soooooo strange.

I think I found the underlying problem, which is that the i350 has a non-trivial correspondence between the PCI function number and the LAN port number. In particular, there is a register "FACTPS.LAN Function Sel": this register is initialised from the EEPROM "Functions Control" register and, if set, causes the ordering of ports 0-3 to be inverted.

I have no idea why Intel added this bit, since I can't think of any realistic scenario in which it is valuable to be able to reassign the PCI<->port mappings.

Worse, the EEPROM MAC addresses are located by LAN port number rather than by PCI function number, which means that the driver can't just use PCI function numbers and not care about how these are mapped to the external physical ports.

Michael

[Fr3DBr]

Ohhhh, I see :|. Is this fixable in any way or is it hard and should take a while ?

I ask this, because I wanted to provision a few servers but currently now I'm stuck

Sincerely,

Fred

[mcb30]

(2014-10-31 16:12)mcb30 Wrote:  I think I found the underlying problem, which is that the i350 has a non-trivial correspondence between the PCI function number and the LAN port number. In particular, there is a register "FACTPS.LAN Function Sel": this register is initialised from the EEPROM "Functions Control" register and, if set, causes the ordering of ports 0-3 to be inverted.

I've pushed a change which should fix this: http://git.ipxe.org/ipxe.git/commitdiff/a937615.

Michael

[Fr3DBr]

(2014-10-31 16:31)mcb30 Wrote:  

(2014-10-31 16:12)mcb30 Wrote:  I think I found the underlying problem, which is that the i350 has a non-trivial correspondence between the PCI function number and the LAN port number. In particular, there is a register "FACTPS.LAN Function Sel": this register is initialised from the EEPROM "Functions Control" register and, if set, causes the ordering of ports 0-3 to be inverted.

I've pushed a change which should fix this: http://git.ipxe.org/ipxe.git/commitdiff/a937615.

Michael

Oh, nice, really nice !!!

I will test it and provide you feedback !

Sincerely,

Fred

---

Yessssssssssssssssssssssssssss, fixed !!!

Thank you very much Michael, really !

Sincerely,

Fred

[Fr3DBr]

Hi, Michael.

There is another issue now. The MAC / DHCP Problem is 100% solved.

However after loading wimboot either for 2k8 or 2k12, the installation doesn't start anymore.

For win2k8 I get a red screen, with an offset/assembly error. And for win2k12 the screen just remain black and nothing happens anymore. (With Linux/CentOS, it works fine).

2K8 Error:


Do you have any hint what could be that ?

Sincerely,

Fred

[Fr3DBr]

I am not entirely sure on what causes that, but I'm trying to find out, Linux provisioning works good, for any version. But microsoft stuff, forget it.

[Fr3DBr]

Same with ipxe.iso, however with win2k8 there is no red screen, however both versions doesn`t start the installation/setup (it just freezes), something looks strange

[heckj]

(2014-10-31 16:44)Fr3DBr Wrote:  

(2014-10-31 16:31)mcb30 Wrote:  [quote='mcb30' pid='11000' dateline='1414768328']
I think I found the underlying problem, which is that the i350 has a non-trivial correspondence between the PCI function number and the LAN port number. In particular, there is a register "FACTPS.LAN Function Sel": this register is initialised from the EEPROM "Functions Control" register and, if set, causes the ordering of ports 0-3 to be inverted.

I've pushed a change which should fix this: http://git.ipxe.org/ipxe.git/commitdiff/a937615.

Michael

Hi Michael,

I just build a debug version off master that includes that patch and used it on a Intel S2600GZ server that's booting off an i350 nic, and it didn't seem to report the correct Mac.

The nic is reporting (via ethtool -i) that it's running firmware version 1.48.

The nic reported when it started PXE booting: 01:1E:67:87:CE:66
Then when it's doing the debug output (make DEBUG=pci,device,intel,undionly,undinet):


INTEL 0xc2a24 MAC+PHY reset (ctrl 001c0261)
INTEL 0xc2a24 has autoloaded MAC address 01:1e:67:87:ce:69
INTEL 0xc2a24 link status is 8028078c

IPXE goes on to iterate through debug output related to PCI, finally hanging or (I'm guessing) crashing and resetting the machine.

(I tried to upload a screencapture, but the forums threw an error on me)

I have a video capture of the whole sequence. Wasn't sure how to best share that, so I put it up as "unlisted" on YouTube at http://youtu.be/WWop5SFXrPg

Any suggestions for what's happening or how to further debug it?

[heckj]

I just built a debug version off master that includes the patch above and used it on a Intel S2600GZ server that's booting off an i350 nic, and it didn't seem to report the correct Mac...

I'm having additional trouble with this machine in that iPXE just hangs or appears to crash and reboot.

The nic is reporting (via ethtool -i) that it's running firmware version 1.48.

The nic reported when it started PXE booting: 01:1E:67:87:CE:66
Then when it's doing the debug output (make DEBUG=pci,device,intel,undionly,undinet):

I made a video of the whole sequence, wasn't sure how best to share it, so I've made it unlisted on YouTube: http://youtu.be/WWop5SFXrPg