johang
commented
6 months ago Do you have packet loss? You can confirm this with ping. Try forcing 100 Mbps and 10 Mbps and see if that improves it. Sounds like a HW issue to be honest.
Open DaveWK opened 6 months ago
johang
commented
6 months ago Do you have packet loss? You can confirm this with ping. Try forcing 100 Mbps and 10 Mbps and see if that improves it. Sounds like a HW issue to be honest.
DaveWK
commented
5 months ago Hi,
I confirmed with ping and wireshark that I am getting packet loss when running these sd-images. I have tried a few different cords, and switches to confirm they were in working order. Each time when I get into a root shell and run apt update it will have stalled out in a few seconds due to retransmission and packet loss.
But in counter-point to it being a hardware issue,
when I test using the latest Armbian Trixie rolling release (6.6.10). I am able to finish an initial apt update successfully before the network connection slows down substantially.
I noticed this merge in arbian commit that seems to give the nics some extra time to power up: https://github.com/armbian/build/commit/ac9373aca47fe6967827503bd32eb5d66b8a7128
I suspect that the issue may be the issue?
johang
commented
5 months ago DaveWK
commented
5 months ago Interesting -- I will give that a shot to see if that improves anything, but my current armbian dts isn't using that.. here's my live one:
ethernet@ff540000 {
compatible = "rockchip,rk3328-gmac";
reg = <0x00 0xff540000 0x00 0x10000>;
interrupts = <0x00 0x18 0x04>;
interrupt-names = "macirq";
clocks = <0x02 0x64 0x02 0x57 0x02 0x58 0x02 0x5a 0x02 0x59 0x02 0x96 0x02 0xdf>;
clock-names = "stmmaceth\0mac_clk_rx\0mac_clk_tx\0clk_mac_ref\0clk_mac_refout\0aclk_mac\0pclk_mac";
resets = <0x02 0x63>;
reset-names = "stmmaceth";
rockchip,grf = <0x3d>;
snps,txpbl = <0x04>;
status = "okay";
assigned-clocks = <0x02 0x64 0x02 0x66>;
assigned-clock-parents = <0x54 0x54>;
clock_in_out = "input";
phy-mode = "rgmii";
phy-supply = <0x1e>;
pinctrl-0 = <0x55>;
pinctrl-names = "default";
snps,aal;
phy-handle = <0x56>;
tx_delay = <0x19>;
rx_delay = <0x05>;
phandle = <0xa1>;
mdio {
compatible = "snps,dwmac-mdio";
#address-cells = <0x01>;
#size-cells = <0x00>;
ethernet-phy@0 {
compatible = "ethernet-phy-id4f51.e91b\0ethernet-phy-ieee802.3-c22";
reg = <0x00>;
motorcomm,clk-out-frequency-hz = <0x7735940>;
motorcomm,keep-pll-enabled;
motorcomm,auto-sleep-disabled;
pinctrl-0 = <0x57>;
pinctrl-names = "default";
reset-assert-us = <0x3a98>;
reset-deassert-us = <0xc350>;
reset-gpios = <0x2b 0x12 0x01>;
phandle = <0x56>;
};
};
};
Hi, I have been checking out the images for the Orange Pi R1 Plus LTS, and after it finishes booting, when I attempt to do anything that requires network connectivity such as running apt update, within a few seconds the connection gets increasingly slow to the point it no longer is functional. The YT8531 is detected by all of the images:
and gets an IPv4 address from DHCP. Within a few seconds the connection just gets slower and slower, down to a few bits a second. I have tried different cables, as well as multiple routers, as well as crossover to rule out any external hardware issue. I did notice when running wireshard that it appears to be sending out a lot of TCP retransmissions when this is occurring.
I have tried all 4 of the images, and they all have the same issue. I have also noticed I can't seem to get the second NIC to be detected by the OS or powered on at all. I also was able to validate with a USB Wireless Cellular connection that it is able to connect to the internet and download things fine (using a serial connection since eventually SSH drops off)
I suspect it may be a u-boot problem since it happens in all of the images, but am not sure how to debug any potential power-up/regulator issues that might be occurring.
Here's my output from
lsmodon trixie:Here's also my output from
ifconfig:which has that entry for
device interruptat the end which looks suspicious, but it may be a symptom rather than the cause.