GTI Mirabox, Netgear RN102/RN104, Netgear RN2120 Installation & Kernel Upgrade (Linux-6.12.6)

Quote

Fixed. It appears that whoever created the page for the RN104 just copied my data for the RN102!

Thanks Ray!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

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 Melen

Thanks Trond!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Kernel 6.12.6-mvebu-370xp-tld-1 package has been uploaded. Please see 1st post for download link.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> Kernel 6.12.6-mvebu-370xp-tld-1 package has been
> uploaded. Please see 1st post for download link.


Hi Bodhi,

Kernel works great, thks !

Additionally, I could verify that the 4 disk leds can be triggered on my RN104 :)

The leds are in inverted order, then in /etc/rc.local :

echo "ide-disk4" > /sys/class/leds/rn104:blue:sata1/trigger
echo "ide-disk3" > /sys/class/leds/rn104:blue:sata2/trigger
echo "ide-disk2" > /sys/class/leds/rn104:blue:sata3/trigger
echo "ide-disk1" > /sys/class/leds/rn104:blue:sata4/trigger

adrien60,

> Kernel works great, thks !
>
> Additionally, I could verify that the 4 disk leds
> can be triggered on my RN104 :)
>

Cool!

> The leds are in inverted order

:) as long as we know the order, and can control them, I think it's OK for now.

I'm guessing Arnaud (the original developer of the RN104 DTS) did not notice this.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

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 Melen

Hi Trond,

> 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.

Thanks for the report!

>
> BTW, did you find anything interesting related to
> the lagging system time in the boot log with stock
> firmware posted on November 19th?

I've briefly looked at it. The only thing stands out is in u-boot.

Quote

Shutting down unused interfaces:
GBE0
SDIO
AUDIO
TDM

I recalled we tried removing an interface (Audio) and the time lag seems to improve a bit. That was a good sign, it's consistent with your theory about interrupts still firing for unused interfaces.

When I can look at this problem again, I think we'll start with updating the DTS and DTSI for this board to remove these interfaces.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi Trond,

Please recreate your uImage using the attached DTB. And try running your timelag test.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

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.

Regards,
Trond Melen

Hi Trond,

> That is 4.9 s/min which is about the same as 5
> months ago.

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?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi bodhi,

I recently setup unattended upgrades on my system, but I just remembered reading a note you made on here about having to regenerate the iniramfs:

Quote
bodhi
Warning: Watch the apt-get upgrade progress. If the apt-get upgrade results in a new initramfs, the log would shows this message:

update-initramfs: Generating /boot/initrd.img-5.13.8-mvebu-tld-1

Then you need to regenerate the uInitrd boot file:

cd /boot
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs 6.6.2-mvebu-tld-1 -d initrd.img-6.6.2-mvebu-tld-1 uInitrd

Is this going to be an issue when using unattended updates?

Thanks,
Jungle

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 Melen

Jungle,

> Is this going to be an issue when using unattended
> updates?

If you don't reboot automatically after unattended upgrades, then there is no problem running the system.

The potential issue is when you reboot the system after unattended upgrades. The system should boot OK with the old initramfs (in the old uInitrd). But things might have changed in the rootfs related to the Debian boot process will not be reflected in the reboot.

This is a limitation of old u-boots. We need the uInitrd (with its u-boot legacy header) to boot boxes that can not boot the initramfs image as is.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Ok, thanks bodhi.

Jungle

Hi Trond,

> 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).
>

Thanks! based on that, the kernel drivers seems to be the problem.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)