<schmars[m]>
nbd: btw what do you think of lowering the number of message retries from 3 to 1? would lower the time to graceful reset from 80s to 40s (i'm assuming timeouts at this level are always a failure indication)
<schmars[m]>
no crash yet, unlucky
skynet2 has quit []
<damo22>
with the upcoming PR for my new port, is there any documentation i could write for the device? I added some info to the commit message but should i write a wiki page? if so is there a template i could use?
hanetzer1 has joined #openwrt-devel
<schmars[m]>
yes there are wiki templates for the device page and hwdata, and if you can snap some pictures of the insides, it'll be perfect :)
<schmars[m]>
i got my wiki account here in the channel but i forgot who did it
minimal has quit [Quit: Leaving]
hanetzer has quit [Ping timeout: 480 seconds]
<efahl>
PaulFertser does the wiki stuff, if I remember right
<damo22>
the github PR has a high res photo already, i could use that :)
<damo22>
PaulFertser: i tried logging into the wiki for the first time using my github account "zamaudio" but it says my OAuth is not enabled for github access against my email address
<Mangix>
alright
<Mangix>
where is this shared-workdir coming from?
<PaulFertser>
damo22: hey, I can try to change that manually, query me
EqUaTe_ has joined #openwrt-devel
robimarko has joined #openwrt-devel
EqUaTe- has joined #openwrt-devel
EqUaTe_ has quit [Read error: Connection reset by peer]
Daanct12 has joined #openwrt-devel
<f00b4r0>
robimarko: lol you're too fast, I was moving my "reviewed-by" into the PR review instead of comment but you already merged it ;)
Daanct12 has quit []
<robimarko>
f00b4r0: I am subscribed so as soon as I saw your reviewed-by that was my signal
<f00b4r0>
;)
<\x>
i wonder if 802.11s / mesh will also get akm24 treatment
<\x>
maybe on wifi 7 mesh?
hanetzer has joined #openwrt-devel
<f00b4r0>
speaking of, what happened with the micro peering patch? This looked very clever
hanetzer1 has quit [Ping timeout: 480 seconds]
EqUaTe- has quit [Quit: Someone should have labelled the future as 'some assembly required'!]
Daanct12 has joined #openwrt-devel
<f00b4r0>
the gl.inet openwrt web interface looks pretty damn nice
Strykar has quit [Quit: /quit]
Strykar has joined #openwrt-devel
asmodehn_ has joined #openwrt-devel
asmodehn has quit [Ping timeout: 480 seconds]
<schmars[m]>
nbd: we have a crash! and we have clients reconnecting right after the reset!!
<schmars[m]>
oh man this thing has been a rollercoast of want-crash / not-want-crash emotions! :-)
<schmars[m]>
f00b4r0 ^ :-)
<f00b4r0>
heh
<f00b4r0>
the bad news is that this means the issue isn't linked to having two separate pci buses involved
<schmars[m]>
that was expect though,w asn it?
<schmars[m]>
expected
n3ph has joined #openwrt-devel
<f00b4r0>
i'm not sure, I don't remember clearly what nbd said but ISTR his guess had to do with how mt7915 is wired to mt7621
<schmars[m]>
the recovery failing had to with that
<f00b4r0>
ha ok, so we're no closer to a solution then :)
<schmars[m]>
lowered the severity by at least 2 points though
<schmars[m]>
i dont need to babysit or hourly-reboot these hosts anymore which is a huge win
<f00b4r0>
yeah but clients still get kicked and performance took a hit, so far from ideal still
<schmars[m]>
yeah definitely not ideal. the message timeouts can potentially also be reduced, so the time-to-reset would be lowered from 80s to 40s
<f00b4r0>
even 40s is a problem tbh. My most problematic use case is point of sale
<schmars[m]>
ah right. yeeeah
<f00b4r0>
also the workaround can't be merged as is either, so there's that too :)
<schmars[m]>
i'll wait for another crash to see if it also recovers repeatedly
<schmars[m]>
next going to find out why ethernet on mt7621 resets all the time :D
<nbd>
good to hear that recovery is working well now. i'll commit the change then
<schmars[m]>
\o/ thanks for keeping coming up with new ideas man
<nbd>
regarding the recovery time - there are ways to get it down to even less than 40s
<schmars[m]>
nice that's good to hear
<nbd>
just have to change the code to make the timeout more command specific
skynet2 has joined #openwrt-devel
caskd has quit [Remote host closed the connection]
caskd has joined #openwrt-devel
nixuser has joined #openwrt-devel
Daanct12 has quit [Quit: WeeChat 4.4.2]
caskd has quit [Ping timeout: 480 seconds]
caskd has joined #openwrt-devel
minimal has joined #openwrt-devel
n3ph has quit [Ping timeout: 480 seconds]
goliath has quit [Quit: SIGSEGV]
Stat_headcrabbed has joined #openwrt-devel
<sandberm>
Does anyone know if buildbot and imagebuilder share the same preprocessor flags? That is, if I do 'ifndef IB ...' in an image makefile buildbot is not affected?
<sandberm>
I have a problem with a factory image relying on initramfs images and they were removed from imagebuilder in a semi-recent patch. Needless to say, imagebuilder cannot build the factory image. I am thinking of flagging out the factory image from IB builds and a user could use release images produced by buildbots.
<sandberm>
Ansuel: maybe you know? :)
<stintel>
anyone know if LACP on realtek target switchports (DSA) is supposed to work?
<stintel>
I used the netifd bonding proto, not the broken proto-bonding package in the packages feed
<stintel>
LACP is negotiated
<stintel>
tcpdump on the realtek device shows traffic going out on bond0 but not on lan7 or lan8
danitool has joined #openwrt-devel
goliath has joined #openwrt-devel
<dwfreed>
stintel: looking at latest master, I think there's a bug in the rtl dsa code that causes it to not support any LAG offloading (or perhaps this is intentional because offloading doesn't actually work in the chip, even though all the code is there to set it up), so all LAG handling is done in the CPU
<stintel>
dwfreed: I added pr_info and the offloading code is not hit at all
<stintel>
[16610.925777] rtl83xx_lag_add: Added port 14 to LAG 0. Members now 0000000000004000.
<stintel>
[16611.379322] rtl83xx_lag_add: Added port 15 to LAG 0. Members now 000000000000c000.
<stintel>
this is what I see
<stintel>
so I'm hitting some _lag_ functions in target/linux/realtek/files-6.6/drivers/net/dsa/rtl83xx/common.c
<stintel>
but the code in target/linux/realtek/files-6.6/drivers/net/dsa/rtl83xx/dsa.c is not hit at all, afaict
<dwfreed>
wild, because the only thing I can see that calls that function is the rtl83xx_port_lag_add function in dsa.c
<stintel>
no
<stintel>
it's a function pointer
<stintel>
actually scratch that
<stintel>
rtl83xx_lag_add is called from rtl83xx_handle_changeupper
<stintel>
in common.c
<dwfreed>
oh, so it is
<dwfreed>
damn github and their "show 1 more matches"
<stintel>
shithub
<stintel>
ah fuck it
<stintel>
I'll just pull a few more 20m cables
<stintel>
and give up on the thought of having OpenWrt switches that can actually do anything useful
<stintel>
I guess there's a reason why TIP abandoned OpenWrt in favor of sonic for switches
<robimarko>
Its cheaper to do, there is a bunch of vendors supporting SONIC
<robimarko>
And only 1 (Mellanox/Nvidia) with a proper switchdev driver
<dwfreed>
stintel: if you want to experiment, you could try setting priv->ds->num_lag_ids to priv->n_lags's value in the rtl83xx_sw_probe function in common.c
<dwfreed>
at the pr_debug("Chip version [...]" line
<stintel>
dwfreed: something tells me you've looked at this code before :P
<KanjiMonster>
robimarko: it's a shame we really haven't seen any sparx 5 switches on the market
<stintel>
ok so the id is negative that's why rtl83xx_lag_can_offload returns false and that's why I don't see any of the pr_info I added in rtl83xx_port_lag_join
<stintel>
ugh, macros
<KanjiMonster>
hrm, rtl83xx_port_lag_change() is unimplemented
<stintel>
now it looks like returning from rtl83xx_port_lag_join because port >= priv->cpu_port
<KanjiMonster>
lag_primary is completely useless; primary only makes sense in the context of active backup, and the dsa driver shouldn't care about it, and instead should just implement lag_change() to selectively enable/disable tx on lag members
n3ph has joined #openwrt-devel
<stintel>
KanjiMonster: I'm not even hitting the code that checks lag_primary
<KanjiMonster>
stintel: I have no idea how the realtek switches work, but there's also lag_fdb_{add,del} dsa ops, which might be required for learning to work on lags (depends on if the switch's fdb supports lag entries)
<stintel>
pr_info("port_lag_join: group %d, port %d\n",i, port);
<stintel>
I never saw this
<stintel>
wait
<stintel>
I did
<stintel>
yeah this context switching between coding in rust, maintaining a Microsoft 365 environment and debugging stuff in OpenWrt is not going very well
<robimarko>
KanjiMonster: Yeah, I like SparX-V
<robimarko>
Especially the fact that register space is public
<robimarko>
And there is literaly no FW needed
<KanjiMonster>
exactly, I'd love to get my hands on one; but apart from one $400 tp-link switch from china I'm not aware of any models on the market with it
<dwfreed>
stintel: not in the slightest, I just spent a lot of time looking at this code after you said something but before I spoke up
<dwfreed>
btw, errno 19 is ENODEV, which is the return from dsa_lag_id when the lag device is not registered with dsa, which happens when num_lag_ids is 0
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
Svanto24 has joined #openwrt-devel
<nbd>
f00b4r0, schmars[m]: here's a patch for testing that should significantly improve recovery time: https://nbd.name/p/99f4829c
<nbd>
the pcie link2 disable is in mt76.git now
<nbd>
with that change, recovery is down to ~10 sec including firmware reload/restart time
<nbd>
~4 seconds of those is mcu timeout waiting
<Mangix>
so this is hillarious.
<Mangix>
in the transition to OF, a bunch of ath9k patches in mac80211 became noop
Svanto24 has quit [Ping timeout: 480 seconds]
Svanto24 has joined #openwrt-devel
<hauke>
damo22: Please update the commit and force push if the formality check failed
<mrnuke>
What is this nonsense? It's hard enough to convince them to try OpenWRT, then they go to the wiki to get some info and find that. But it's okay, because the page warns the documentation is unreliable! Come on guys! Let's not do this
<sur5r>
Seems like "thomascrisan" begs to have their wiki account removed...
<dwfreed>
PaulFertser: ^^^
<efahl>
I think the 80211s page kerfuffle has already been resolved. thess stepped in and PMed the perpertrator and they have not been seen on the forum since the day before that final edit.
sorinello has quit [Ping timeout: 480 seconds]
<dwfreed>
so it should be reverted back to sanity, and not that warning at the top of the page
<PaulFertser>
dwfreed: well Thomas is a real person, not LLM.
<dwfreed>
sure, but one should not be making wiki edits using text generated by an LLM
<dwfreed>
whether human or otherwise
<PaulFertser>
One shouldn't write misinformation no matter how it was prepared.
<dwfreed>
also valid
<PaulFertser>
LLM is dangerous in that regard because it makes it easy to prepare a ton of bullshit in no time. And there's no sense arguing with it because it can't provide rationale or be convinced about anything at all.
<PaulFertser>
While Thomas as a living person can be talked to and accept reasoning if at all needed.
<PaulFertser>
My suggestion would be for someone who has indeed an authority in the project and solid understanding of 802.11s and who is not BlueWaveNet (with whom there's a personal story of apparently misunderstanding/miscommunication) to take an opportunity go over the wiki page and improve it.
<PaulFertser>
Also a new rule for the wiki can be added that LLM generated content is absolutely discouraged with an explanation that it's much better to make (and show!) your own mistakes than a nice plausibly looking hallucinations from an LLM.
<PaulFertser>
But since it'd be a new rule it couldn't be retroactively applied to criticise what Thomas did.
n3ph has quit [Ping timeout: 480 seconds]
<efahl>
<PaulFertser>
To sum up: my own impression is that there's a misunderstanding. I talked to Thomas and he is not a crazy or ill-intending person. I would be happy to see the conflict resolved, the wiki page improved, and the rules improved.
<PaulFertser>
Also I would like to highlight I'm not any authority in OpenWrt, I just volunteer to help with the wiki registrations.
<mrnuke>
PaulFertser: I have some experience setting up 802.11s with batman-adv, but I'm not sure if that would be too useful for that respective page
Svanto24 has joined #openwrt-devel
Svanto24 has quit [Read error: Connection reset by peer]
Svanto24 has joined #openwrt-devel
<schmars[m]>
nbd: thanks i'll give it a try :) the other device also recovered successfully from its first crash, but it gave a kernel trace from __ieee80211_stop_tx_ba_session which i've never seen: https://gist.github.com/pktpls/049fd9ab3d4c8a959e4b453626e0b561 - not sure if that's just noise, clients did reconnect and traffic resumed
<f00b4r0>
PaulFertser: in the meantime the page should be reverted to whatever "last" version was correct. I agree with dwfreed that having this warning on top of the page as if it were acceptable reflects poorly on the project and makes little sense in the context of a versioned wiki
<Habbie>
fully agree but it's actually worse without the warning :)
<Habbie>
"as if it were acceptable" seems core to that indeed
Svanto24 has quit [Ping timeout: 480 seconds]
fakuivan has quit [Remote host closed the connection]
<damo22>
PaulFertser: can you please guide me on how to create a new wiki page for a new device? I know what to write in there but i cant seem to locate where to create the page