Description of problem: https://github.com/ipxe/ipxe/issues/157 iPXE floods the physical switch with LACP frames, fails to configure network interface. Version-Release number of selected component (if applicable): from RHOSP16.2.2 $ sudo podman exec -ti ironic_pxe_tftp rpm -q ipxe-bootimgs ipxe-bootimgs-20181214-8.git133f4c47.el8.noarch How reproducible: I need - a Dell PowerEdge R830, configured for PXE and UEFI boot - Mellanox ConnectX-3 cards - connected to 2 switches with active LACP bonding Steps to Reproduce: 1. openstack baremetal introspection start <node> 2. 3. Actual results: ipxe.efi is properly downloaded, but then the interface fails to configure. The interface on the switch goes to errdisabled because lacp-rate-limit tcpdump on the switch reveals the same trace as in the github ticket: switch being flooded with LACP frames. Expected results: should work Additional info: it works replacing the ipxe.efi from ipxe-bootimgs-20181214-8.git133f4c47.el8.noarch with one I built myself that includes more recent sources + a patch to disable NET_PROTO_LACP (https://koji.fedoraproject.org/koji/taskinfo?taskID=88334805)
Hi François. As the bug has been fixed in ipxe-20181214-10.git133f4c47.el8, could you check if the problem is fixed using this version? If it is, please report us any information that could be useful to mark this bug as verified. Thanks!
Thanks Oliver, unfortunately I don't have a way to retrieve this artifact.
Jarod: Could you give François a public link to download the fixed version package and do the testing for the package?
Packages temporarily available here: https://people.redhat.com/~jwilson/testing/ipxe/
Created attachment 1910398 [details] Unknown_krgfs_crash used the ipxe-snponly-x86_64.efi to deploy 2 servers: - 1 unrelated machine: deploys fine - 1 machine with the ConnectX-3 pro -> crash, log attached.
Hi @frigo . The crash you specify in this test is something that happened also with previous version or only with this new one?
hi! no I have never seen this crash before, it is specific to this new version.
Does the package you built yourself (mentioned in the original report description) work on that host where this build failed, or does that fail similarly?
the package I built myself works on that host flawlessly yes. I understand this requires a specific type of hardware to reproduce. I can live with my hacks if fixing it is not trivial.
(In reply to François Rigault from comment #33) > the package I built myself works on that host flawlessly yes. > > I understand this requires a specific type of hardware to reproduce. I can > live with my hacks if fixing it is not trivial. It sounds like it would require tracking down the specific changes from upstream ipxe that make this work with cx-3 or a full rebase (which we generally frown upon doing at any point in a major release, let alone this late), and without a readily available reproducer and some time and effort (I'm lacking in time), I think we may well have to revert that one patch and revisit this for the next minor release.