<mangix>
what's the policy regarding kernel modules in packages?
<mangix>
I ask since they cannot simply be updated
<Tusker>
mangix: what do you mean ?
<Tusker>
KernelPackage probably has a depends on the kernel version that is compiled...
neelaksh has joined #openwrt-devel
<Tusker>
*sigh* I can't get my head around ubinized kernel partition + ubinized rootfs. I have tried to look at examples, but haven't found one that is appropriate. Most assume uImage for the kernel. The nand_upgrade_tar "$1" looks implemented, and expects the ubifs based kernel and ubifs based rootfs inside a sysupgrade.tar, but I don't see how to build such sysupgrade.tar :| Anyone have any pointers ?
danitool has quit [Ping timeout: 480 seconds]
nitroshift has joined #openwrt-devel
dorf has joined #openwrt-devel
neelaksh has quit [Quit: Page closed]
pkgadd has quit [Quit: leaving]
<mangix>
Tusker: yeah but it can't be updated
slh has quit [Remote host closed the connection]
<mangix>
because it depends on a specific kernel
<Tusker>
yes, it will need to be updated at the same time as the kernel
<mangix>
it probably makes sense to migrate these to base then
<mangix>
since base handles the kernel
<Tusker>
up to the repo maintainers where it should go I suppose
goliath has joined #openwrt-devel
<Tusker>
i think it'll be easier to create a combined mtdsplit ubi fs with the kernel inside
<mangix>
wonder whatever happened to the btrfs idea
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
goliath has quit [Quit: SIGSEGV]
<jschwart>
Tusker: hope you saw the e-mail, thanks again for the help, I expect we'll get this bit to work for all users of those fritzbox modes now!!
Tapper has quit [Ping timeout: 481 seconds]
slh has joined #openwrt-devel
slh64 has joined #openwrt-devel
pkgadd has joined #openwrt-devel
Tapper has joined #openwrt-devel
decke has joined #openwrt-devel
rmilecki has quit [Quit: Konversation terminated!]
<rsalvaterra>
mangix: The btrfs idea is interesting, but… I think lots of testers (myself included) were badly bitten by btrfs when it was prematurely promoted to experimental in the kernel, years ago. I've had enough of it. Looking forward to bcachefs.
goliath has joined #openwrt-devel
nlowe has joined #openwrt-devel
por has joined #openwrt-devel
<digitalcircuit>
Okay, the ipq806x CPU governor 1.4 GHz cache saga continues - apparently I just missed the crashes (infrequent/nondeterministic when triggered by SFTP) and OpenWRT "master" has them too since 1.4 GHz cache memory frequency was re-enabled. I think that at least helps narrow down what I need to test, but the "stress-ng" package has been broken in the "master" branch for a month or more by now so I need to get that fixed first.
<digitalcircuit>
Something about how the 1.4 GHz cache memory clock speed is handled is just not working for me. And I feel bad because I had given my test results for Linux kernel 5.4 to help get that merged...
Tapper has quit [Ping timeout: 482 seconds]
<digitalcircuit>
Admittedly by this point I'm kind of just wanting to see if I can disable the top frequency clock and just take the performance hit to have a router that doesn't crash during 7+ hour SFTP copies to an attached USB drive (25 MB chunks, Deja Dup/duplicity).
<digitalcircuit>
(Ideally a runtime parameter so I could stay on the official builds and just add another script/service that runs on boot.)
* digitalcircuit
will revisit this with a clearer, cooler head soon enough.
<Tusker>
jschwart: I saw your email, thanks, let me know if you need me to look at any other mtd dump
<nlowe>
digitalcircuit I haven't seen have any stability issues on my test R7800 under max possible wifi channel load, saturated 20 MHz (2.4 GHz) and saturated 80 MHz (5 GHz) loaded via two STA using iperf to an iperf server
<nlowe>
It may not be a representative test to a CPU load test you are exercising
<mangix>
rsalvaterra: bcachefs will probably take a while to be stable too
<nlowe>
Good luck finding anything!
<rsalvaterra>
mangix: Sure, but I'm not seeing it having the fundamental issues btrfs had from the beginning.
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
rmilecki has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
nitroshift has joined #openwrt-devel
rejoicetreat has joined #openwrt-devel
nlowe has quit [Read error: Connection reset by peer]
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
<por>
with 21.02.0.-rc3 (on ipq4040 fb4040) when having a switch_vlan (swconfig, not DSA) that serves as a port of a device of type bridge, what does setting vlan_filtering actually change ?
<jschwart>
Tusker: alright thanks! this other person might upload their mtd2 too, I suppose it'll be a matter of figuring out the right spot with those bytes you already mentioned
<por>
with 21.02.0.-rc3 (on ipq4040 fb4040, swconfig, not DSA) when having a switch_vlan that serves as a port of a device of type bridge, what does setting vlan_filtering actually do ?
rejoicetreat_ has joined #openwrt-devel
glitzydeletion__ has joined #openwrt-devel
decke has quit [Quit: Leaving.]
rejoicetreat has quit [Ping timeout: 480 seconds]
dorf has quit [Remote host closed the connection]
rejoicetreat_ has quit [Ping timeout: 480 seconds]
dorf has joined #openwrt-devel
Tapper has quit [Remote host closed the connection]
<rsalvaterra>
rmilecki: I have no idea if it fixes your issues, but maybe worth a shot, yes.
<rmilecki>
rsalvaterra: sounds like possibly related to my bitrate going down randomly
<rmilecki>
so worth a try for sure
<xback>
blogic_: No, there is no way to see the revision
<xback>
MikroTik tends to alter hw layout without any change in a (for us) readable value
<silver>
who knows a translator?
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
Rentong has quit [Remote host closed the connection]
minimal has joined #openwrt-devel
<xback>
_lore_: ping
<xback>
_lore_: i'm looking at the dynack issues as reported on upstream wireless ML
<xback>
I can simulate the issue, but it looks obvious
<xback>
The reporters use IBSS, so they start of with 600 (HT20) or 300 (HT40). when the connection was already linked before, it will stay at MAX_VAL for the current width
<xback>
when the link is made afterwards. I see that dynack calculates the ACK_TO which is then averaged down. so only a small step down
<xback>
This specific case was tested mid-2019 when we tested the new code, and it was working fine back then.
<xback>
So for IBSS, are AUTH frames the only method of use for ack_to calculation?
aleksander has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
Tusker has quit [Quit: Time wasted on IRC: 14 hours 53 minutes 15 seconds]
aleksander has joined #openwrt-devel
aleksander0m has joined #openwrt-devel
aleksander has quit [Ping timeout: 480 seconds]
<_lore_>
xback: ack, right..is he using ibss?
<_lore_>
I did not noticed
<_lore_>
if so yes, we need to enable wpa_supplicant
aleksander0m has quit [Ping timeout: 480 seconds]
aleksander has joined #openwrt-devel
<xback>
_lore_: I'm testing here with wpa_supplicant and it takes forever
<xback>
just getting the logs right now
<_lore_>
xback: I did not get if it is working or not with wpa_supplicant
<xback>
_lore_: the issue appears to be present both with wpa_supplicant and without
<xback>
you will notice dynack gets enabled. then it takes forever to very slowly get ack_to lower and lower towards the optimal value (which is 28 when using static)
<xback>
this is using wpa_supp
<xback>
Very strange .. I didn't encounter this during our review back in 2019
<xback>
then it synced pretty quickly and got a lot of samples :s
<_lore_>
are you testing @ 10MHz?
<xback>
this is using basic HT20
<xback>
I would focus on getting this one working first
<xback>
afterwards we could check HT40 .. HT5 and HT10
<_lore_>
ah ok
<_lore_>
strange, I am pretty sure it was working
<xback>
me too :s
<_lore_>
maybe it has been break in the middle
<xback>
this is also tested on 19.07 branch, so kernel 4.14 with mac80211 based on 4.19.x
<xback>
19.07 was also used back in 2019 to test the improvements we did
<_lore_>
ack
<_lore_>
is it hard to perform a git bisect?
<xback>
yes :-)
<_lore_>
:(
<_lore_>
ok I will take a look to the logs
<xback>
I could try a few older builds. but it will be annoying to test a huge numbers of build
<_lore_>
sure
<_lore_>
I understand
<xback>
Now testing on a build from 4Nov 2019
<_lore_>
xback: for some reason we do not run ath_dynack_sample_tx_ts(), just few times
<_lore_>
can you please check why?
<xback>
yes. checking
<_lore_>
thx
<xback>
_lore_: I think I found an issue in the testing method
<xback>
re-testing now
<_lore_>
what do you mean?
<xback>
the boards also sustained a wired OLSR link. not only over wifi
<xback>
so all iperf traffic travelled accross wired
<_lore_>
but we have a lot of acks
<_lore_>
how is it possible/
<xback>
yeah .. that was the issue
<_lore_>
?
<xback>
not ack_to estimation is nearly instant
<xback>
now*
<_lore_>
cool
<xback>
So I guess the upstream report is lacking usage of wpa_supplicant?
<xback>
especially for IBSS
<_lore_>
I think the reported issue is only @ 10MHz
<_lore_>
and @ 5MHz
<xback>
Will test that now
<_lore_>
ack, thx
<_lore_>
the issue for 5MHz and 10MHz seems the reported values are very high
<_lore_>
at least according to the report
<xback>
just tested using fixed distance:
<xback>
HT20 - Distance 1m: Ack_to 28
<xback>
10 - Distance 1m: Ack_to 64
<xback>
5 - Distance 1m: Ack_to 120
<xback>
now trying dynack with debug prints
<xback>
fresh reboot. setting 10MHz and dynack on, then interface UP and starting wpa_supp
<xback>
blogic_: One of my boards is showing your exact ethernet issue
Rentong has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
_lore_ has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
nbd_ is now known as nbd
<_lore_>
xback: sorry I was away
<_lore_>
is it working in your tests?
Rentong has joined #openwrt-devel
Acinonyx has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
Acinonyx_ has quit [Ping timeout: 480 seconds]
<xback>
_lore_: yes
<_lore_>
ok
<xback>
but
<_lore_>
5GHz or 2.4GHz?
<xback>
it's not possible to alter chanbw on the fly
<_lore_>
what do you mean?
<xback>
for that. dynack should reset when that debugfs entry is issued
<xback>
it's possible to alter channel bandwidth to 5 or 10MHz using echo 5 > /sys/kernel/debug/ieee80211/phy0/ath9k/chanbw
<xback>
when this one gets invoked, it should check that:
<xback>
- only allowed to alter when current bw is 20MHz or less
<xback>
- dynack should reset here
<xback>
if these 2 are met, it should work on the fly
<xback>
the reporter also notices this that it doesnt work on the fly. and indeed, it doesnt
<xback>
also. the reporter shows in measurements that ack_to is 56 or so for 20, 10 and 5
<xback>
this is really wrong somewhere
<xback>
I couldn't simulate that
philipp64 has joined #openwrt-devel
Rentong has joined #openwrt-devel
minimal has quit []
<por>
quit
por has quit []
Rentong has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
Rentong has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
dorf has quit [Remote host closed the connection]
rmilecki has quit [Ping timeout: 480 seconds]
dorf has joined #openwrt-devel
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
rmilecki has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
wvdakker has joined #openwrt-devel
danitool has quit [Read error: Connection reset by peer]
danitool has joined #openwrt-devel
Luke-Jr has quit [Ping timeout: 480 seconds]
aleksander has quit [Quit: Leaving]
slh has quit [Quit: Lost terminal]
slh64 has quit [Quit: gone]
dorf has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
dorf has joined #openwrt-devel
slh has joined #openwrt-devel
slh64 has joined #openwrt-devel
fda has joined #openwrt-devel
Luke-Jr has joined #openwrt-devel
wvdakker has quit [Read error: No route to host]
shibboleth has joined #openwrt-devel
bluew has joined #openwrt-devel
<nick[m]12>
blocktrron: do you know if hw-watchdog ist working for fritz!box 7530?
goliath has joined #openwrt-devel
dedeckeh has quit [Remote host closed the connection]
<blocktrron>
nick[m]12: never tested it personally
<digitalcircuit>
nlowe (who is no longer here?), noted! And I haven't had any issues with iperf either. I suspect it's something about OpenSSH transfers that might be hitting CPU/cache utilization differently than iperf (due to encryption?), and Deja Dup/duplicity uploading in 25 MB chunks means it's probably exercising different CPU frequency states. I'd be curious if anyone else with a USB drive connected to an ipq806x router has issues.
greearb_ has quit [Read error: Connection reset by peer]
greearb_ has joined #openwrt-devel
<nick[m]12>
blocktrron: ah okay, thanks. I can trigger it manually disabling procd wathcdog. is there some way to test this procd watchdog stuff?
dorf has quit [Remote host closed the connection]
Luke-Jr has quit [Read error: Connection reset by peer]
<fda>
nick[m]12: do you run openwrt 21+ on 7530? im trying with 1200, but only older bulds with Openwrt 19 are booting
<nick[m]12>
fda: yep. running trunk and 21.02
glitzydeletion__ has quit [Ping timeout: 483 seconds]
<fda>
thx! so its something with 1200 only
<fda>
maybe while adding 7530 support..
ecloud has quit [Ping timeout: 480 seconds]
dorf has joined #openwrt-devel
ecloud has joined #openwrt-devel
netprince_ has quit [Remote host closed the connection]
Luke-Jr has joined #openwrt-devel
<blocktrron>
nick[m]12: which component do you want to test?
<blocktrron>
If you want to ferify functionality of the HW watchdog, look into the kernel watchdog api (/dev/watchdog)
shibboleth has quit [Quit: shibboleth]
<nick[m]12>
blocktrron: sometimes this fritzboxes get in state in which they are not reachable anymore, so network seems broken. howeer also other stuff could be broken.
<nick[m]12>
I thought hw watchdog should fire
<nick[m]12>
and reset the device
<blocktrron>
as long as the userspace signals to the kernel a good state, the watchdog won't reset the box
lucenera has quit [Quit: Ping timeout (120 seconds)]
lucenera has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
myon98 has quit [Ping timeout: 480 seconds]
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
nlowe has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
Tusker has joined #openwrt-devel
swalker has quit [Remote host closed the connection]