Hi Michael, On Tue, 1 Apr 2025 at 23:22, Michael Brown <[email protected]> wrote: > > On 31/03/2025 18:31, Christian Kohlschütter wrote: > > Whoa! Good eyes, Michael! > > > > What is my Fritzbox doing to my initrd, and why does reverting the commit > > fix it? > > > > FWIW, I also have a capture with an ethernet frame from another device on > > my network (ARP, ethertype 0x0806), so this is probably the content of some > > ethernet receive buffer... > > I've taken a quick look through the U-Boot codebase, and I can't > immediately see where the Ethernet device gets disabled as a result of > calling ExitBootServices(). It's possibly worth noting that U-Boot may > have relied upon iPXE's behavior prior to commit > https://github.com/ipxe/ipxe/commit/562c74e1e: > > [efi] Run ExitBootServices shutdown hook at TPL_NOTIFY > > ... <snip lengthy explanation as to why we need to do this> ... > > Avoid calling into an underlying SNP protocol instance from within our > shutdown hook at TPL_NOTIFY, since the underlying SNP driver may > attempt to raise the TPL to TPL_CALLBACK (which would cause a fatal > error). Failing to shut down the underlying SNP device is safe to do > since the underlying device must, in any case, have installed its own > ExitBootServices hook if any shutdown actions are required. > > So, older versions of iPXE would have called Snp->Stop(), which in > U-Boot's efi_net_stop() will call eth_halt(). Current versions of iPXE > will not call Snp->Stop(), and will rely on the underlying SNP driver to > have dealt with its own ExitBootServices() requirements. > > I can't find any evidence of U-Boot installing an > EVT_SIGNAL_EXIT_BOOT_SERVICES event to call eth_halt() when > ExitBootServices() is called. > > The closest I can find is a block of code in U-Boot's > efi_exit_boot_services(): > > bootm_disable_interrupts(); > if (IS_ENABLED(CONFIG_USB_DEVICE)) > udc_disconnect(); > board_quiesce_devices(); > dm_remove_devices_active();
We have discussed combining this code with the similar code in boot/bootm.c > > but I don't know precisely what these various functions are supposed to > do, and I can't find any path that leads from any of these to eth_halt(). > > Is it possible that U-Boot is failing to call eth_halt() in response to > ExitBootServices(), and is therefore leaving the network device active > and performing DMA while the kernel starts up? The dm_remove_devices_active() is supposed to handle this, but it is possible that one of the drivers lacks a remove() method. Regards, Simon
