Build for Netgear R7800

Huliz808 · 2022-08-02T05:22:11.256Z

Ok thanks for the info. It makes more sense now. I’ve set it to fq_codel and simple.qos. I put upload to 8000. I got A+ For bufferbloat test.

zabolots · 2022-08-04T13:55:57.709Z

It's always surprised me that "yes, the huge performance drop from stock firmware is normal" and we all accept it.

When I first got my R7800 I only ran stock FW long enough to flash DD-WRT so I never even tried it until recently. My needs are pretty basic so I'm going to stick with it for now.

IMO, the performance hit really argues for sticking with stock FW unless there's something you absolutely need that is only offered in 3rd party FW.

Of course the lack of frequent updates opens the door to potential security issues down the line (though some may eventually be patched by a stock FW update), but it's a choice between potential security issues vs guaranteed performance hit.

mroek · 2022-08-05T06:46:24.770Z

I purchased a spare R7800 to experiment with in preparation for making the big jump from LEDE 17 to OpenWrt 22.03 on my main unit, and that includes trying different builds. Yesterday I tried flashing Kong's
22.03 build, which is pretty large and contains a lot of things I don't really need, so I pretty quickly flashed back to this build.

However I've come across something peculiar, and that is that after flashing Kong's build, there are some texts in Luci that seems to be leftover from that build no matter what I flash to, and I can't fathom why that would happen. For example, in the top menu bar (using Bootstrap theme), the topmost item under "Status", should normally be called "Overview". However, now it says "Visão Geral", no matter which build I am flashing. And also, under software installation, if I choose a package to install, in the info box it says "Cancelar" instead of "Cancel". The install button is normal.

I've obviously flashed without keeping settings, and I have also tried soft reset from the shell. I have not tried a TFTP flash of a factory image yet, as I'd like to understand how this could happen with sysupgrades.

slh · 2022-08-05T06:52:55.397Z

If flashing succeeded, both sysupgrade -n or firstboot would do the job. The only other potential interference might actually be client side, namely your browser interfering (stale cache, cookies, site data, redirects) - clearing the browser cache and/ or using incognito mode might sort that.

mroek · 2022-08-05T07:58:03.293Z

Thanks! You're right. It is something with the browser cache. I'm using Firefox, and apparently I can't selectively clear the cache for individual sites, so I'll have to nuke it all, unfortunately.

perceival · 2022-08-11T07:58:14.573Z

Not sure if that is my specific setup but since around March build roaming between access points is failing. Especially roaming with Android devices causes session to stall.
Very quick investigation suggests wpad (or one of the libraries it is dependent upon) is to blame.

Ansuel · 2022-08-21T18:20:14.146Z

@hnyman do you have by chance an r7800 with openwrt-22.03? Need to check something...
An user reported empty

cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies

Thing is that trans table is OK so it's strange that the cpufreq driver doesn't report freq but actually scale the cpu... Can you run the command and give me the output?

hnyman · 2022-08-21T18:40:25.139Z

Well, you are 45 minutes late
I just flashed from 22.03 to master.

But I can re-flash a new 22.03 build in a while.

mroek · 2022-08-21T18:42:40.703Z

I'm not hnyman, but I do have a spare R7800 that is just doing nothing, and it is running 22.03 (my own build, but heavily based on @hnyman's), and I get this:

root@OpenWrt:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
cat: can't open '/sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies': No such file or directory

Listing that directory gives this:

root@OpenWrt:/sys/devices/system/cpu/cpufreq/policy0# ls -l
-r--r--r--    1 root     root          4096 Aug 21 18:24 affected_cpus
-r--------    1 root     root          4096 Aug 21 18:24 cpuinfo_cur_freq
-r--r--r--    1 root     root          4096 Aug 21 18:24 cpuinfo_max_freq
-r--r--r--    1 root     root          4096 Aug 21 18:24 cpuinfo_min_freq
-r--r--r--    1 root     root          4096 Aug 21 18:24 cpuinfo_transition_latency
-r--r--r--    1 root     root          4096 Aug 21 18:24 related_cpus
-r--r--r--    1 root     root          4096 Aug 21 18:24 scaling_available_governors
-r--r--r--    1 root     root          4096 Aug 20 11:55 scaling_cur_freq
-r--r--r--    1 root     root          4096 Aug 21 18:24 scaling_driver
-rw-r--r--    1 root     root          4096 Aug 20 11:55 scaling_governor
-rw-r--r--    1 root     root          4096 Aug 21 18:24 scaling_max_freq
-rw-r--r--    1 root     root          4096 Aug 20 11:55 scaling_min_freq
-rw-r--r--    1 root     root          4096 Aug 21 18:24 scaling_setspeed
drwxr-xr-x    2 root     root             0 Aug 20 11:55 stats

Ansuel · 2022-08-21T18:45:00.857Z

How is possible that on 5.15 I have that but on 5.10 it's not present... A regression in 5.10 kernel o.o?

hnyman · 2022-08-21T18:46:30.890Z

Ansuel:

An user reported empty

cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies

Well,
I can actually report that empty in up-to-date current master...

 -----------------------------------------------------
 OpenWrt SNAPSHOT, r20374-a434795809
 -----------------------------------------------------
root@router1:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
cat: can't open '/sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies': No such file or directory

root@router1:~# ls /sys/devices/system/cpu/cpufreq/policy0/
affected_cpus                cpuinfo_transition_latency   scaling_driver               scaling_setspeed
cpuinfo_cur_freq             related_cpus                 scaling_governor             stats
cpuinfo_max_freq             scaling_available_governors  scaling_max_freq
cpuinfo_min_freq             scaling_cur_freq             scaling_min_freq

root@router1:~# cat /sys/devices/system/cpu/cpufreq/policy0/*
0
600000
1725000
384000
100000
0
ondemand performance schedutil
600000
krait-cpufreq
ondemand
1725000
600000
<unsupported>
cat: read error: Is a directory

root@router1:~# uname -a
Linux router1 5.10.136 #0 SMP Sun Aug 21 17:16:45 2022 armv7l GNU/Linux

But there has been scaling activity, still. Graph contains 5 min of 22.03 and then master:

image1725×538 278 KB

Ansuel · 2022-08-21T18:48:43.576Z

@mroek can you give output of uname -a ?

Ansuel · 2022-08-21T18:51:51.178Z

hnyman:

But there has been scaling activity, still. Graph contains 5 min of 22.03 and then master:

yep seems just a regression in sysfs not giving the right data... internally cpufreq and the driver works correctly... wonder if in backporting fixes something broke and nobody notice? (or the krait cpufreq is lacking something needed for scaling_available_frequency)

on 5.15 i have this

root@Ansuel-Router:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_availa
ble_frequencies
384000 600000 800000 1000000 1400000 1725000

hnyman · 2022-08-21T18:55:02.282Z

Ansuel:

seems just a regression in sysfs not giving the right data
...
wonder if in backporting fixes something broke and nobody notice? (or the krait cpufreq is lacking something needed for scaling_available_frequency)

Likely we need to look into the upstream stable kernel changelog regarding cpufreq.

(I have a bi-monthly archive of old builds, so I could try to triangulate the regression point to some extent)

Ansuel · 2022-08-21T18:56:00.190Z

hnyman:

(I have a bi-monthly archive of old builds, so I could try to triangulate the regression point to some extent)

i would ask you to use a a very old 5.10 kernel to check if the sysfs entry is actually there and working

hnyman · 2022-08-21T19:01:38.545Z

Ansuel:

i would ask you to use a a very old 5.10 kernel

Looks like really old. Missing already at the end of February...

 OpenWrt SNAPSHOT, r19009-58212a6194
 -----------------------------------------------------
root@router1:~# uname -a
Linux router1 5.10.100 #0 SMP Mon Feb 28 17:36:53 2022 armv7l GNU/Linux
root@router1:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
cat: can't open '/sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies': No such file or directory

and as of 2021-12-28:

 OpenWrt SNAPSHOT, r18437-92820cc5b9
 -----------------------------------------------------
root@router1:~# uname -a
Linux router1 5.10.88 #0 SMP Tue Dec 28 08:09:44 2021 armv7l GNU/Linux
root@router1:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_fr
equencies
cat: can't open '/sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequ                                       encies': No such file or directory
root@router1:~# ls /sys/devices/system/cpu/cpufreq/policy0/
affected_cpus                cpuinfo_transition_latency   scaling_driver               scaling_setspeed
cpuinfo_cur_freq             related_cpus                 scaling_governor             stats
cpuinfo_max_freq             scaling_available_governors  scaling_max_freq
cpuinfo_min_freq             scaling_cur_freq             scaling_min_freq

Ps. but scaling works...

Ansuel · 2022-08-21T19:09:34.223Z

I now have some doubt it was present in 5.10? But it must be...

Ok I just checked and It seems a quick fix... the krait cpufreq lacks of the required attr... the sysfs entry is not something standard generic to cpufreq but it's provided by cpufreq drivers.

So I have to adds the missing attr Will push a fix ASAP

hnyman · 2022-08-21T19:37:41.559Z

The values have definitely been there earlier, but may have been dropped out when you introduced krait-cpufreq in 2021.

But I wonder why it has worked in 5.15.

Ansuel · 2022-08-21T19:49:43.176Z

Dropped the driver for a different solution so I'm using cpufreq-dt that has the entry.

The entry was present before as we didn't used the dedicated driver but we were patching cpufreq-dt

mroek · 2022-08-21T21:19:07.468Z

Sorry I had to do something else, so I didn't see the request. I guess you already have what you need, but anyways, here's the output on mine:

root@OpenWrt:/sys/devices/system/cpu/cpufreq/policy0# uname -a
Linux OpenWrt 5.10.136 #0 SMP Fri Aug 19 12:44:44 2022 armv7l GNU/Linux