TX failure with i219-lm(4) about ipxe HOT 4 CLOSED

@raphaelmeyer Since you have a sequence of operations in Genode that is able to recover from the situation, I would suggest bisecting this sequence to isolate the minimum operation(s) required to effect a recovery.

For example, the call to netdev_link_down() should be superfluous since that will not touch the hardware in any way (it affects only the internally recorded link state). Bisecting the operations performed by netdev_close() and netdev_open() is harder, but you can start with bypassing the netdevice core by calling intel_close() and intel_open() directly, then try various bits of those routines to see what minimally clears the error condition.

from ipxe.

And this is tested with the latest version of iPXE?

from ipxe.

@raphaelmeyer Are you able to reproduce the problem with iPXE, or does this occur only when using iPXE's driver within Genode?

from ipxe.

Thank you very much for your inputs.

Indeed, I could not reproduce the issue with iPXE itself. I tried by setting up an infinite iPXE loop, even with adding undionly.kpxe once before entering the loop as well.

I am not sure about how recent the iPXE code in genode is. The driver drivers/net/intel.c is basically the same as in iPXE master, but I found a few differences in net/netdevice.c. The issue was still present when I incoporated these differences into the genode code.

These insights will help to further narrow down the issue. Probably it's in how netdevice is used by genode as a driver interface.

Therefore, I close the issue, but I would still be very happy to receive further feedback.

from ipxe.