<Ansuel>
so the lpthread was the fix nice! Mangix wonder if you can send upstream and create a pr with the 2 commit and this new one... then i would ask the user that reported the error to test and add some tested by tag
<Ansuel>
what do you think?
<Mangix>
Upstream uses some weird bugzilla system. Not familiar with it
<Mangix>
Ansuel: I just noticed there's GCC8 in the tree...
<Mangix>
given that 22.03 was just released, I think it should be removed.
<nbd>
robimarko: actually, it looks like this patch won't affect ath11k after all
<nbd>
robimarko: since it doesn't implement the .sta_set_decap_offload driver op
<Ansuel>
isn't that a problem? considering ath11k have support for decap offload?
<Ansuel>
and is actually enabled by default
Tapper has quit [Ping timeout: 480 seconds]
<nbd>
maybe the firmware doesn't have a way to toggle it per station
<nbd>
i think it needs to be enabled via module parameter
<Ansuel>
nbd yes that's the case decap offload is enabled globally and can be toggled with module parameter on mtk you can disable decap offload per ap ?
<nbd>
with mtk, mac80211 tells the driver which stations to enable it on
<nbd>
in order to deal with corner cases
<nbd>
e.g. it's disabled when legacy crypto (WEP or TKIP) is used
<ynezz>
Ansuel: BTW kernel might still build, but image wont. For example, when kernel outgrows the size in the flash partition.
<Ansuel>
ynezz we should at least catch when kernel doesn't build at all. If a device doesn't have enough space for the kernel buildbot will skip that image right?
<Ansuel>
is it possible to build an image without installing the package? just to check kernel ?
<nbd>
Ansuel: last time i looked at making 4-addr encap/decap offload with a qca-forked ath11k, i gave up eventually
<nbd>
i think one of the first things i had to fix was receiving nullfunc packets as 802.11
<Ansuel>
nbd on codeaurora there are many patch about it.... in short it's a nightmare with the amount of changes required
<nbd>
because otherwise it didn't detect 4-addr clients
<nbd>
yeah
<nbd>
and it's not like qca cares about proper upstream development for it
<Ansuel>
nbd for some changes they care... now they are working on ath12k so it's not a priority anymore....
dangole has joined #openwrt-devel
<nbd>
well, they do care enough to have something where they can claim to have upstream support
<Ansuel>
but devs on codeaurora are well aware that the wlan-open patches are a big hack and that upstreaming them is a nightmare
<Ansuel>
even if they can self review their patch the have to at least reach an acceptable code quality
<nbd>
but not enough to get the upstream version in shape enough to be actually usable
<Ansuel>
one example is the decap offload patch itself... the patch is the same from ath10k and they just pushed that recently for ath11k... and want to know why?
<Ansuel>
cause wifi offload required that or it doesn't work at all
<Ansuel>
ahahhaha
<nbd>
my expectation is that they will repeat the pattern with ath12k
<nbd>
they will get it upstream as an early prototype
<nbd>
then they will build piles upon piles of hack patches on top of that
<nbd>
which they will regularly rebase on top of newer (but still obsolete) versions internally
<nbd>
and occasionally send one or two of those patches upstream
<nbd>
while the private development continues to diverge
<Ansuel>
nbd there are at least 3 patch with "refresh with new mac80211" where they fix compilation error
<Ansuel>
instead of ficing the patch itself they just make another patch fixing error
srslypascal is now known as Guest1614
srslypascal has joined #openwrt-devel
<ynezz>
Ansuel: buildbot is not going to skip that image, that failing target needs to be disabled manually, so it would result in a build failure
<Ansuel>
ynezz ok so we need to find a way to build the image without compiling each packet
<nbd>
it's the same with their SDK. after likely spending man-years of effort, they manage to rebase their linux 4.4 based sdk to 5.4, just in time for the kernel to be obsolete again :)
<ynezz>
Ansuel: I believe, that it should be somehow possible to run just the size check on the resulting kernel, but then final image might not fit in the rootfs space, due to bigger kernel modules
<nbd>
so that maybe in 3-4 years they can finally rebase it to 5.15 or something like that :)
<ynezz>
Ansuel: so if you really want to be sure (thats my understanding of the CI), you should do e2e build
<ynezz>
Ansuel: please note, that I'm not saying, that you should do that for every single push in every single PR
<Ansuel>
ynezz my concern is time and the fact that with force push and other stuff other workflow will be queued indefinetly
Guest1614 has quit [Ping timeout: 480 seconds]
shoragan has quit [Quit: quit]
shoragan has joined #openwrt-devel
<robimarko>
nbd: Thanks for trying anyway
shoragan has quit []
shoragan has joined #openwrt-devel
<Ansuel>
robimarko another bugilla report to do ? :D
<robimarko>
Couldnt hurt, but I have a feeling they care only about the user cards
<robimarko>
Since those are in laptops
<Ansuel>
yep....
<Ansuel>
well a router is a laptop with no display if you think about it :D
<Ansuel>
attach an ups and done it's a laptop
whatevs111[m] has quit [Write error: connection closed]
pavlix has quit [Write error: connection closed]
lipnitsk has quit [Write error: connection closed]
decke[m] has quit [Write error: connection closed]
t4h4[m] has quit [Write error: connection closed]
Jonny[m] has quit [Write error: connection closed]
olmari has quit [Write error: connection closed]
MatMaul[m] has quit [Write error: connection closed]
will[m]1 has quit [Write error: connection closed]
gnustomp[m] has quit [Write error: connection closed]
ctdvqgg445[m] has quit [Write error: connection closed]
John[m]123456 has quit [Write error: connection closed]
fpsusername[m] has quit [Write error: connection closed]
nick[m]1 has quit [Write error: connection closed]
bluse-blue[m] has quit [Write error: connection closed]
mkg20001 has quit [Write error: connection closed]
Movedtomkg20001mkg20001io[m] has quit [Write error: connection closed]
MatrixTravelerbot[m]1 has quit [Write error: connection closed]
JuniorJPDJ has quit [Write error: connection closed]
domon has quit [Write error: connection closed]
znullptr[m] has quit [Write error: connection closed]
Kiste has quit [Write error: connection closed]
schmars[m] has quit [Write error: connection closed]
fieryeagle954[m] has quit [Write error: connection closed]
barhom has quit [Write error: connection closed]
dfceaef[m] has quit [Write error: connection closed]
oliv3r[m] has quit [Write error: connection closed]
tohojo has quit [Write error: connection closed]
aparcar[m] has quit [Write error: connection closed]
Q__ has quit [Write error: connection closed]
evils[m]1 has quit [Write error: connection closed]
hexagonwin[m] has quit [Write error: connection closed]
<robimarko>
nbd: Looks like FW is enabling decap offload per VDEV
<soxrok2212>
so should i not bother testing the wds patch?
<robimarko>
Give it a go if you have time, but its probably not gonna fix it
<soxrok2212>
alright ill build it now. have any ideas as to why 802.11s is broken? i saw one user report its only on 5ghz that its broken and 2.4g works fine
<robimarko>
No idea really
<robimarko>
But yeah, doubt the patch will fix decap
<robimarko>
As I checked and rx_decap is set by the initial FW init call
<soxrok2212>
ok just drop that patch into the subsys patch dir and re-built?
<robimarko>
Yeah, or apply the commit as patch
<soxrok2212>
alright building, will report back when its done
<soxrok2212>
not even sure the benefits of en/decap, im getting over 1gbit/s over wireless
<robimarko>
Reducing CPU usage
Tapper has joined #openwrt-devel
<soxrok2212>
ah okay.
<soxrok2212>
really wish xiaomi put 2.5g ports on the redmi ax6000. im massively bummed, thing is working like a champ right now
<robimarko>
You are asking too much for a Redmi model
<robimarko>
They skimp on the Mi ones, let alone Redmi
<soxrok2212>
i mean they put an mt7986 in it
<robimarko>
I know, but then they will skimp on all of the peripherals
<robimarko>
And ethernet PHY-s are pretty expensive
<soxrok2212>
i easily wouldve paid another $50 to get 2.5g+ on this
<robimarko>
Well, that would kind of kill whole logic behind the Redmi models
<soxrok2212>
guess so. im not familiar with their lineups
<oliv3r[m]>
Ansuel: while you are absolutely right and we should build all targets; I'm slowly migrating to a single kernel for the realtek platform :) (rtl931x being weird is still singled out, but that just needs some TLC)
Gaspare has joined #openwrt-devel
cbeznea1 has joined #openwrt-devel
cbeznea has quit [Read error: Connection reset by peer]
tlj_ has quit [Remote host closed the connection]
tlj_ has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
soxrok2212 has quit [Read error: Connection reset by peer]
<robimarko>
I dont have any Apple devices, but I have seen a lot of weird WLAN issues with them
<soxrok2212_>
are you referring to slow 802.11ax speed?
<robimarko>
More generaly
<robimarko>
WPA2, then WPA3 issues
<robimarko>
802.11r which is still iffy and such
<soxrok2212_>
havent heard of those ones.
<soxrok2212_>
havent used 802.11r yet but wpa2 and wpa3 work fine across all my apple stuff
<robimarko>
Forum is a goldmine
<robimarko>
WPA3 was iffy, but it got fixed up with some stuff Aple requires
<robimarko>
802.11r is still weird, there is a whole thread about it
<soxrok2212_>
do you think the slow 11ax speeds are an issue with mac80211 or broadcom? seen some samsung devices hit by that same thing
<robimarko>
No idea really, mac80211 and related drivers are complete mistery to me
<soxrok2212_>
rip. anyone you know that's more familiar with them in here?
<castiel652>
that'd be Felix
<robimarko>
nbd is pretty much your guy
<soxrok2212_>
nbd: any input here? i got ath11k and mt76 chips all behaving the same way. hard to pinpoint the issue
<Ansuel>
as usb, wifi is full of standard but everyone implement their stuff their own way... apple is at peak of implementing wifi standard in their own special way
<soxrok2212_>
its also samsung too. someone with a newer galaxy phone had the same problem
<oliv3r[m]>
So I'm learning bout SerDeS calibration/training; and (obviously) notice it's quite board specific, as it relies on the layout of the board. This sounds somewhat like 'hardware configuration' e.g. devicetree. How are other boards handling this? The number of static tables in the kernel would grow huge, and we'd still need to map them to a compatible that matches a board in the end ...
<robimarko>
oliv3r[m]: So far I have not seen other platforms requiring calibration for SFP
<robimarko>
Let alone DAC-s
<oliv3r[m]>
(things get even more confusing when we're talking about DAC calibration; as that can be in the kernel, as you hotplug a unit; but there's of course some 'offset calibration' that relates to the traces on the PCB ...
<oliv3r[m]>
robimarko: I'm working on the realtek stuff; and with those 10G SFP+ cages, but even the 10G onborad serdes's they defiantly need it.
<robimarko>
oliv3r[m]: I am following great PR-s you are doing
<oliv3r[m]>
SFP+ .. is where it gets more interesting (that's the part i'm trying to figure out now, due DAC's behaving differently)
<oliv3r[m]>
anyway, Ansuel robimarko I'd love some help on some MR's so they can go through :)
<oliv3r[m]>
i'll go try to learn more about this tx calibration now :(
<Ansuel>
robimarko sure but something like qcom,pll = <0xf426a>; will be nack... something like qcom,serdes_calibration = <0xf 0x5 0x2>; with some documentation is more upstream friendly.
<robimarko>
QCA SDHCI driver uses qcom,ddr_pll with a magic value
<Ansuel>
(probably auto-accepted)
<oliv3r[m]>
i'd be looking at realtek,serdes_calibration = <0xf 0x5 0x3>; indeed, or even more preferably, realtek,serdes_calibrartion-main_amp = <0xf>;
<robimarko>
Not ideal, but its not like you can get around it
<robimarko>
To me its rather weird that DAC-s are special
<Ansuel>
oliv3r yep that is the idea... yes making different binding is even better
<robimarko>
Though, I get that their signal quality is gonna be lower than fiber
<robimarko>
As its just twinax copper
<Ansuel>
robimarko the strange thing is that all this stuff needs to be done manaully and it's not done by some algo
<Ansuel>
like psgmii
<robimarko>
Well, there isnt a PHY on the other side so you cannot use CRC and packet counters
<robimarko>
SFP modules and DAC-s are not meant to do any calibration on their side
shoragan has quit [Ping timeout: 480 seconds]
shoragan has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
<blocktrron>
robimarko: please check your DSA patches in my staging tree
<blocktrron>
I plan on test-building some targets i have here and if it works as expected we can push this to master if you think it is ready
hanetzer has quit [Read error: Connection reset by peer]
hanetzer has joined #openwrt-devel
Gaspare has quit [Quit: Gaspare]
<robimarko>
blocktrron: Only thing that needs double checking is boards that are disabled as Jalapeno as example has been converted for ages
<robimarko>
Other than that, code has been widely used for a long time
<Ansuel>
fun that ipq40xx have dsa before ipq806x
<Ansuel>
wonder if I should just ignore the perf regression and work on the switch
Slimey has joined #openwrt-devel
<robimarko>
There are also some PR-s for board conversion against my tree, but I just dont have time to babysit each one of them
<robimarko>
Its better for those to get opened against OpenWrt and get higher scrunity as well
<blocktrron>
robimarko: can you ceck i disabled all i should and non i shouldn't?
<robimarko>
blocktrron: Yeah, I am looking at the list
<blocktrron>
Close those PRs and direct them over t openwort as soon as this is merged
<robimarko>
Ansuel: Have you looked at enabling threaded NAPI in sttmac?
<blocktrron>
This PR against staging-trees is a absolute hssle to deal with
<robimarko>
Yeah, that is my plan
<robimarko>
Just point them to OpenWrt master to make the PR against it
<Ansuel>
robimarko should be already enabled o.O
<Ansuel>
let me check
<blocktrron>
btw thanks for taking care
<robimarko>
Ansuel: Not in upstream at least
<blocktrron>
btw do you have any insight regarding what happens when the ipq40xx kernel reaches 4M?
<robimarko>
blokctrron: Nothing should really happen
<robimarko>
Unless vendors did the stupid thing of using sf read with a fixed size
<blocktrron>
I vaguely remember from reading qca uboot that they use the fixed 4M from smem sepcified for the HLOS partition
<robimarko>
The ones that possibly may have issue are SPI-NOR only boards
<robimarko>
Those with UBI shouldnt have any issues
<Ansuel>
robimarko you are right it's not enabled but no idea if it will cause perf improvement
<robimarko>
If its got more than one queue than it will
<tmn505>
and indendation at meraki,mr74: https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=commitdiff;h=14c11bf0ff4018d3db8b2de46752afd9170a8e04#patch2
tlj_ has joined #openwrt-devel
<blocktrron>
tmn505: what is your errata based on?
<Ansuel>
Maginx I miss track if we fixed each problem with that
<Ansuel>
(mean the zlib problem)
<Ansuel>
zstd*
<Mangix>
Ansuel: all the bad commits were reverted, so this can proceed
<Ansuel>
doesn't depend on the other?
<Mangix>
not really
<Mangix>
My goal was to avoid adding -Wl,rpath, to HOST_LDFLAGS, but it's a bit complicated
<Mangix>
the PR as is has that.
<Ansuel>
require major patching or other limitation ?
<Mangix>
the former
<Mangix>
so toolchain/gcc currently does not use tools/zstd for libzstd. My patches make it do so. But once done, GCC completely fails on packages that use LTO
<Mangix>
which indicates there's a problem with tools/zstd