Optimized build for the D-Link DIR-860L

If you only want to spread out ethernet interrups across all or certain CPUs only use packet steering. For shotgun spreading of devices use irqbalance. However, a script can be better since there you can define which devices should get which CPU(s). There is such a script floating around for the DIR860L on this forum

1 Like

Found it, all credits go to @dissent1, change /etc/init.d/set_cpu_affinity:

#!/bin/sh /etc/rc.common

set_irq_affinity() {
	local name="$1"
	local val="$2"

  	local irq=`grep -m 1 "$name" /proc/interrupts | cut -d: -f1 | sed 's, *,,'`
	[ -n "$irq" ] && $(echo "$val" > "/proc/irq/$irq/smp_affinity") || echo "$name irq not found."

start() {

. /lib/functions.sh

local board=$(board_name)

case "$board" in
	set_irq_affinity mt7603e 1
	set_irq_affinity xhci-hcd:usb1 4
	set_irq_affinity mt76x2e 8
	set_irq_affinity 1e100000.ethernet 2
	echo "Unsupported hardware. CPU affinity is not adjusted."
1 Like

Just noticed this commit in nbd's git where he disables packet steering by default since: "mt76 now spreads the load over multiple CPUs more smoothly, processing
ethernet packets should be faster running on one core"

1 Like

That means i don´t need packet steering and irqbalance anymore? And is that rc.local script for irqbalance?

And thank you for the answers :slight_smile:

With the script you set the irq affinities manually and thus you shouldn't need irqbalance anymore.
That being said, irqbalance is a one-size-fits-all solution, the script is more tailored. However, for your situation there might be more optimal irq affinities. So, put the scripts through it's paces but don't be afraid to change stuff around and see how that works.

1 Like

Is there a way to disable airtime fairness on mt76 or is it always on?

It is on by default but if my memory serves me correct there is a switch to disable it.
Edit, this should do the trick:

echo 0 > /sys/kernel/debug/ieee80211/phy0/airtime_flags
echo 0 > /sys/kernel/debug/ieee80211/phy1/airtime_flags

Hmmm.... I wonder if that's correct since it says currently (unmodified)

 cat /sys/kernel/debug/ieee80211/phy1/airtime_flags
AIRTIME_TX      (1)
AIRTIME_RX      (2)

...and no it isn't

echo 0 > /sys/kernel/debug/ieee80211/phy1/airtime_flags
ash: write error: Invalid argument

Hey @Bartvz, can I also use this script with r12255?
My interrupts look like this (~13 days uptime):

cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
  8:  109812986  109813002  109813005  109812997  MIPS GIC Local   1  timer
  9:     100717          0          0          0  MIPS GIC  63  IPI call
 10:          0  166207419          0          0  MIPS GIC  64  IPI call
 11:          0          0  185423737          0  MIPS GIC  65  IPI call
 12:          0          0          0  177350536  MIPS GIC  66  IPI call
 13:    1783367          0          0          0  MIPS GIC  67  IPI resched
 14:          0    3311045          0          0  MIPS GIC  68  IPI resched
 15:          0          0    3511158          0  MIPS GIC  69  IPI resched
 16:          0          0          0    5092951  MIPS GIC  70  IPI resched
 19:         12          0          0          0  MIPS GIC  33  ttyS0
 20:          0          0          0          0  MIPS GIC  29  xhci-hcd:usb1
 21:  776860750          0          0          0  MIPS GIC  10  1e100000.ethernet
 22:        214          0          0          0  MIPS GIC  30  gsw
 23:        399          0  197040031          0  MIPS GIC  11  mt76x2e
 24:  239033051          0          0          0  MIPS GIC  31  mt76x2e
 26:          0          0          0          0      GPIO   7  keys
 27:          0          0          0          0      GPIO  18  keys
ERR:     165929

r14284 installed through LuCI forcing the update and without keeping settings.
Reconfigured all by hand, but at the first reboot the settings are gone :frowning:
I will try to flash from d-link recovery, but it seems that we still have the same problem of all previous 5.4 kernel builds...

Sysupgrade from ssh never got me into this trouble,

1 Like

just updated with sysupgrade from ssh, but at every reboot I am continuing to lose all settings.
below the command I used for the upgrade:

root@OpenWrt:/tmp# sysupgrade -v -n -F /tmp/openwrt-ramips-mt7621-dlink_dir-860l
Device dlink,dir-860l-b1 not supported by this image
Supported devices: dlink,dir-860l-b1 dir-860l-b1 - Image version mismatch: image 1.1, device 1.0. Please wipe config during upgrade (force required) or reinstall. Reason: Config cannot be migrated from swconfig to DSA (early adopters with DSA already set up may just force-flash keeping existing config)
Image check failed but --force given - will update anyway!
Commencing upgrade. Closing all shell sessions.
Connection to closed by remote host.
Connection to closed.

Any ideas?

Do not use -n in the command. BTW, which version are you upgrading from?

I am upgrading from r12255, will try without -n option but I am not confident it will make any difference. PS: just for fun I tried also to upgrade from recovery with factory bin file, but it is the same (no settings kept after reboot)

Might be because I have stripped out debug info. Needs more testing

You can use the script but you have to modify the board names. Newer build that I am on has a few fixes, uptime is over 2 days and I only have:

ERR: 352

Usage: /sbin/sysupgrade [<upgrade-option>...] <image file or URL>
       /sbin/sysupgrade [-q] [-i] [-c] [-u] [-o] [-k] <backup-command> <file>

        -f <config>  restore configuration from .tar.gz (file or url)
        -i           interactive mode
        -c           attempt to preserve all changed files in /etc/
        -o           attempt to preserve all changed files in /, except those
                     from packages but including changed confs.
        -u           skip from backup files that are equal to those in /rom
>>      -n           do not save configuration over reflash
        -p           do not attempt to restore the partition table after flash.
        -k           include in backup a list of current installed packages at
        -T | --test
                     Verify image and config .tar.gz but do not actually flash.
        -F | --force
                     Flash image even if image checks fail, this is dangerous!
        -q           less verbose
        -v           more verbose
        -h | --help  display this help

        -b | --create-backup <file>
                     create .tar.gz of files specified in sysupgrade.conf
                     then exit. Does not flash an image. If file is '-',
                     i.e. stdout, verbosity is set to 0 (i.e. quiet).
        -r | --restore-backup <file>
                     restore a .tar.gz created with sysupgrade -b
                     then exit. Does not flash an image. If file is '-',
                     the archive is read from stdin.
        -l | --list-backup
                     list the files that would be backed up when calling
                     sysupgrade -b. Does not create a backup file.

-n is kind of a weird flag. From the description is not entirely clear to me what it exactly does. Do other builds flash just fine, master and/or 19.07?

No luck with keeping the settings following a reboot either, I'm by no means an expert but it appears to be an issue with JFFS2.

Upon a new flash (or following "firstboot") the mounts are as follows:

root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 8.3M      8.3M         0 100% /rom
tmpfs                    59.6M    504.0K     59.1M   1% /tmp
tmpfs                    59.6M    112.0K     59.5M   0% /tmp/root
tmpfs                   512.0K         0    512.0K   0% /dev
/dev/mtdblock8            5.1M    296.0K      4.8M   6% /overlay
overlayfs:/overlay        5.1M    296.0K      4.8M   6% /

Following a reboot overlayfs gets mounted to tmpfs, as such:

root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 8.3M      8.3M         0 100% /rom
tmpfs                    59.6M    496.0K     59.1M   1% /tmp
tmpfs                    59.6M    116.0K     59.5M   0% /tmp/root
overlayfs:/tmp/root      59.6M    116.0K     59.5M   0% /
tmpfs                   512.0K         0    512.0K   0% /dev

I tried numerous flashing methods, including going back to stock and to openwrt from there (oddly enough going back to stock some previous stock settings such as SSID names had been retained).

I've been reading up but can't seem to find a definitive cause for this...

Could anyone more "enlightened" share their thoughts on this? :slight_smile:

1 Like

In case someone is interested about the dir-860l general's stability, this is a stock 19.07.1 installation that I am about to upgrade to 19.07.4:

root@OpenWrt:~# uptime
 08:56:47 up 200 days, 15:21,  load average: 0.04, 0.03, 0.00

I just happened to be catching up on this thread...

I have the same issue on ath79 and haven't found any mentions of it. On a freshly built image I see log entries saying it failed to mount /overlay and something about it using ramdisk instead (hence no configs are retained over a reboot).

Did you find anything since you wrote this?

@Bartvz you asked a question further back that indicates you might also have the issue, any idea where this was introduced? I haven't had time to work back and find the commit

I don't follow this thread that close as I don't have 860l anymore, however there is this in the 19.07.4 changelog:

Device support: images for some device became too big to support a persistent overlay, causing such devices to lose configuration after a reboot. If you experience this problem, please report the affected device in the forum and consider downgrading to OpenWrt 18.06 or using the Image Builder to pack a smaller custom image

1 Like

Thanks for the heads up, however I believe that 16Mb flash at this point in time should be sufficient, also it might be worth noting that dev/root has actually decreased from 8.8Mb in 12255 to 8.3 in the latest optimized build, whilst dev/mtdblock8 (overlays) has remained the same size - 5.1Mb.

Could it be a JFFS2 configuration issue? (its odd that on first boot overlays get mounted fine, but in subsequent boots it defaults to ramdisk)