Intel X710-TM4 nics not found #731
Comments
|
What are the PCI vendor:device IDs for this NIC? |
|
Also verify that you are using the latest version of iPXE. (And post the version number to verify) |
|
Here is the lspci output with vendor:device info for the nics Output of ipxe version |
This comment was marked as abuse.
This comment was marked as abuse.
|
@loood Thanks for confirming the IDs and version. Could you please try building with |
|
Recompiled today with the DEBUG=intelxl:3. This is the output: Then it continued on unsuccessfully with the rest of the ipxe script |
This comment was marked as abuse.
This comment was marked as abuse.
|
Hi! The output from The build script I have does a I rebuilt it with |
This comment was marked as abuse.
This comment was marked as abuse.
|
Tried |
|
@loood Thank you for the debug output. The values being read from the card are very strange: PF 7, port 3, queues 0x7ff-0x7ff, BAR 3. All of these values represent all bits being set (within the bit width of the relevant field). It looks as though every single MMIO read from the card is returning 0xffffffff. You are using UEFI, so it's possible that the platform firmware is providing a broken translation table or similar. As a quick test: if the server supports booting in legacy BIOS mode, could you try that? |
|
@loood Could you please also try (in UEFI mode) |
|
Here is the output for Haven't tried legacy boot but we're trying to convert to all uefi. Also like to add that I just tried the snp.efi (didn't know that was an option until a few days ago) and that works without issue. |
This comment was marked as abuse.
This comment was marked as abuse.
|
Commentary inline below:
PF 0 is detected with memory BAR at 0xc7000000. The address 0xc7000000 is within the root bridge range, and is apparently identity mapped. So far, so good. The "could not enable DAC" message is potentially harmless: from the pointers observed within the other debug messages (e.g. 0x9ea1b910), it appears that iPXE is running within the low 4GB of RAM and so dual address cycles will not be needed anyway. For some unknown reason, all subsequent MMIO reads from the memory BAR appear to be returning all ones (0xffffffff), as described in my earlier message.
This is the same device (PF 0) being discovered again. This is not entirely unsurprising, since other UEFI platforms have been observed to retry device probes several times in the event of a driver What is interesting is that the memory BAR now appears to have been zeroed (and hence disabled).
Same sequence of events happens for PF 1 ...
... and again for PF 2 ...
...and again for PF 3. So, it's clear that something is zeroing the memory BAR, which would fully explain the fact that all reads seem to return 0xffffffff (since that is the defined behaviour when no PCI target responds to the read transaction). It is highly suspicious that this seems to happen around the same time that the failed attempt to enable DAC is made, so the first experiment I'd want to try would be to comment out the call to If that doesn't change anything, then I'd try adding debug statements such as: at various points within |
|
Tried commenting out the |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Same here. We're using |
In that case, https://ipxe.org/howto/bisect may be useful. |
|
Commit a202de3 seems to break things for me. |
stappersg
referenced
this issue
Sep 20, 2022
Remove knowledge of the PFGEN_CTRL register (which changes location between XL710 and E810 register maps), and instead use PCIe FLR to reset the physical function. Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
Hi We have the same problem with while compiled with DEBUG=intelxl:3,pcimsix:3 we found this: Media Present |
Same here. |
@alexdepalex Thanks for the bisection result. Should be fixed by #801 |
|
Just a quick question to the people that are tracking this issue before I open a new one. Did some of you try the fixed code? We're using master, with which the adapters get discovered, but we can't get packets flowing over the network. We're booting into ipxe, configuring networking as we previously did on the commit that did work, but we can't ping the gateway or our dns servers. Was somebody able to get this to work with X710 after the fix was introduced? |
|
I can confirm, the newest commit fixed the problem for us.
…On Mon, 6 Feb 2023 at 16:57, Alex Vermulst ***@***.***> wrote:
Just a quick question to the poepl that are following this before I open a
new issue. Did some of you try the fixed code? We're using master, with
which the adapters get discovered, but we can't get packets flowing over
the network. We're booting into ipxe, configuring networking as we
previously did on the commit that did work, but we can't ping the gateway
or our dns servers.
Was somebody able to get this to work with X710 after the fix was
introduced?
—
Reply to this email directly, view it on GitHub
<#731 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQPBUIT7U7NSK6CI37AVPADWWENOXANCNFSM6AAAAAAQBY22SQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Thanks. I'll give that a shot. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm using ipxe.iso to boot a Supermicro A+ Server 1124US-TNRP which uses a Intel X710-TM4. ipxe doesn't seem to see the intel nics. Wanted to find out if those nics are suppose to be supported or what I can do to help get those supported?
The text was updated successfully, but these errors were encountered: