[5.9] intermittently semi-broken network after boot on RPi4/kernel 5.9 #3850
Comments
|
@popcornmix Have you seen any connectivity issues with an NFS root? |
|
No I haven't. I'm still using sdcard from bootrom, then nfs for rootfs and that seems okay in my setup. |
|
Yes, I'm using TFTP boot from the bootrom here. So far I haven't seen the issue with SD card boot yet, but due to the intermittent nature I wouldn't dare to say that's related at this point (already got another red herring when looking into this issue) |
|
I just caught a not-too-broken-network state where LibreELEC managed to copy the squashfs root to RAM. Network and NFS are slow but I've got a running userspace. Ping me if you'd like me to do some checks (peeking with miitool etc). |
|
I've got a reboot loop running on 5.9-rc5 with nfs booted raspbian (using sdcard for firmware). 50 reboots and counting. Are you able to test with a different Pi4 or a different switch? Also curious if unplugging/replugging ethernet affects it. |
|
Replugging didn't help, tried both plugging it back into the original switch (HP 1810-24G) and into another one (Netgear GS108). dmesg showed the link down/up status change but ping was still ~1000ms I'll do test with another RPi4 and boot-tests with the Netgear switch a bit later. |
|
I assume 5.4 has always been reliable for booting? And 5.9 always unreliable? |
|
yes, 5.4 has always been fine. 5.9 has these intermittent issues (i.e. mostly fine). haven't tested any kernels in between yet |
|
Can you try adding |
|
I checked another RPi4 (2GB) model with the Netgear switch and got slow net on the second reboot. Sep 3 bootloader, only change is BOOT_UART=1 and BOOT_ORDER=0xf241, Sep 16 fw and 5.9.0-rc5 will give umac_reset a try now. |
|
with |
|
Hmm, this is beyond my knowledge. (*) that was enabled by default on 5.4 and doesn't cause the csum spam. It is present on 5.9 but disabled by default. |
|
I checked the 5.6 kernel branch on RPiOS and that showed the same behaviour as 5.9 - intermittently slow network and splats with genet.skip_umac_reset=1 I didn't have much luck with 5.5, that wouldn't mount the nfsroot. kernel dhcp config succeeded but nfs mount failed and kernel panicked I also checked with 5.4 kernel (on LibreELEC) before and that survived about 20 reboots without any issues. I did all these tests on the same setup (2GB RPi4, Sep 16 firmware, Netgear switch). |
|
Libreelec with 5.9 kernel and sdcard boot doing I suspect there's something pi4/switch specific, or bootrom netboot dependent that is causing this. |
|
I think I managed to narrow it down: TFTP boot from bootloader in combination with kernel 5.6 or newer seem to be the key points to trigger the issue. The nfsroot mount issue with kernel 5.5 seems to have been caused by the rw option in nfsroot. No idea why I had it in there, with that removed raspios survived 20 reboots with TFTP/NFS without any issue. raspios with kernel 5.6 and TFTP/NFS boot failed at the 3rd reboot and in a later test even at the very first boot However, with the same 5.6 kernel and firmware on SD card and only root on NFS it survived 50 reboots. I also checked kernel 5.9.0-rc4, that survived 20 SD/NFS reboots as well. |
|
If skipping genet.skip_umac_reset=1 makes things worse then it would seem that either the umac_reset more likely the PHY reset is not correct. A few months ago the bootloader was updated to reset Ethernet if network boot failed (timeout, not connected) which resolve this problem raspberrypi/rpi-eeprom#144. Presumably, the genet/phy driver now has different init behaviour. Edit: The alternative is for the firmware to reset the PHY and UMAC before starting Linux after TFTP boot (@popcornmix see genet_reset / genet_reset_phy). Although, having the firmware reset the PHY/UMAC and have the kernel skip UMAC / PHY reset doesn't feel right. |
|
the downstream umac skip workaround has been disabled by default since kernel 5.5 (which got an upstream fix for that issue), so I don't think this is related here - and kernel 5.5 works fine with TFTP boot. So I guess the downstream kernel workarounds can be dropped. As the issue only seems to occur when TFTP booting kernel 5.6 and above this suggests successful network boot leaves genet/phy in a different state than SD boot (I have SD boot priority higher than netboot, so I assume the bootloader doesn't touch genet/phy in this case). So probably the bootloader should put genet/phy into the reset state and I guess a kernel change to work around that issue is warranted as well - something in 5.6 changes, maybe some registers aren't (re)set as in previous kernel - so kernel can deal with older firmwares as well |
|
The bootloader can't do this because start.elf can use TFTP to loader the kernel so either start.elf has to fully reset the PHY or the kernel has to do this. My guess is that if the UMAC is reset without a PHY reset via MDIO then the UMAC gets upset. Given that the kernel used to reset the UMAC I think it should really reset UMAC + PHY to isolate itself from start.elf or u-boot, UEFI etc |
|
I'm seeing a variety of alignment exceptions and skb BUGs netbooting with 5.9. After establishing that 5.4 is a safe starting point I'll work forwards and see where it starts to go wrong. |
|
IIRC, we've had problems with offloading checksuming of small packets, we had a tweak in there somewhere to prevent it. I wonder if this bypasses the tweak. @6by9 has a younger brain and can therefor remember more than me, |
|
@JamesH65 Are you thinking of Pi 3 issues which had a different network interface? |
|
Are you perhaps thinking of the lan78xx and/or smsc95xx drivers? We had no end of checksum issues with them. |
|
Maybe. Told you I had an aging brain.
…On Thu, 24 Sep 2020 at 09:58, Phil Elwell ***@***.***> wrote:
Are you perhaps thinking of the lan78xx and/or smsc95xx drivers? We had no
end of checksum issues with them.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3850 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA5KWHIELTHL47IBDPVCQHLSHMC4FANCNFSM4RL6L2BQ>
.
--
----
James Hughes
Principal Software Engineer at Raspberry Pi (Trading) Ltd
|
|
@pelwell thanks for looking into this! I've kicked off a 5.9 build with these two commits reverted and will run my reboot loop test with that |
|
@pelwell reboot test with those two commits reverted looks good. I stopped it after 56 successful reboots and bootup times were quite consistently around 18 seconds from kernel startup to reboot service start. Tested on RPi4 4GB B1 stepping, HP1810 switch, Sep 3 bootloader, Sep 17 firmware |
pelwell
added a commit
that referenced
this issue
Sep 24, 2020
This reverts commit ae895c4. See: #3850 Signed-off-by: Phil Elwell <[email protected]>
pelwell
added a commit
that referenced
this issue
Sep 24, 2020
This reverts commit 9a9ba2a. See: #3850 Signed-off-by: Phil Elwell <[email protected]>
|
Thanks, @HiassofT - I've pushed the reversions for now, pending a proper fix. |
pelwell
added a commit
that referenced
this issue
Sep 25, 2020
If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: #3850 Signed-off-by: Phil Elwell <[email protected]>
FerryAr
pushed a commit
to FerryAr/kernel_xiaomi_mojito
that referenced
this issue
Jul 29, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
FerryAr
pushed a commit
to FerryAr/kernel_xiaomi_mojito
that referenced
this issue
Jul 29, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
ShujathMohd
pushed a commit
to ShujathMohd/kernel
that referenced
this issue
Jul 29, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
romgharti
pushed a commit
to romgharti/kernel_xiaomi_mojito
that referenced
this issue
Jul 30, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
LucasBlackLu
pushed a commit
to LucasBlackLu/kernel_google_msm-4.14
that referenced
this issue
Aug 9, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
mcf1y
pushed a commit
to mcf1y/android_kernel_xiaomi_sdm660
that referenced
this issue
Aug 15, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
wcedla
pushed a commit
to wcedla/kernel_xiaomi_sm8250_immens1ty_mod
that referenced
this issue
Aug 20, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
xt0032rus
pushed a commit
to xt0032rus/kernel_xiaomi_sm8550
that referenced
this issue
Aug 30, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: xt0032rus <[email protected]>
ahnet-69
pushed a commit
to ahnet-69/android_kernel_samsung_a32
that referenced
this issue
Sep 5, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
backslashxx
pushed a commit
to backslashxx/mojito_krenol
that referenced
this issue
Oct 2, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
fluffball3
pushed a commit
to fluffball3/android_kernel_samsung_m33x
that referenced
this issue
Oct 4, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
wanghao75
pushed a commit
to openeuler-mirror/kernel
that referenced
this issue
Oct 15, 2024
stable inclusion from stable-v5.10.217 commit 1fb7ab9a6e3eb4ea71a02b8b27fe2a95cc1213af category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAWLXC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1fb7ab9a6e3eb4ea71a02b8b27fe2a95cc1213af -------------------------------- [ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: sanglipeng1 <[email protected]>
noticesax
pushed a commit
to noticesax/sphinx_kernel_xiaomi_rosemary
that referenced
this issue
Oct 17, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
noticesax
pushed a commit
to noticesax/sphinx_kernel_xiaomi_rosemary
that referenced
this issue
Oct 17, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
noticesax
pushed a commit
to noticesax/hydrogen_kernel_xiaomi_selene
that referenced
this issue
Oct 20, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
noticesax
pushed a commit
to noticesax/hydrogen_kernel_xiaomi_selene
that referenced
this issue
Oct 20, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
hoaysly
pushed a commit
to hoaysly/android_kernel_oneplus_msm8998-4.14
that referenced
this issue
Nov 3, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
hoaysly
pushed a commit
to hoaysly/android_kernel_oneplus_msm8998-4.14
that referenced
this issue
Nov 3, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
backslashxx
pushed a commit
to backslashxx/mojito_krenol
that referenced
this issue
Nov 9, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
Ksawlii
pushed a commit
to Ksawlii/android_kernel_samsung_a53x-FireAsf
that referenced
this issue
Nov 19, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
ethicalfighter56
pushed a commit
to ethicalfighter56/android_kernel_realme_x2pro_sm8150
that referenced
this issue
Nov 22, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
fus0g
pushed a commit
to sm8350-martini/kernel_oneplus_sm8350
that referenced
this issue
Nov 29, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
XeroMz69
pushed a commit
to XeroMz69/Bumi-Kernel-Tree
that referenced
this issue
Dec 1, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
pyo3377
pushed a commit
to pyo3377/kernel_xiaomi_mojito
that referenced
this issue
Dec 2, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
Anush02198
pushed a commit
to xiaomi-sdm678/android_kernel_xiaomi_mojito
that referenced
this issue
Dec 4, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
nzlnice
pushed a commit
to nzlnice/crux-marisa
that referenced
this issue
Dec 6, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]>
FakeShell
pushed a commit
to FuriLabs/linux-android-furiphone-krypton
that referenced
this issue
Dec 7, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
build-13
pushed a commit
to build-13/kernel_xiaomi_mojito
that referenced
this issue
Dec 12, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]> Signed-off-by: build-13 <[email protected]>
build-13
pushed a commit
to build-13/kernel_xiaomi_mojito
that referenced
this issue
Dec 18, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]> Signed-off-by: build-13 <[email protected]>
build-13
pushed a commit
to build-13/kernel_xiaomi_mojito
that referenced
this issue
Dec 18, 2024
[ Upstream commit 0a6380cb4c6b5c1d6dad226ba3130f9090f0ccea ] If the RBUF logic is not reset when the kernel starts then there may be some data left over from any network boot loader. If the 64-byte packet headers are enabled then this can be fatal. Extend bcmgenet_dma_disable to do perform the reset, but not when called from bcmgenet_resume in order to preserve a wake packet. N.B. This different handling of resume is just based on a hunch - why else wouldn't one reset the RBUF as well as the TBUF? If this isn't the case then it's easy to change the patch to make the RBUF reset unconditional. See: raspberrypi/linux#3850 See: raspberrypi/firmware#1882 Signed-off-by: Phil Elwell <[email protected]> Signed-off-by: Maarten Vanraes <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> (cherry picked from commit 510e7b18fdad4b55849d7a73b8ff2c3e8ad2f7af) Signed-off-by: Vegard Nossum <[email protected]> Signed-off-by: build-13 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Sometimes I get huge ping times on ethernet, network packets going out very slowly from RPi4 (up to several seconds between tcp packets) and (almost) non-functional NFS after boot.
Most of the time network performance is fine though (about 0.1ms ping time and linux part of NFS boot completed in about 20 seconds).
To reproduce
So far I've only seen the issue when netbooting the RPi4, I wouldn't rule out though that it can happen with SD card boot as well. I usually get the issue in about 1-3 out of 10 boots, sometimes it can need more than 10 reboots though.
Expected behaviour
Network performs normally (low ping, working NFS mounts), like with 5.4 kernel.
Actual behaviour
Kernel level DHCP configuration and root NFS mount sometimes take very long, NFS performance is sometimes so bad that the userspace system fails to start up.
System
4GB RPi4 with B1 stepping, Sep 03 boot eeprom, Sep 11 firmware, kernel 5.9-rc4 githash 4ba2756
Tested with current 32bit RaspiOS (bcm2711_defconfig) and LibreELEC master (custom kernel config).
Logs
Working network, as a reference: http://ix.io/2xzu , ping time is about 0.1ms
One try with semi-working NFS, systemd somewhat came up http://ix.io/2xzw , ping was about 300-500ms:
Another try, NFS pretty much unusable: http://ix.io/2xzx , ping up to 1024ms
Additional context
In other tests I had seen rather tunny ping times of 1024, 2048, 3072 and 4906ms.
I had seen this issue with the previous rpi-eeprom version as well, but only on kernel 5.9. I used that very often to netboot kernel 5.4 systems (mainly LibreELEC)
The text was updated successfully, but these errors were encountered: