We use some essential cookies to make our website work.

We use optional cookies, as detailed in our cookie policy, to remember your settings and understand how you use our website.

8 posts • Page 1 of 1
breiti
Posts: 2
Joined: Sat Sep 28, 2024 8:43 pm

RPi 4: downloads unreliable w/ 1Gbps but not w/ 100Mbps ethernet interface speed

Sat Sep 28, 2024 9:16 pm

Hi, i have this weird problem w/ my Raspberry Pi 4 (4GB).

I run fedora-iot

Code: Select all

[root@rpi ~]# rpm-ostree status
State: idle
Deployments:
くろまる fedora-iot:fedora/stable/aarch64/iot
 Version: 40.20240926.0 (2024年09月26日T15:46:00Z)
 BaseCommit: 7a242e48bdf0d65d68b0d0d27df81628b6ea2a87d2a2c02121359fd9b0ee61fb
 GPGSignature: Valid signature by 115DF9AEF857853EE8445D0A0727707EA15B79CC
 LayeredPackages: bind-utils bluez ethtool htop systemd-container systemd-networkd tcpdump
I noticed that every time i run

Code: Select all

rpm-ostree upgrade
it got stuck at a random percentage (transfer speed drops to 0) while downloading the newest packages/layers and after like 30-60s it eventually timed out. Than i have to re-run the command, often i gave up after 15-20x. Obviously, a very annoying and frustrating situation.

Downloads are made from

Code: Select all

[root@rpi ~]# dig +short aaaa d2uk5hbyrobdzx.cloudfront.net
2600:9000:2261:4400:1a:9c17:e740:21
2600:9000:2261:fa00:1a:9c17:e740:21
2600:9000:2261:7c00:1a:9c17:e740:21
2600:9000:2261:b400:1a:9c17:e740:21
2600:9000:2261:4a00:1a:9c17:e740:21
2600:9000:2261:6a00:1a:9c17:e740:21
2600:9000:2261:2a00:1a:9c17:e740:21
2600:9000:2261:6600:1a:9c17:e740:21
A complete packet-capture (.pcap) of one of the transmissions that failed can be found here:
https://www.icloud.com/iclouddrive/080Q ... ernet.pcap

I reproduced the failing download with the following command:

Code: Select all

curl -o /var/tmp/test https://d2uk5hbyrobdzx.cloudfront.net/objects/b6/a2e2f2833ddbcf117796ca4ac0fac6638efedb3c8536be70d4f63eabec3379.filez

As a workaround, i set the following to my end0 device:

Code: Select all

[root@rpi ~]# cat /etc/systemd/network/20-end0.link 
[Match]
MACAddress=dc:a6:32:4c:75:2c
[Link]
Advertise=10baset-full
Advertise=10baset-half
Advertise=100baset-full
Advertise=100baset-half
This caps the Ethernet speed to 100 Mbps (instead of 1 Gbps) which completely eliminates the download issues and make it perfectly working 100% of the time.

Any ideas what is wrong here? Is this a hardware fault? A bug in the network driver in the kernel? Something else? Any help is appreciated.

Thank you.

P.S.: I know that EEE is sometimes the culprit of unreliable network, but EEE is off on my raspberrypi:

Code: Select all

[root@rpi ~]# ethtool --show-eee end0
EEE settings for end0:
 EEE status: disabled
 Tx LPI: disabled
 Supported EEE link modes: 100baseT/Full
 1000baseT/Full
 Advertised EEE link modes: 100baseT/Full
 1000baseT/Full
 Link partner advertised EEE link modes: 100baseT/Full
 1000baseT/Full

pidd
Posts: 6603
Joined: Fri May 29, 2020 8:29 pm

Re: RPi 4: downloads unreliable w/ 1Gbps but not w/ 100Mbps ethernet interface speed

Sun Sep 29, 2024 7:20 pm

First thing to try with all random ethernet problems is a different ethernet cable.

kerry_s
Posts: 8464
Joined: Thu Jan 30, 2020 7:14 pm

Re: RPi 4: downloads unreliable w/ 1Gbps but not w/ 100Mbps ethernet interface speed

Mon Sep 30, 2024 1:15 am

it's not you, it's them

fedora updates/repos are the slowest of any distro

google for tweaks, there out there and sometimes help for the larger updates.

there doing that thing where it's only downloading the parts that changed, the process is slow

what fedora version are you running.

i've seen ultramarine in imager, but haven't tried it. i watch videos so i need DRM for some, so i prefer a custom raspberry os lite install.

redvli
Posts: 2953
Joined: Thu Sep 03, 2020 8:09 am

Re: RPi 4: downloads unreliable w/ 1Gbps but not w/ 100Mbps ethernet interface speed

Mon Sep 30, 2024 5:31 am

This should not be too difficult to pinpoint, as said test other cable, look in network switch/linkpartner settings, I hope you have managed switch where you can see various logs.

Fedora is not RPi specific AFAIR, so it might be the set of bootloader+firmware+kernel causes some internal mismatch. You could find and look into the PDF 'Updating the Pi firmware'. In there, there is also a download link to the kernel ZIP file. Put that on your Fedora installation, essentially config.txt determines what is booted. So then you have a stable RPi set of bootloader+firmware+kernel with Fedora userspace. Then see what happens.

Or wait until someone else also experiences the same problem with 'Version: 40.20240926.0 (2024年09月26日T15:46:00Z)' and reacts in this topic. It is very new version, so usually that means you need Fedora maintainers themselves. I use/used Opensuse Tumbleweed, same story. On this RPI forum focus is on Debian+vendorkernel, not mainline and/or U-boot/EFI, where the problem might come from.

kerry_s
Posts: 8464
Joined: Thu Jan 30, 2020 7:14 pm

Re: RPi 4: downloads unreliable w/ 1Gbps but not w/ 100Mbps ethernet interface speed

Mon Sep 30, 2024 6:20 am

yeah, fedora still uses that slow uboot
i think there the only ones still doing that to run on rpi's

redvli
Posts: 2953
Joined: Thu Sep 03, 2020 8:09 am

Re: RPi 4: downloads unreliable w/ 1Gbps but not w/ 100Mbps ethernet interface speed

Mon Sep 30, 2024 7:32 am

kerry_s wrote:
Mon Sep 30, 2024 6:20 am
yeah, fedora still uses that slow uboot
i think there the only ones still doing that to run on rpi's
'Fedora is RedHat/IBM', they set/are a standard for Linux. They likely find it more important that their Linux is driving and following the mainline kernel and multi-vendor standards then something from a tiny company that just did an IPO and uses proprietary firmware and boot-loader.

Last time I checked Fedora, it was for 13 SoCs/platforms. We now have AmpereOne, Apple M3, Qualcomm ARM laptops and more. RPL/T is not Apple (yet), maybe in 5 years or so or even earlier they are eaten by some Qualcomm or so. Or locally in Cambridge. Or it becomes a fabless micro-controller design house, who knows. Just wait until they are mainline kernel/Linux enough, then M&A and get rid of all knowhow/methods that is legacy/proprietary, that is how it works usually.

U-boot latest (2024-10-RC) is very extensive, many companies rely on U-boot, but for Pi it is a problem if you don't follow the latest FW. Actually you can't as it is closed source. So that is or can be a problem for things like initialization of the GMAC. It is not like PCI-E connected ethernet, industry effort has been done for example for UEFI Windows on ARM64.

kerry_s
Posts: 8464
Joined: Thu Jan 30, 2020 7:14 pm

Re: RPi 4: downloads unreliable w/ 1Gbps but not w/ 100Mbps ethernet interface speed

Mon Sep 30, 2024 7:42 am

there biggest problem is the "non-free" they added repo's as a option for certain software, but you still got to jump through hoops for simple video playback.

look how long it took debian to cave and include non-free, they just need more time. :lol:

breiti
Posts: 2
Joined: Sat Sep 28, 2024 8:43 pm

Re: RPi 4: downloads unreliable w/ 1Gbps but not w/ 100Mbps ethernet interface speed

Fri Oct 04, 2024 11:50 am

First thing to try with all random ethernet problems is a different ethernet cable.
Good point. I ordered a new cable and tried it with a new cable. Same issue.
google for tweaks, there out there and sometimes help for the larger updates.
This feels like cookie-cutter advice which doesn't help here. I assume this is in reference to finding a fast mirror which is fundamentally not how Fedora IoT/RPM-Ostree works. It only has one mirror

Code: Select all

[root@rpi ~]# curl https://ostree.fedoraproject.org/iot/mirrorlist
https://d2ju0wfl996cmc.cloudfront.net/
which uses cloudfronts CDN to distribute - which, because of that, is very fast, as you can see here:

Code: Select all

[root@rpi ~]# curl -o /dev/null https://d2uk5hbyrobdzx.cloudfront.net/objects/b6/a2e2f2833ddbcf117796ca4ac0fac6638efedb3c8536be70d4f63eabec3379.filez
 % Total % Received % Xferd Average Speed Time Time Time Current
 Dload Upload Total Spent Left Speed
100 131M 100 131M 0 0 10.3M 0 0:00:12 0:00:12 --:--:-- 10.5M
It' limited to 10.5M because i run the interface with 100mbps again for stability reasons, otherwise it saturates my WAN connection at 15MB/s
what fedora version are you running.
Fedora 40 (as seen in the original post by the output of rpm-ostree status).
i've seen ultramarine in imager, but haven't tried it. i watch videos so i need DRM for some, so i prefer a custom raspberry os lite install.
Not sure how this is related to my problem?
This should not be too difficult to pinpoint, as said test other cable, look in network switch/linkpartner settings, I hope you have managed switch where you can see various logs.
No, i only have a FRITZ!Box, but not sure what else a managed switch would tell me that the tcpdump wouldn't.
Fedora is not RPi specific AFAIR
Raspberry Pi 4 is officially supported since Fedora 37. See here: https://fedoraproject.org/wiki/Changes/RaspberryPi4
so it might be the set of bootloader+firmware+kernel causes some internal mismatch.
How would a bootloader impact the Ethernet after boot? I'm also not sure about how to detect a firmware mismatch. My Firmware is fairly recent, i updated it via rpi-eeprom-update about 6 months ago to the latest stable back then. Also the fedora-arm-installer has a special flag to indicate the image is for a RPi4 which copies then some special boot files. Is this what you mean?
Or wait until someone else also experiences the same problem with 'Version: 40.20240926.0 (2024年09月26日T15:46:00Z)' and reacts in this topic. It is very new version, so usually that means you need Fedora maintainers themselves.
It is not. Fedora 40 is the current stable release, being out for some time now. The timestamp just indicates the last time i ran a system wide update.
On this RPI forum focus is on Debian+vendorkernel, not mainline and/or U-boot/EFI, where the problem might come from
I'm not sure i understand correctly. Do you mean the mainline linux kernel receives no support in here?

I wont go into the discussions that happens after that which is a generic distro-related discussion and in no way related to troubleshooting this problem and it would be nice if we can keep the off-topic out of here to keep the relevant information visible. Thanks!

8 posts • Page 1 of 1

Return to "Pidora / Fedora"

AltStyle によって変換されたページ (->オリジナル) /