Rpi4 < $(community_build)

anon50098793 · November 27, 2021, 11:11am

best move is to make sure you are running absolute official (clarification: OpenWrt) firmware source (exclude any build related possibilities);

so;


cd /
wget http://rpi4.wulfy23.info/misc/lib-firmware-brcm-r18161_orig.tar.gz
rm /lib/firmware/brcm/*
tar -xzf lib-firmware-brcm-r18161_orig.tar.gz
reboot

create a new thread linking/including both your log/dmesg above and most importantly your /etc/config/wireless

there are many more skilled than I with wireless related stuff on the general forum threads...

the above said... r18161 is right on the border of alot of 'cutting edge' wireless related commits to master... and as a general rule... i'd recommend most people who wish to rely on wireless for these boards to run or at least compare operation with 21.02...

but my hunch is that is not the primary reason behind the current issues you are experiencing... a history about what you have recently done, whether or not it was ever working, whether you set the otp country etc. etc. all are important kinds of information when seeking support

(then again... just saw the QoS map line in the output so maybe it is master related... there are a few related posts on the general forum)

but you have the main bits we need already covered... your config, a log, and asking here about build related or version implications in this case will likely be 99% if the puzzle...

random observation from your support output...

this line here is anomolous... could be a false positive... but i've not seen this before...

lol... speak of the devil... i'm running the same build and you just directed me to another one i've not seen before on my system... (likely minor or a false positive or something... possibly from the 5.10 tailroom bug before the localfix triggers)

ethtool -S eth0 | grep -E '(errors:|drops:|pause:|col:|jabber:|cnt:|frags:|outrange:|unknown:)' | grep -v ': 0'
     mdf_err_cnt: 30

swanson · November 27, 2021, 11:44am

cd /
wget http://rpi4.wulfy23.info/misc/lib-firmware-brcm-r18161_orig.tar.gz
rm /lib/firmware/brcm/*
tar -xzf lib-firmware-brcm-r18161_orig.tar.gz
reboot

done and added dmesg to Rpi4 < $(community_build) - #1669 by swanson, anything else i can do?

anon50098793 · November 27, 2021, 11:48am

cheers... no, as suggested it's a matter of now seeking input on the general forum re:

your settings and/or r18161 specific things
or
downgrading to 21.02 to see how that goes... (note: if it's not working off the bat once settings are sorted... you can use the same firmware .tar / method on 21 to make sure you are working with official blobs...
(21.02 is a much more well known entity and much easier to say with certainty what will and will not work regarding settings)

general related note to everyone on this topic:

afaik master around r17700-800 was around the last time it was 'known good' (or at least comparable to 21.02 in it's operation) ...

swanson · November 27, 2021, 12:05pm

Well then I hope my topic will get some attention, mostly my previous topics (if I hadn't posted here where the boss will always replies and fixes everything x) hadnt got as much attention, anything I should do to change that?

anon50098793 · November 27, 2021, 12:17pm

dalai lama pictures?

(seriously tho'... good questions usually get good answers on this forum... i've learn't 90% of most I know here... so only one way we will find out)

swanson · November 27, 2021, 12:29pm

xDDDDDDDDDDDDDDDDD

neil1 · November 28, 2021, 3:47am

@anon50098793
I will be able restore all my settings on pi4 using this backup if I do a factory reset?

anon50098793 · November 28, 2021, 6:08am

if by reset you mean new fac.img to sdcard and by all settings you mean all common settings then probably ( 93% confidence )...

but there is a semi-large chance you'll end up with the same 'settings' that caused you to want to reset in the first place...?

so if it's for a newer card or something then sure...

malikshi · November 28, 2021, 2:35pm

Is it okay to ignore this errors

sysinfo-msgs 20211128-2128
[    2.873067] fsckparts bootpart:/dev/mmcblk0p1 [unclean-fsck-repairing]
[    3.585540] fsckparts bootpart:/dev/mmcblk0p1 [unclean-fsck-ok]
throttled=0x50000 [one-undervolt+throttle] #20211128-2128

Log from rpi-throttlewatch.sh while doing speedtest on smartphone

rpi-throttlewatch.sh
taskset-aarch64 -c 0,1,2,3 /bin/rpi-throttlewatch.sh -P -C 4
NPROC:4 RUNSSLBENCH:off NPROC_SSL:2
Time       Temp     CPU     Core         Health           Vcore
21:33:04  47.2'C  1500MHz  500MHz  01010000000000000000  0.8688V
21:33:07  46.7'C  1500MHz  500MHz  01010000000000000000  0.8688V
21:33:10  46.2'C  1500MHz  500MHz  01010000000000000000  0.8688V
21:33:13  47.7'C  1500MHz  500MHz  01010000000000000000  0.8688V
21:33:16  46.7'C   600MHz  200MHz  01010000000000000101  0.8688V
21:33:19  46.2'C  1500MHz  500MHz  01010000000000000000  0.8688V
21:33:22  46.7'C   600MHz  200MHz  01010000000000000101  0.8688V
21:33:25  47.2'C  1100MHz  500MHz  01010000000000000000  0.8688V
21:33:28  47.2'C   600MHz  200MHz  01010000000000000101  0.8688V
21:33:31  46.7'C   600MHz  200MHz  01010000000000000101  0.8688V
21:33:34  46.7'C   600MHz  200MHz  01010000000000000101  0.8688V
21:33:37  46.7'C  1500MHz  500MHz  01010000000000000000  0.8688V
21:33:40  48.2'C  1500MHz  500MHz  01010000000000000000  0.8688V
21:33:43  46.7'C  1500MHz  500MHz  01010000000000000000  0.8688V
21:33:46  47.2'C   600MHz  200MHz  01010000000000000101  0.8688V
21:33:49  47.7'C  1500MHz  500MHz  01010000000000000000  0.8688V
21:33:52  48.2'C  1500MHz  500MHz  01010000000000000000  0.8688V
21:33:55  47.7'C  1500MHz  500MHz  01010000000000000000  0.8688V
21:33:58  47.2'C  1500MHz  500MHz  01010000000000000000  0.8688V
21:34:01  47.2'C  1500MHz  500MHz  01010000000000000000  0.8688V
21:34:04  47.7'C  1500MHz  500MHz  01010000000000000000  0.8688V
21:34:07  47.7'C  1500MHz  500MHz  01010000000000000000  0.8688V
21:34:10  46.7'C  1500MHz  500MHz  01010000000000000000  0.8688V
21:34:13  46.7'C  1500MHz  500MHz  01010000000000000000  0.8688V
21:34:16  47.7'C  1500MHz  500MHz  01010000000000000000  0.8688V
21:34:19  46.7'C  1500MHz  500MHz  01010000000000000000  0.8688V
21:34:22  47.7'C  1500MHz  500MHz  01010000000000000000  0.8688V
21:34:25  47.2'C  1500MHz  500MHz  01010000000000000000  0.8688V
21:34:28  47.7'C  1500MHz  500MHz  01010000000000000000  0.8688V
21:34:31  46.2'C  1500MHz  500MHz  01010000000000000000  0.8688V

anon50098793 · November 28, 2021, 2:44pm

good question/s...

the fsck stuff usually happens on the odd occasion and it fixes itself... this is usually after power loss during the boot process... it is more uncommon for the boot partition (partition 1) to need to be repaired...

for the throttle watch results... yes... they do seem possibly something worth investigating....

(my rpi4 always triggered everyboot... due to really thin power wires... but it was/is never really a problem for normal operation in my case)

with yours... both the things combined may indicate substantial drain somewhere in the power system;

extra / (new)devices? / bad psu?

but if you see the fsck message regularly or with some sort relation to power loss (frequent) then something should probably be looked at...

here is a brief output from throttlewatch on my system showing undervolt was triggered but causing no/less issues than in your output

[root@dca632 /usbstick 48°]# rpi-throttlewatch.sh 
taskset-aarch64 -c 0,1,2,3 /bin/rpi-throttlewatch.sh -P -C 4
NPROC:4 RUNSSLBENCH:off NPROC_SSL:2
Time       Temp     CPU     Core         Health           Vcore
01:46:20  48.7'C  1500MHz  500MHz  01010000000000000000  0.8375V
01:46:23  48.2'C  1100MHz  366MHz  01010000000000000000  0.8375V
01:46:26  48.7'C  1100MHz  366MHz  01010000000000000000  0.8375V
01:46:29  47.7'C  1100MHz  366MHz  01010000000000000000  0.8375V
01:46:32  48.7'C  1100MHz  366MHz  01010000000000000000  0.8375V
01:46:35  48.2'C  1100MHz  366MHz  01010000000000000000  0.8375V
01:46:38  48.2'C  1100MHz  366MHz  01010000000000000000  0.8375V
01:46:41  47.7'C  1100MHz  366MHz  01010000000000000000  0.8375V
01:46:44  48.7'C  1500MHz  500MHz  01010000000000000000  0.8375V
01:46:47  47.7'C  1100MHz  366MHz  01010000000000000000  0.8375V
^X^C

(could also be caused/influenced-by config.txt overclock settings I suppose)

your welcome to add load... but the script itself generates load by default using openssl... (edit: that seems to be only when ran with the full parameters rpi-throttlewatch.sh -P -C 2)

ok when I run it with full parameters i'm getting it too... (undervolt)

[root@dca632 /usbstick 47°]# rpi-throttlewatch.sh -P -C 2
taskset-aarch64 -c 0,1,2,3 /bin/rpi-throttlewatch.sh -P -C 4
NPROC:4 RUNSSLBENCH:1 NPROC_SSL:2
starting opensslbench with 2 cores
Time       Temp     CPU     Core         Health           Vcore
02:00:09  48.7'C  1100MHz  366MHz  01010000000000000000  0.8375V
02:00:12  47.2'C   600MHz  200MHz  01010000000000000101  0.8375V
02:00:15  50.1'C   600MHz  200MHz  01010000000000000101  0.8375V
02:00:18  49.1'C   600MHz  200MHz  01010000000000000101  0.8375V
02:00:21  50.6'C  1500MHz  500MHz  01010000000000000000  0.8375V
02:00:24  49.6'C   600MHz  200MHz  01010000000000000101  0.8375V

so looks to me like some new issues(demand/power subsystem changes) with newer kernel etc. and maybe not your PSU after all...

I will need to look a bit deeper into this to see if/when this has changed and if I need to change something with scaling or similar or if it's just a transient OS bug/quirk...

thankyou for letting me know...

malikshi · November 28, 2021, 3:12pm

I will do test with original adapter rpi4 tomorrow

Well i bought mini ups as backup since it's often blank out in my area. I think the setup seem wrong output seller didn't have rpi4 or similar devices to test the electric output. It's been 2 month i used it and only having problem while upgrading openwrt version two times failed(firstboot).

The other one i saw something good in your commit
-12) sqm-autorate via config/sqm autorate='1' (for lte/variable-bw-links)
Is there any tips for the those update in openwrt 21.02? I'm using router 4G cat 19(lte) as internet

anon50098793 · November 28, 2021, 4:19pm

Glad you noticed that... it's kind of experimental but it will be in the
next 21.02.x build that I push...
(there is also a zip file that can be installed to test with)

A few more details here;

https://forum.openwrt.org/t/sqm-qos-for-dual-lte-wan-connections/112779/8?u=wulfy23

It's pretty much just the code from the guys mentioned in that thread at this stage

i can't really test it properly as I don't have LTE...

on my system it keeps SQM settings at the bare minimum
(I think it requires load to make it start working or something)

So likely won't be perfect right now... but in situations where
you really need SQM... and have LTE... it still may
offer benefits... ( sacrifice some 'learning/scaling' speed loss to have low latency in general )

I only have 3 new lines in my sqm section to make it work/enable it;

	option autorate '1'
	option autorate_min_dl_rate '10999'
	option autorate_min_ul_rate '2111'

where min rate should be the lowest value for the link...

malikshi · November 29, 2021, 1:40am

anon50098793:

I only have 3 new lines in my sqm section to make it work/enable it;
	option autorate '1'
	option autorate_min_dl_rate '10999'
	option autorate_min_ul_rate '2111'
where min rate should be the lowest value for the link

I did set it like this.

config queue 'eth1'
        option interface 'eth1'
        option qdisc 'cake'
        option debug_logging '0'
        option verbosity '5'
        option linklayer 'none'
        option enabled '1'
        option script 'ctinfo_4layercake_rpi4.qos'
        option download '49700'
        option upload '15950'
        option autorate '1'
        option autorate_min_dl_rate '29700'
        option autorate_min_ul_rate '5950'

i assumed if this working speed gonna over 29,7Mbps since my speed download 30-64Mbps up 18-25Mbps. i did a few speedtest and wavebloat for bufferbloat test but the speed not hit above min_dl_rate
bufferbloat

everytime changes in /etc/config/sqm need to stop/restart sqm-autorate-init.sh to take effect

anon50098793 · November 29, 2021, 1:43am

yeah... this is also what I found... apparently it does not work if there is no load...

yes it can be restarted from that command or just /etc/init.d/sqm restart should also restart it...

malikshi · November 29, 2021, 1:55am

here are the things after installing those sqm scripts. I got errors and some software not running at startup

anon50098793 · November 29, 2021, 1:58am

In this case you should probably try the original script... (I've not tested from luci so will look into this > actually it looks like it has some bugs so will have to temporarily remove it... the whole reason to create it was for multiple interfaces... but for a single interface the original script below should be fine)

You can comment out the lines you added to /etc/config/sqm, then rm /bin/sqm-autorate-init.sh then reboot

This is a link to the underlying code I've used;

https://github.com/moeller0/sqm-autorate/blob/main/sqm-autorate.sh

That script needs to be downloaded and edited then run...

This is the thread where it's being developed;

https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/108848?u=wulfy23

where you can give the guys feedback, ask about why it's keeping the rate low...

malikshi · November 29, 2021, 2:56am

yes for multiple WAN would be helpful.

I look up into it.

somehow speed can increase about 500Kbps-2Mbps above the minimum set.

jaromanda · November 29, 2021, 5:03am

I found AX88179 adapters to be absolute garbage

Lynx · November 29, 2021, 8:37am

I don't know how well @moeller0's fork works. I think he has been experimenting with various changes. Whatever change is of benefit will get pulled into the main code I am developing.

The code here:

Certainly works at the moment on my LTE connection but it is still experimental. The service file works to enable service but needs to be restarted with any SQM change. Perhaps a call to this service script should be placed inside the main SQM script so that when the SQM script is restarted the autorate service script is also restarted. Also take care to disable logging as otherwise one log line per tick. That said we'd love a day's worth of data output to the memory card on RPi to test over a day's usage.

The readme in the link above gives some help about how the script works.

The script is designed to stay at the minimum set download and upload on zero load. Because without load the capacity of the connection is unknown. When there is a load it then increases the bandwidth until any RTT spike is detected, at which point it eases back.

So the idea is that it recovers otherwise lost bandwidth associated with having to set a compromise bandwidth which won't even work all of the time.

So imagine orange load here. Starts at 0 but increases. It goes beyond what is available so the script knocks it back down.

Here is some real data:

And here:

anon50098793 · November 29, 2021, 8:42am

thanks for the info... I will definitely test both...

and suspected/read about this ramping up behavior on load only... (although couldn't see it happen with the first script on my connection will test yours to see if different and will retest the first script in it's vanilla form in case I messed something up)

hopefully after some feedback from those with LTE links will work again on the sqm restart lock up thing...