I think I've tried everything. Already tried what you're asking now.
I tried making a backup from v24.X and restoring it on a newly flashed v24.X (I also tried flashing using rufus)
The problem persists. IMO, It's just my single glitchy R4S that refuses to work with latest kernel.
I'm at peace with it, in the future I'll get another R4S or maybe upgrade to R6S. For now v23.X is fine (and I guess it'll be fine for the coming year).
I am wondering if kernel 6.6 could be drawing more power that is causing this glitch (at least I noticed an R5S running hotter with kernel 6.6 than with previous kernel).
Just a sanity check question: have you tried 24.10 with a different power supply and power cable?
Sounds suspiciously like a power supply issue.
For NanoPI R4S(E) power supply they recommend 5V/3A. As for me, it does not exceed more than 6W (I measure at the switch port). But it's possible that at peak it needs more and if it won't cause problems.
Yup, as I said before.
Already tried different powersupply (up to 65watt) and cable.
For now I'll let it rest. I wanna stream some movies/series now trough my working internet connection. Can't keep on checking this thread 
Thnx for all the replies and help. Great community!!!
I came across this too, might be useful.
5V/3A and above USB Type-C interface power adapter (Note: QC/PD fast charger may have compatibility issues)， it is recommended to use the following or similar power adapter: 5V 4A Power Adapter
(There used to be a link but it doesn't work anymore.)
https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R4S
Have a nice holiday and good luck 
Just to follow up with last my last effort. Even with the Raspberry Pi EB82182 adaptor (5.1v 5A) my ETH1 problem occurs.
I feel like I've tried all. it's ok, sometimes things happen.
@ChrisNL See how it is for you with eth1 working and not working.
root@vr1 44.44℃ :~# lspci -v
00:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3399 PCI Express Root Port (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 84
Bus: primary=00, secondary=01, slave=01, sec-latency=0
Memory behind bridge: fa000000-fa0fffff [size=1M] [32-bit]
Capabilities: [80] Power Management version 3
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable+ 64bit+
Capabilities: [b0] MSI-X: Enable- Count=1 Masked-
Capabilities: [c0] Express Root Port (Slot+), MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [274] Transaction Processing Hints
Kernel driver in use: pcieport
lspci: Unable to load libkmod resources: error -12
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 15)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller
Flags: bus master, fast devsel, latency 0, IRQ 83
Memory at fa004000 (64-bit, non-prefetchable) [size=4K]
Memory at fa000000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [b0] MSI-X: Enable+ Count=4 Masked-
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00
Capabilities: [170] Latency Tolerance Reporting
Capabilities: [178] L1 PM Substates
Kernel driver in use: r8169
And this too:
root@vr1 43.88℃ :~# ethtool -i eth1
driver: r8169
version: 5.10.201
firmware-version: rtl8168h-2_0.0.2 02/26/15
expansion-rom-version:
bus-info: 0000:01:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
root@vr1 44.44℃ :~# ethtool -i eth0
driver: st_gmac
version: Jan_2016
firmware-version:
expansion-rom-version:
bus-info:
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
The other thing I can think of is to share the dmesg log. Someone might see something you missed.
The documentation says that R4S does not work with PD adapters. An option is from some start phone to try with it. But in general I think it's not the adapter. If it was a hardware issue, it would have been an issue on other versions.
Since I don't know version 24 with which version of kernel, You could try another axis with that version of kernel, for example armbian.
Good luck with debugging the problem.
@fever_wits Thnx for your reply and efforts to help me troubleshoot/debug.
To be honest last hour I've spent swapping out my R4S with an OrangePi R1 Plus LTS (I almost forgot I also have that SBC).
I've got the OrangePi R1 Plus LTS effortlessly running with https://downloads.openwrt.org/releases/24.10-SNAPSHOT/targets/ (build date 10 dec)
Since I only have a FTTH 100/100 pppoe connection to do SQM & adblock with, even the Rockchip RK3328 is powerfull enough for my needs. Bonus point, it draws a little less power then the R4S.
Now I feel my setup is perfect again. No more problems running latest version of OpenWRT. When 24.X becomes stable I'll be able to run those builds.
Last days I've been flashing / swapping SD cards and troubleshooting so much, I feel like not wanting to touch/test or even look at my glitchy R4S for the coming months. 
For me a solid SBC with OpenWRT is all I wanted. Just enjoying the stable uptime between OpenWRT updates 
Cheers!
Can anyone help me?
I had the following setup:
Backend - Switch (Zyxel GS1900-8) - NanoPi R4S - AVM Fritxbox 6490 (Bridge by Vodafone) - Internet
All nics supported 1 gbit/s and so i was able to use the full vodafone cable 500 mbit/s line.
Now i had to change the AVM Fritzbox 6490 to an 6591 and the NanoPi just supports 100 mbit/s.
I tested the following: I connected switch directly to the Fritzbox and both devices show 1 gbit/s.
Here is the output of ...
[root@NanoPi-R4S ~]$ ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: external
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: ug
Wake-on: d
Current message level: 0x0000003f (63)
drv probe link timer ifdown ifup
Link detected: yes
Any hints?
As I understand it, you are replacing an AVM Fritzbox 6490 model with a modem: the AVM Fritzbox 6591 and in both cases the NanoPi is hooked directly to the modem.
If I've understood correctly, it's probably either a software configuration of the port on the new modem which coupling/links to the 100mbit or a bad cable.
If the modem is configured correctly for 1gbit, you could try stopping Autonegotiate on eth0
root@vr1 43.88℃ :~# **ethtool -a eth0**
Pause parameters for eth0:
Autonegotiate: on
RX: off
TX: off
RX negotiated: off
TX negotiated: off
root@vr1 43.88℃ :~# **ethtool -A eth0 autoneg off**
root@vr1 43.88℃ :~# **ethtool -a eth0**
Pause parameters for eth0:
Autonegotiate: off
RX: off
TX: off
Changing the live setting may cause the interface to drop if there is incorrect configuration on the other side.
Good luck
Thanks 
The new AVM 6591 is also in bridge mode as the older one.
I changed the cable (new and short one now) and checked the portsettings of the 6591 (port is in power mode = 1 gbit/s).
Auto-negotiation is on
I will try this one here later when i am at home:
sudo ethtool -s eth0 speed 1000 duplex full autoneg off
I've found out that if I configure rps_cpus manually, i.e
echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus
after sometime it resets to 0.
Since I have packet steering disabled, probably it's related to this:
The suggested solution of creating a script in /etc/hotplug.d/net also gets the config reset.
I think the solution is creating the file /usr/libexec/platform/packet-steering.sh, at least according to this:
FriendlyARM NanoPi R4S 1GB not bootable，is the official plan not to support it?
may someone found the same problem
This is fixed in snapshot, merged 3 days ago.
rockchip: disable kernel preemption #17575
It was also merged in 24.10, next release under 24.10 branch will have this patch.