Kernel warning and network failure when attempting to use the network after bootloader times out. #144
Comments
|
I think this should be raised as a Linux issue. Once the kernel is loaded the network interface is reset before starting the kernel. There is no shared network state between the firmware and the kernel. |
|
I thought that, but the reason I raised it here is because it does seem to matter. If you insert the cable in the window when the bootloader is loading everything from the uSD card, the link comes up but the kernel still crashes when it tries to send a packet. If there really is no state maintained, then it shouldn't do that, surely? |
|
I think the kernel is assuming that genet registers are in a particular state and I think that's probably a regression in the 5.4 Kernel or nobody has spotted this in a 4.19 kernel. |
|
ping @pelwell to see if he thinks this ought to be moved to the Linux repo? |
|
It might be a kernel problem, but I'm not being given the option to move it, and demanding that it be closed and another issue opened in raspberrypi/linux seems a bit draconian. |
|
Leave it here until we know what the issue is. If it really is a Kernel problem then that's a separate discussion for an upstream driver. |
|
I was able to reproduce the failure. The problem only seems to occur if network boot as attempted but the link was never established i.e. cable always disconnected until waiting in Linux. Adding genet.skip_umac_reset=n doesn't help. Anyway, this now works for me (boot without ethernet cable then insert cable when rootfs timeout messages start to appear). It resets the MAC and PHY in the bootloader if network boot was selected. The MAC/PHY reset sequence has been a bit fragile on Pi 4 so I think it's going to need to be tested on various boards + switchers for us to be sure. I also don't know why Linux is crashing other than TX gets stuck. |
timg236
changed the title
|
Updated title to be more specific. The backtrace is a warning that the ethernet driver is stuck, with NFS boot the OS will be inoperable but I think you could get an Ethernet freeze from an SD boot if the timing was just "right" when the kernel does DHCP |
* Reset Ethernet MAC + PHY if final boot mode is not network boot
See: Kernel warning and network failure when attempting to use
the network after bootloader times out. raspberrypi#144
* Improve handling of multiple bootable USB devices and remove USB_MSD_BOOT_MAX_RETRIES
* Resolve: No DHCPACK with DHCP relay agent raspberrypi#58
* Toggle USB root hub port power for 200ms on the first USB MSD boot attempt
See: Bootloader can't boot via USB-HDD after system reboot raspberrypi#151
* Update bootloader handover to support uart_2ndstage - requires a newer
start.elf firmware which will be via rpi-update.
* Assert PCIe fundamental reset if the final bootmode was not USB-MSD
because the OS might not do this before starting XHCI.
|
Resolved in pieeprom-2020-06-15 |
If the Pi 4 is booted with a boot order which includes the network before the ultimately successful boot device, but no network cable is plugged in, the kernel will crash when attempting to use it, once the link is restored. I am using NFS boot, but I don't believe that is related. On a control-alt-delete reboot, the bootloader no longer displays the diagnostics screen.
Kernel version:
[ 0.000000] Linux version 5.4.42-v7l+ (dom@buildbot) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1319 SMP Wed May 20 14:12:03 BST 2020
To Reproduce:
Set BOOT_ORDER to, say, 0xf124. Remove all USB bootable devices. Install a bootable uSD card. Remove the network cable. Boot the Pi.
The bootloader will time out waiting for the USB and network stages, then fall back to the uSD card. At this point, the kernel should boot. With an NFS root, it will wait undefinitely for a cable. Plugging the cable in at any time after the network boot timeout, including during the rainbow screen, will cause the kernel to crash when it attempts to send a packet.
Expected behaviour
The kernel run as usual.
Screenshots
Backtrace:
Full log attached.
bt.txt
Bootloader version and configuration
Also present in 2020-05-28. I reported it on the thread over the weekend, but I believe it was missed. Niche, yes. Hope this helps.
The text was updated successfully, but these errors were encountered: