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
Hi bodhi, Quote Please cold start (after shutdown for about 30 minutes) your RN102 or RN104. Interrupt u-boot at count down and dump SAR register RN102 warm start: Marvell>> md.l 0x18230 1 00018230: e12fff1e ../. Marvell>> md.l 0x18234 1 00018234: e3a00000 .... RN102 cold start: Marvell>> md.l 0x18230 1 00018230: e12fff1e ../. Marvell>> md.l 0x182by tme - Debian
Hi bodhi, Quote Please cold start your RN102 or RN104. Interrupt u-boot at count down and dump SAR register I'm currently not co-located with my TTL-to-USB adapter. I'll report when we are reunited. Regards, Trond Melenby tme - Debian
Hi bodhi, Quotebodhi Wish we have GPL source for the RN102 u-boot so we can see what it does during boot. I found a file named "ReadyNASOS_V6.6.0_WW_src.zip" dated October 2020 on my file server, but I don't recall from where I got it. Within it there is a top level directory "u-boot-2011.12-armada370" containing the GPL source code for a version of U-Boot with builby tme - Debian
Hi bodhi, Marvell>> SatR read cpufreq cpufreq = 255 Marvell>> SatR read fabfreq fabfreq = 255 Marvell>> SatR read freq Current freq mode is invalid! Marvell>> SatR read bootsrc 3(255) = opt' = user manual option (opt) Marvell>> SatR read pex pex = 65535 Marvell>> These parameters all seem to be uninitialized, so probably they are ignby tme - Debian
Hi bodhi, From RN102 U-Boot: BootROM 1.08 Booting from NAND flash General initialization - Version: 1.0.0 High speed PHY - Version: 2.1.4 (COM-PHY-V20) Update PEX Device ID 0x6710 High speed PHY - Ended Successfully 0000 DDR3 Training Sequence - Ver 5.7.1 DDR3 Training Sequence - Run without PBS. DDR3 Training Sequence - Ended Successfully BootROM: Image checksum verificatby tme - Debian
Hi bodhi, octave:1> 55/60 ans = 0.9167 octave:2> 18749237/18699646 ans = 1.0027 octave:3> (1-55/60)/(1-18749237/18699646) ans = -31.423 The observed lagging is 31 times larger than the difference in reported frequency, so there must be more to it than just the clock frequency. Regards, Trond Melenby tme - Debian
Hi bodhi, I agree. 114.8 s wrap time (Mirabox) is correct and 114.5 s (RN102) is wrong. So then it's wrong already after 6 us. I successfully installed Linux kernel version 6.9.6 on one of my RN102 boxes. It seems to work fine: $ uname -a Linux rn102 6.9.6-mvebu-370xp-tld-2 #2 PREEMPT Wed Jul 3 17:10:27 PDT 2024 armv7l GNU/Linux The relevant 'dmesg' lines are: $ dmeby tme - Debian
Hi Jungle, I just checked my second RN102. Plenty of Ethernet RX buffer overrun errors on this one, so this issue is not limited to RN104. The box has been up for about 10 weeks. The Linux kernel version is 6.7.5. This issue may have been introduced between Linux version 6.5.7 (24 Oct 2023) and 6.7.5 (13 Mar 2024), or maybe one just have to load the box sufficiently and wait long enough forby tme - Debian
Hi Jungle, QuoteI also want to be able to use the LCD or at least turn off the backlight. Did you succeed? /usr/bin/printf '\x1b[L-' > /dev/lcd should do the trick. My most relevant post on this topic is https://forum.doozan.com/read.php?9,133864,133997#msg-133997 and the next one. Regards, Trond Melenby tme - Debian
Hi Jungle, Still no Ethernet RX buffer overruns after upgrading the Linux kernel from 6.4.11 (22 Aug 2023) to 6.5.7 (24 Oct 2023): tme@rn104:~$ uname -a Linux rn104 6.5.7-mvebu-370xp-tld-1 #2 PREEMPT Thu Oct 19 18:31:43 PDT 2023 armv7l GNU/Linux tme@rn104:~$ cat /etc/debian_version 11.9 tme@rn104:~$ uptime 12:02:15 up 3 min, 1 user, load average: 0.08, 0.17, 0.08 tme@rn104:~by tme - Debian
Hi Jungle, I've checked my RN104 which is normally remote. It has indeed two Ehernet ports. Only the upper one is connected. Linux detects it as "eth0". I see no RX buffer overrun on this box neighter, but the kernel version is not the very latest. tme@rn104:~$ uname -a Linux rn104 6.4.11-mvebu-370xp-tld-1 #1 PREEMPT Mon Aug 21 16:34:49 PDT 2023 armv7l GNU/Linux tme@rn104by tme - Debian
Hi bodhi, I see. Sorry for overlooking the details! I strongly believe the cause of the lagging system clock must be inside the SOC since apparently time is lagging as soon as the kernel starts its internal timer (see https://forum.doozan.com/read.php?2,133814,133889#msg-133889 above). Regards, Trond Melenby tme - Debian
Hi bodhi, QuoteThe significant difference between the Mirabox and this RN 102/104 is: the oscillator. IIRC, the SOC in Mirabox is a stripped down version of the one in RN 102/104, so the oscillators are the same. If the DTSs are different, Mirabox seems to have the right one. Yes? Regards, Trond Melenby tme - Debian
Hi Jungle, This is the thread about the system clock lagging on RN102/RN104: https://forum.doozan.com/read.php?2,133814 My current main hypothesis is that one of the unused modules in the SOC is not properly disabled and generates spurious interrupts that causes the kernel to sometimes miss the timer interrupts that updates the 64 bit system clock. It's thinkable that the same spuriousby tme - Debian
Hi bodhi, QuoteHave you seen this problem that Jugle is seeing with networkk receive buffer overrun? No, I have not: tme@rn102:~$ uptime 19:45:39 up 5 days, 5:10, 2 users, load average: 0.00, 0.00, 0.00 tme@rn102:~$ dmesg | grep overrun tme@rn102:~$ IIRC, RN104 has two ethenet ports, while RN102 has one. The SOC has two interfaces on both. Could it be that the overrun occurs on tby tme - Debian
Hi bodhi, QuoteI just don't like to see the kernel bootargs being messed up. I halted U-Boot, modified "sata_set_bootargs" and booted five times: root@rn102:~# dmesg | grep mtdparts | fold -sw 80 [ 0.000000] Kernel command line: console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 earlyprintk=serial mtdparts=pxa3xx_nand-0:0x180000@0(u-boot),0x20000@0x180000(u-boot-enby tme - Debian
Hi bodhi, QuoteI think you might be right about the timing difference. I ran the new kernel on the Mirabox for a day, and saw no BUG. When the line "BUG: scheduling while atomic" appears on the serial console (and later in the 'dmesg' output), it is always between 27 s and 30 s into the kernel boot. It is always followed by two debug stack dumps as in the attachment to thby tme - Debian