Hi bodhi, Quote I'm afraid that for this box, like other 32-bit processors with single CPU, the performance might get worse. You are right. The performance loss is about 10% (ranging from 7% to 11%) when upgrading to a kernel with symmetric multiprocessing. Not much to do about it, I guess, if keeping the kernel current is desired. I repeated the tests above from 8 years ago with Liby tme - Debian
Hi stalker, You may use a swap file. Details under point A here. Regards, Trond Melenby tme - Debian
Hi Adrien, Thanks for investigating! This starts looking like some hardware difference. Could it be that I have an older version of the SoC than you? These are the details of my CPU: tme@rn102:~$ lscpu | head -14 Architecture: armv7l Byte Order: Little Endian CPU(s): 1 On-line CPU(s) list:by tme - Debian
Hi adrien, Your 'dmesg' log show that my RN102 and your RN104 boot at the same rate for about 2.0 s. Then my RN102 is delayed for about 1.2 s, but after this delay, the boot processes again progress at the same rate for about 0.6 s. At this point the PCI bus is polled with diverging results due to hardware differences. Attaches a file created by 'paste' where every second lby tme - Debian
Hi bodhi and adrien, Quoteadrien60 Curiously, no lag for me This came as a surprice! I originally discovered the lagging on my RN104. It died a year ago, so I cannot repeat the test on RN104 today, but I have no reasons to believe it would differ from RN102. I have two RN102s in continous operation, one making nightly backup of the other. I just repeated the test on the other RN102 whiby tme - Debian
Hi bodhi, When I discovered the lagging some years ago, I estimated it at 6 to 7 s/min, but actually it was 1 h in 11:56 h or 60*60/(11*60+56) = 5.03 s/min as reported here. My hypothesis is that the source of the lagging is lost timer interrupts. If I've understood correctly, a fast spinning 32 bit hardware timer (sched_clock@19MHz) creates an interrupt each time the 64 bit system cloby tme - Debian
Hi Bodhi, Linux kernel version 6.17.7 installed without any issues. It seems to work as expected. Thanks! Output from 'dmesg' attached. > Please try your timing lag test with this kernel. tme@laptop:~$ ssh rn102 date && sleep 600 && ssh rn102 date Thu Nov 13 09:15:08 CET 2025 Thu Nov 13 09:24:18 CET 2025 So the lagging was 50 s in 10 minutes, or 5 s/min, juby tme - Debian
I'm sorry, adrien, for responding late on your October 16 post! 8 years ago i reported Linux kernel 5.9.3-mvebu-370xp performance on Netgear RN102/RN104 at 59% to 81% of the stock kernel performance on some simple network tests not involving disks. I expect similar results if the tests were repeated today, but would be thrilled if you prove me wrong! Regards, Trond Melenby tme - Debian
Hi bodhi, QuoteIt also works if we put the essid and password in /etc/network/interfaces and then protect this file with chmod 600. I've come to realized that the range of these very small USB-to-WiFi adapters is very short, maybe just 2 meters (6') or so. When I've been unable to reproduce issues, it may just have been thet the distance between the box and the wirless routerby tme - Debian
Hi bodhi, Problem solved. It was not a driver issue. Modifying '/etc/network/interfaces' is sufficient to connect to an open WiFi network, but to connect to a WPA or WPA2 protected network, the 'wpasupplicant' package is needed. This makes sense since '/etc/network/interfaces' is normally readable for everyone and should not include any passwords. sudo apt iby tme - Debian
Thanks bodhi, So the root file system is mounted before WiFi interfaces on USB ports are probed? I didn't know. I had no success when blacklisting any modules. When 'rtw88_8821au' is blacklisted, no other relevant modules are loaded, and 'ip a' reports no wireless interfaces. I no longer believe 'cfg80211' is a replacement for 'mac80211', ratherby tme - Debian
Thanks for trying, bodhi! Since the firmware file '/usr/lib/firmware/rtw88/rtw8821a_fw.bin' is missing in Debian 12, I assume support starts with Debian 13. My impression is that the new driver 'mac80211' (merged in kernel 6.13/6.14) is supposed to replace 'rtw88_88*', 'rtw88_core and 'cfg80211''. I think the problem might be that both 'cfby tme - Debian
Hi bodhi, To investigate further, I rolled back to Linux 6.13.8 and 6.12.6. I found no relevant differences between version 6.15.2 and 6.13.8. With 6.12.6 the USB-to-Wireless adapter is not supported. The device is detected, but the kernel does not try to load the firmware, and 'ip' does not report any wireless devices. Some details: root@rn102:~# uname -a Linux rn102 6.12.6-mvebby tme - Debian
Dear All, I've installed a USB-to-WiFi adapter in a Neatgear ReadyNAS RN102. The box is now able to scan for WiFi networks, but is unable to connect. The error message is "No DHCPOFFERS received". Connecting fails the same way on a second network. The adaper is a TP-Link AC600 Archer T600U Nano. It's the kind of adapter that barely extends out of the USB connector on theby tme - Debian
Hi bodhi, Quotetme According to 'ethtool', the wakeup-on-lan support differs between the two ports ("pg" vs." d"). Adrien60 got it right. By bringing up 'eth1' too, 'ethtool' reports the same support "pg" on both 'eth0' and 'eth1'. Sorry! Regards, Trond Melenby tme - Debian
Hi bodhi, I just upgraded the Linux kernel on my RN104 and my two RN102 boxes from version 6.12.6 to 6.13.8. No issues. Thanks for your efforts! Regards, Trond Melenby tme - Debian
Hi bodhi, Running your root file system on my RN104, 'eth0' is the upper Ethernet connector and 'eth1' the lower. According to 'ethtool', the wakeup-on-lan support differs between the two ports ("pg" vs." d"). tme@rn104:~$ uname -a Linux rn104 6.12.6-mvebu-370xp-tld-1 #1 PREEMPT Sun Dec 22 16:34:11 PST 2024 armv7l GNU/Linux tme@rn104:~$by tme - Debian
Hi bodhi, Quote I recall we removed the audio controller node from the DTB and the time lag was reduced a bit. Was that 4.9 s/min ? or is 4.9 s/min the original lag? Originally, the lagging was between 6 and 7 s/min (see https://forum.doozan.com/read.php?2,133814,133814#msg-133814). Regards, Trond Melenby tme - Debian
Thanks bodhi, After installing a the 6.12.6 kernel with the alternative dts-file and switching off the synchronization with the real time clock, the system clock is still lagging 49 seconds in 10 minutes: $ ssh rn102 date && sleep 600 && ssh rn102 date Sun 29 Dec 11:21:21 CET 2024 Sun 29 Dec 11:30:32 CET 2024 That is 4.9 s/min which is about the same as 5 months ago.by tme - Debian
Hi bodhi, Thank you again! I have successfully installed Linux kernel version '6.12.6-mvebu-370xp-tld-1' on a Readynas RN102. It seems to work a expected. Output from 'dmesg' attached. BTW, did you find anything interesting related to the lagging system time in the boot log with stock firmware posted on November 19th? Regards, Trond Melenby tme - Debian
Hi bodhi, > Does all 4 drives working on your RN104? I'm > wondering if the SATA PCI driver 88SE9170 on RN104 > works (2 bays are connected to the PCIe bus). My RN104 currently contains only 2 disks, in the 2 left most bays. I think it has contained more before, but I'm not certain. Regards, Trond Melenby tme - Debian
Hi bodhi, I did save the RN104 stock boot environment, though. Regards, Trond Melenby tme - Debian
Hi bodhi, I did not save a stock boot log from my RN104 before installing Debian and a recent kernel on it. Sorry! Regards, Trond Melenby tme - Debian
Hi bodhi, Stock boot log for RN102 attached. Regards, Trond Melenby tme - Debian
Hi bodhi, Thank you very much for your effort! I have successfully installed Linux kernel version '6.11.6-mvebu-370xp-tld-1' on a Readynas RN102. It seems to work a expected. Output from 'dmesg' attached. Regards, Trond Melenby tme - Debian
Hi bodhi, Nifty! You may skip the -u option (display the system uptime), since it's overruled by the -F option, and add '#U\n' to the string in stead. Best regards, Trond Melenby tme - Debian
Hi bodhi, Linux kernel version '6.10.11-mvebu-370xp-tld-1' seems to work as expected on Readynas RN104 too. Regards, Trond Melenby tme - Debian
Hi bodhi, Thank you very much! I have successfully installed Linux kernel version '6.10.11-mvebu-370xp-tld-1' on a Readynas RN102. It seems to work a expected. Regards, Trond Melenby tme - Debian
Thanks, bodhi! Installed on RN102: $ dmesg | grep armada [ 0.000000] armada-370: SAR Reg Addr = 0xe080f230 SAR Reg = 0x12b395 TCLK = 200 MHz [ 0.000000] armada_370_timer_init: timer_clk: 18749237 [ 0.000000] armada_370_xp_timer_common_init: timer_clk: 18749237 [ 0.007890] clocksource: armada_370_xp_clocksource: scale: 1 ns, freq: 18749237 [ 0.015204] clocksource: armaby tme - Debian
Hi bodhi, On RN102 (warm start): Marvell>> md.l 0xd0018230 1 d0018230: 0012b395 .... Marvell>> md.l 0xd0018234 1 d0018234: 00000000 .... Regards, Trond Melenby tme - Debian