johang
commented
10 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 10 months ago
johang
commented
10 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
10 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
10 months ago DaveWK
commented
10 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.