Debian on RN104

Hi,

I'll start by saying im not an expert at Linux (my main experience comes from using raspberry pi's)

I have installed Debian on my RN104 but im having a couple of issues with it.
I used this guide: https://web.archive.org/web/20230909154806/https://www.katerkamp.de/howto/osinstall/rn104-d-i.xhtml
but I installed bookworm instead.

I keep getting buffer overruns on the ethernet which slows down transfers alot and systemd-journal churns out tons of messages causing high CPU usage.
If I use wifi on the client side its not as bad but still has lots of overruns and is still slower then stock.

I've tried lowering the MTU but made it worse and I'm a little hesitant to start messing with the network as its a headless device and dont want to lose SSH access.

------------------------------------------------------------------------------------------

I also want to be able to use the LCD or at least turn off the backlight.
I see an entry in the DTB for Aux Display but dont think its setup as theres nothing in /sys/class/ although there is a 'backlight' entry but:

cat /sys/class/backlight/value
returns:
cat: /sys/class/backlight/value: No such file or directory

I can see other entires listed in /sys/class/gpio & /sys/class/leds but they seem to be for the disk indicators and power buttons.

I found this post:https://forum.doozan.com/read.php?9,133864
which relates to the LCD but i'm using a different system.


Any help would be appreciated..

Thanks,
Jungle



Edited 1 time(s). Last edit at 06/01/2024 06:59AM by jungle_roger.

Jungle,

> I keep getting buffer overruns on the ethernet
> which slows down transfers alot and
> systemd-journal churns out tons of messages
> causing high CPU usage.
> If I use wifi on the client side its not as bad
> but still has lots of overruns and is still slower
> then stock.

We don't have this problem runing my rootfs.

Best if you post the output of dmesg and some of those messages. If you have serial console then post the serial console boot log.

> I also want to be able to use the LCD or at least
> turn off the backlight.
> I see an entry in the DTB for Aux Display but dont
> think its setup as theres nothing in /sys/class/
> although there is a 'backlight' entry but:
>
> cat /sys/class/backlight/value
> returns:
> cat: /sys/class/backlight/value: No such file or
> directory
>
> I can see other entires listed in /sys/class/gpio
> & /sys/class/leds but they seem to be for the disk
> indicators and power buttons.
>
> I found this
> post:https://forum.doozan.com/read.php?9,133864
> which relates to the LCD but i'm using a different
> system.

It is quite applicable to your systemd Debian rootfs. It will work the same way, except for a few places where Trond mentioned a sysvinit- specific places, which you need to translate to systemd.

But overall, the testing using printf to write to /dev/lcd should be same in any Linux system.

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

Hi,
Thanks for the reply.

I wish I had installed your one first but only found it after.
Do you think there will be an issue just installing yours as I've already followed a different method? or would I need to restore to stock/defaults first?

Thanks,
Jungle

jungle_roger Wrote:
-------------------------------------------------------
> I have installed Debian on my RN104 but im having
> a couple of issues with it.
> I used this guide:
> https://web.archive.org/web/20230909154806/https://www.katerkamp.de/howto/osinstall/rn104-d-i.xhtml
> but I installed bookworm instead.
>
I'm glad I went to this link and read it as I learned about a useful new tool! I had not heard about the "ModuleAssistant" before, but I will be making extensive use of it in the future.

Ray

Jungle,

> Do you think there will be an issue just
> installing yours as I've already followed a
> different method? or would I need to restore to
> stock/defaults first?

It's won't be an issue installing, but you need to connect serial console. Take a look at the Initial Installation instruction here and see if you are comfortable with doing manual installation like this.

https://forum.doozan.com/read.php?2,92514

Quote

II. Netgear RN102 Intsallation
Updated 06 Sept 2020
Updated 19 Dec 2022 (added Section C)

========

Since you already have a Debian rootfs, you could also try to install and run my released kernel (latest kernel is linux-6.8.7-mvebu-370xp-tld-1). But the rootfs /boot files structure is probably different, that we need to verify and see how the boot files must be created after running dpkg to install kernel.

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

hi Bodhi,

I just did a fresh install with usb, had to use the old 5.2.9 rootfs with the 6.8.7 kernel as the rootfs 6.6.2 with built-in kernel didn't work.
I dont need to 'update' the rootfs, do i?

But good news, no more ethernet overruns and the lcd backlight is off!


Thanks!

> I just did a fresh install with usb, had to use
> the old 5.2.9 rootfs with the 6.8.7 kernel as the
> rootfs 6.6.2 with built-in kernel didn't work.
> I dont need to 'update' the rootfs, do i?

Jungle,

Whenever you like to update is fine, if you only use the box locally in a closed network.

But eventually you'll need to do dist-upgrade for the rootfs 5.2.9 to Debian bookworm to avoid protential problems. As Debian progress to newer version, it will be more complicate to jump version (i.e. bullseye 11 to trixie 13).


So I'd say once you are happy that the system is running well, backup the USB rootfs, and then do dist-upgrade to bookworm.


> But good news, no more ethernet overruns and the
> lcd backlight is off!
>

Cool!

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

Hey Bodhi,

Looks like I spoke too soon, I'm still getting ethernet overruns.
I've started on your rootfs 5.2.9 with kernel 6.8.7
I've been able to update to bookworm but it hasn't fixed it.

The dmesg and serial logs are attached:


Thanks
Jungle



Edited 1 time(s). Last edit at 06/10/2024 06:08AM by jungle_roger.

Jungle,

You're seeing the same problem as Trond did on the RN102 with kernel 6.8.7.

I did mark it as broken

Quote

Updated 21 May 2024:

Kernel linux-6.8.7-mvebu-370xp-tld-1-bodhi.tar.bz2 package has been uploaded.

New/Updated in this release:

- General kernel upgrade.
- Warning: this kernel version is broken on the Netgear RN102 and 104. Please stay with previous kernel if you have these 2 boxes.

So install kernel linux-6.5.7-mvebu-370xp-tld-1

Quote

Updated 24 Oct 2023:

Kernel linux-6.5.7-mvebu-370xp-tld-1 package has been uploaded.

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



Edited 1 time(s). Last edit at 06/10/2024 02:29PM by bodhi.

Thanks Bodhi,

I've installed the 6.5.7 kernel and it got rid of of the "BUG: scheduling while atomic" error but I'm still getting lots of overrun errors:

[  310.133162] mvneta d0070000.ethernet eth0: bad rx status 0f830000 (overrun error), size=384

Jungle

Jungle,

Get the status to see if there are errors in RX and TX.

ifconfig -a

====

Try these to see if it helps

1. Turn off flow control

ethtool -A eth0 autoneg off rx off tx off

2. Swap your network cable with a different one.

=====

We don't have network buffer management in the DTS for this box. I'm not sure why, perhaps this network chip (88e1318) does not have that capability. I tried to connect to natisbad.org as I recall he had this Reference Manual.

With that said, even if there is no HW buffer, the network driver buffer should have prevented the overuns. What was the box activity when these overuns occured? are you downloading something or do network files transfering?

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

Hi,

It happens during file transfers using smb and its only RX:

RX packets 49808615  bytes 70509970400 (65.6 GiB)
RX errors 25511  dropped 0  overruns 0  frame 0
TX packets 5850581  bytes 54137665733 (50.4 GiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Turning off flow control and swapping cables has no effect.
There's not much else running as all I have installed is samba and mariadb.

Tasks: 145 total,   2 running, 143 sleeping,   0 stopped,   0 zombie
%Cpu(s):  4.5 us, 63.5 sy,  0.0 ni,  2.6 id,  0.0 wa,  0.0 hi, 29.4 si,  0.0 st
MiB Mem :    489.7 total,    112.2 free,    267.2 used,    308.4 buff/cache
MiB Swap:   1953.1 total,   1826.5 free,    126.7 used.    222.5 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 3634 ****      20   0  103968  10604   8244 R  72.6   2.1   4:03.27 smbd
 1418 root      20   0   50628   9936   9668 S   6.5   2.0   1:58.18 systemd-journal
 4270 root      20   0       0      0      0 I   6.1   0.0   0:00.28 kworker/u2:1-events_unbound
   48 root      20   0       0      0      0 S   5.8   0.0   4:28.13 kswapd0
 3976 root      20   0       0      0      0 I   2.3   0.0   0:01.91 kworker/u2:2-writeback
 4268 ****      20   0    6676   3960   1948 R   1.6   0.8   0:00.38 top
 1293 root      20   0       0      0      0 S   1.3   0.0   0:39.18 usb-storage
   15 root      20   0       0      0      0 S   0.3   0.0   0:22.75 ksoftirqd/0
   16 root      20   0       0      0      0 I   0.3   0.0   0:16.91 rcu_preempt
 3939 ****      20   0   11144   3280   3000 S   0.3   0.7   0:02.12 sshd
    1 root      20   0   32424   4216   3148 S   0.0   0.8   0:14.07 systemd

Thanks,
Jungle



Edited 2 time(s). Last edit at 06/12/2024 03:42AM by jungle_roger.

Jungle,

Make sure you are running the 6.5.7 kernel.

Reboot, login and don't turn off flow control. Just leave the defaut whatever it is. And get the current settings

ifconfig -a
ethtool eth0

(you should mask out the MAC addresses from ifconfig output).

======

I'm still looking for the datasheet for this chip 88e1318.

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



Edited 1 time(s). Last edit at 06/12/2024 03:14PM by bodhi.

Hey Bodhi,

Here's uname -a:

Linux ***** 6.5.7-mvebu-370xp-tld-1 #2 PREEMPT Thu Oct 19 18:31:43 PDT 2023 armv7l GNU/Linux

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.15  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::2ac6:8eff:fe34:5030  prefixlen 64  scopeid 0x20<link>
        ether **:**:**:**:**:**  txqueuelen 1024  (Ethernet)
        RX packets 328  bytes 26735 (26.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 305  bytes 37950 (37.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 36

Settings for eth0:
        Supported ports: [ TP    MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: external
        MDI-X: Unknown
        Supports Wake-on: pg
        Wake-on: d
        Link detected: yes

Thanks,
Jungle

How about

ethtool -a eth0

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

And does your Gbit network set up for jumbo frame?

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

Pause parameters for eth0:
Autonegotiate:  on
RX:             off
TX:             off
RX negotiated: on
TX negotiated: on

I have an unmanaged gbit switch and a router that doesn't support jumbo frames.


Not sure if it's related but my system clock lost a hour overnight. (I have to set the time on every reboot)


Jungle



Edited 3 time(s). Last edit at 06/13/2024 07:24AM by jungle_roger.

Jungle,

The good new is Trond did not see network buffer overun on his box. See this recent post the installation thread.

>

> Pause parameters for eth0:
> Autonegotiate:  on
> RX:             off
> TX:             off
> RX negotiated: on
> TX negotiated: on
>

Looks like the default is not fully flow control. Try:

ethtool -A eth0 autoneg on rx on tx on
ethtool -a eth0

> Not sure if it's related but my system clock lost
> a hour overnight. (I have to set the time on every
> reboot)

Unfortunately, this is a problem with the Netgear RN102 and 104. Also see the installation thread for our ongoing discussion about this issue.

Time is not lagging on the Mirabox (I have this box) and we are running the same kernel. So it is hard to see.

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

Quote
bodhi
Looks like the default is not fully flow control. Try:
ethtool -A eth0 autoneg on rx on tx on
ethtool -a eth0

Unfortunately has the same result.


Jungle

Jungle,

This problem was reported for this RN104 box (in the kernel ML) about 5-6 years ago. But I did not see any specific patch submitted afterward, so not sure if people have fixed the root cause.

Perhaps you should run your box with a cron job to adjust the system clock, like Trond did in the installation thread. I think it will potentially help in timer-related tasks.

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

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 spurious interrupts clogs the kernel so that it sometimes fail to handle a full Ethernet receive buffer, but it may of course have some other explanation.

Regards,
Trond Melen

Thanks guys,

I'm just using systemd-timesyncd now, which is keeping the clock up to date.

----------------------------------------------------

Found this:
Netgear forum

Seems like it happens on stock aswell.


Jungle



Edited 1 time(s). Last edit at 06/15/2024 05:33AM by jungle_roger.

Jungle,

> I'm just using systemd-timesyncd now, which is
> keeping the clock up to date.

Yeah, please let use know after you setup the clock sync. Trond might have solved this buffer overrun issue indirectly with this workaround.

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

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@rn104:~$ cat /etc/debian_version 
11.9

tme@rn104:~$ uptime
 10:59:33 up 9 days, 15:53,  1 user,  load average: 0.00, 0.00, 0.00

tme@rn104:~$ dmesg | grep overrun
tme@rn104:~$

Are you using both the Ethernet ports?

Regards,
Trond Melen

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:~$ dmesg | grep overrun
tme@rn104:~$

Regards,
Trond Melen

Hi Jungle,

Quote

I 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 Melen

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 for the issue to appear also in the former version?

tme@rn102:~$ uname -a
Linux rn102 6.7.5-mvebu-370xp-tld-2 #2 PREEMPT Wed Feb 21 15:11:27 PST 2024 armv7l GNU/Linux

tme@rn102:~$ cat /etc/debian_version 
11.9

tme@rn102:~$ uptime
 12:35:34 up 69 days, 15:13,  1 user,  load average: 0.13, 0.20, 0.16

tme@rn102:~$ dmesg | grep overrun | wc -l
1478

tme@rn102:~$ dmesg | grep overrun | head -5
[529141.228231] mvneta d0074000.ethernet eth0: bad rx status 0f830000 (overrun error), size=336
[529141.297725] mvneta d0074000.ethernet eth0: bad rx status 0f830000 (overrun error), size=1344
[529141.501540] mvneta d0074000.ethernet eth0: bad rx status 0f830000 (overrun error), size=1088
[529141.651565] mvneta d0074000.ethernet eth0: bad rx status 0f830000 (overrun error), size=448
[529141.710757] mvneta d0074000.ethernet eth0: bad rx status 0f830000 (overrun error), size=1440

529141 seconds are roughly 6 days.

Regards,
Trond Melen

Hi Trond,

I'm only using the top port (eth0)

I haven't tried the LCD yet as my main issue was the back-light being on constantly but it gets switched off automatically at the end of boot with this setup. I'm going to leave that for now.

I'm currently on the 6.5.7 Kernel as I had updated to bookworm with the 6.8.7 kernel and had the atomic bug. Would it be worth me trying an older kernel?

You mentioned waiting long enough (6 days) but I get the errors immediately after boot when transferring files.

Quote
Bodhi
Yeah, please let use know after you setup the clock sync. Trond might have solved this buffer overrun issue indirectly with this workaround.

I read through the install thread and your "Time is lagging" thread but am not sure what Bodhi means, is it the cron to sync the system clock to the hardware clock bit? (which I've tried and does keep the clock up to date but has not effect on the overrruns)


Thanks,
Jungle