**** BEGIN LOGGING AT Sat Mar 06 02:59:57 2021
Mar 06 03:03:48 <aparcar[m]1> lipnitsk: dango was faster
Mar 06 04:31:58 <Festivenari_> so, uh, I've been looking around the docs and in the source code, and there doesn't seem to be support for the BCM63137 (however, the BCM63138 SoC is supported)
Mar 06 04:33:16 <Festivenari_> oh, never mind, it doesn't matter
Mar 06 05:16:37 <Festivenari_> oh, my bad, it is supported by OpenWRT
Mar 06 05:21:51 <guidosarducci> jow: ping
Mar 06 05:22:47 <Festivenari_> oh... the source code is available from netgear's servers
Mar 06 05:22:54 <Festivenari_> well, I might just make my own firmware build...
Mar 06 05:31:12 <guidosarducci> rsalvaterra: are you still seeing unreproducible build failures?
Mar 06 06:52:40 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 98.2% packages reproducible in our current test framework.)
Mar 06 08:18:43 <lipnitsk> dangole: thanks for fixing my fix. I guess I didn't fully understand all the intricacies of wildcard matching. Glad that we could get rid of those ugly ifdefs though..
Mar 06 09:28:17 <rsalvaterra> guidosarducci: Yes, a clean master always fails to build tc, for some unfathomable reason… :/
Mar 06 09:28:59 <Borromini> race condition?
Mar 06 09:29:28 <rsalvaterra> guidosarducci: And yesterday I had a build failure with firewall3. It built fine after I retried with make -j 1 V=s.
Mar 06 09:29:46 <rsalvaterra> Borromini: I'm starting to think so.
Mar 06 09:33:52 <Borromini> rsalvaterra: i've seen a lot of builds fail on a few packages lately, and just running a make -j1 'fixes' it
Mar 06 09:35:11 <rsalvaterra> Borromini: Badly specified build dependencies, maybe…?
Mar 06 09:36:59 <Borromini> rsalvaterra: the build system has seen a few changes, maybe that's related
Mar 06 09:37:29 * Borromini wonders what's up with all those people yelling about getting WPA3 to work on mwlwifi or 'old' hardware
Mar 06 09:38:19 <rsalvaterra> Borromini: Tell me about it! :P https://github.com/openwrt/mt76/issues/494#issuecomment-788246013
Mar 06 09:38:59 <Borromini> xD
Mar 06 09:40:47 <rsalvaterra> Being old isn't the problem (I got WPA3 to work on b43 hardware)… being closed is the problem.
Mar 06 09:44:44 <Borromini> someone else is on the forum saying 'i have this old stuff and i now realise WPA3 is fully software'
Mar 06 09:45:00 <rsalvaterra> Borromini: Link?
Mar 06 09:45:14 <rsalvaterra> Found it. :P
Mar 06 09:46:24 <Borromini> https://forum.openwrt.org/t/successfully-get-wpa3-support-for-old-hardware-with-a-self-compiled-openwrt-snapshot-source-code/90476/2
Mar 06 09:47:22 <Borromini> i haven't seen any messages about rt2800-usb not being usable with wpa3, but none to the contrary either
Mar 06 09:48:04 <Borromini> well gotta go
Mar 06 09:48:24 <rsalvaterra> https://github.com/rsalvaterra/linux/commit/b6b15e20421fefae9f78274f9fef80bc97bf5d5c#diff-f80cb11b673cb231fc4e4fd35a17a074e441025ef8d8b485e40202a54961cf53
Mar 06 09:50:06 <rsalvaterra> Borromini: See you later. :)
Mar 06 10:00:07 <PaulFertser> rsalvaterra: fwiw, I'm using rt2800usb with wpa3 right atm.
Mar 06 10:10:49 <rsalvaterra> PaulFertser: I only have mini-PCIe hardware, but it's good to know it also works on USB. :)
Mar 06 10:11:12 <rsalvaterra> Mine: 04:00.0 Network controller: Ralink corp. RT2790 Wireless 802.11n 1T/2R PCIe
Mar 06 10:12:10 <PaulFertser> Bus 001 Device 003: ID 0db0:3871 Micro Star International MS-3871 802.11bgn Wireless Module [Ralink RT8070]
Mar 06 10:12:43 <PaulFertser> I disabled hwcrypt manually though.
Mar 06 10:13:38 <rsalvaterra> PaulFertser: You don't need to, and it's counterproductive. The driver should now fall back to software only for the unsupported features (MFP and the WPA3 handshake).
Mar 06 10:16:31 <mangix> i assume that also works with mwlwifi?
Mar 06 10:16:39 <PaulFertser> rsalvaterra: now yes, i needed it when I was using older kernel.
Mar 06 10:17:20 <mangix> hmm maybe it only works if mac80211 has access to the data path
Mar 06 10:17:24 <rsalvaterra> mangix: I was going to write about that… the problem is when the firmware does so much you can't even fall back to software for the unsupported features.
Mar 06 10:18:00 <mangix> what's stranger is why it's a mac880211 driver
Mar 06 10:18:05 <rsalvaterra> However, as far as mwlwifi is concerned, I could be talking out of my a**, as I haven't looked at the code.
Mar 06 10:18:21 <mangix> sorry, softmac
Mar 06 10:18:36 <mangix> if there's nothing soft about it
Mar 06 10:19:34 <rsalvaterra> And I can't believe after all these years nobody thought about falling back to software, if possible…
Mar 06 10:20:11 <Festivenari_> So, uh, is there a flag to get around the "But that file is already provided by package" error (I'm compiling a build and now it's doing this)?
Mar 06 10:20:31 <Festivenari_> and for some reason, the affected files are sysctl-tcp-bbr.conf and sysctl-br-netfilter.conf
Mar 06 10:26:08 <mangix> rsalvaterra: sounds too easy to be true :)
Mar 06 10:26:40 <mangix> also, this was done with mt76 and ath10k in the past when enabling 802.11w resulted in a speed decrease.
Mar 06 10:27:20 <rsalvaterra> mangix: https://github.com/kaloz/mwlwifi/blob/master/mac80211.c#L490-L543
Mar 06 10:27:36 <rsalvaterra> The answer could be somewhere in that function.
Mar 06 10:28:24 <rsalvaterra> The driver unconditionally enables MFP support… https://github.com/kaloz/mwlwifi/blob/master/core.c#L762
Mar 06 10:29:39 <rsalvaterra> However, I don't have any mwlwifi hardware (thank God).
Mar 06 10:31:51 <rsalvaterra> Woohoo! lipnitsk's pull is merged! Time to kill my Redmi RM2100. :P
Mar 06 10:32:12 <blocktrron> zx2c4: I'd rather wait some time for the backport, as otherwise we have to apply and track bugfixes to both branches
Mar 06 10:32:39 * rsalvaterra hasn't even soldered the UART pins… #yolo
Mar 06 10:34:45 <blocktrron> mangix: someone stated mwlwifi applies magic to some management frames, thus you can't fall back to SW crypto for that
Mar 06 10:34:54 <blocktrron> Similar to iwldvm
Mar 06 10:35:20 <rsalvaterra> blocktrron: Yeah, that's what I thought. Firmware being too smart for its own good.
Mar 06 10:35:33 <mangix> ath10k does the same i believe
Mar 06 10:35:44 <mangix> luckily there's ct
Mar 06 10:35:57 <blocktrron> you can drive ath10k with sw-crypto
Mar 06 10:36:19 <rsalvaterra> mangix: I'm starting to hate ath10k hardware with a passion (I have two QCA9880 on my Omnia).
Mar 06 10:36:32 <blocktrron> also i did not experience speed decrease with MFP /WPA3 and ath10k using the AP chips
Mar 06 10:36:37 <mangix> why two?
Mar 06 10:37:17 <rsalvaterra> With -ct firmware, I have stable WPA3, but the cards crash from time to time (they recover automatically, but it's annoying as hell).
Mar 06 10:37:27 <rsalvaterra> mangix: Because I can…? :P
Mar 06 10:37:32 <mangix> blocktrron: stintel did. don't remember which driver and firmware
Mar 06 10:37:50 <rsalvaterra> They're dual band cards, so I have one for each band.
Mar 06 10:38:01 <blocktrron> The QCA6174 however gets impacted a lot, this might be fixable as the firmware itself does not indicate MFP capability and the driver simply expects the HW to support MFP
Mar 06 10:38:13 <mangix> the 9880s are...pretty much abandoned by qualcomm
Mar 06 10:38:32 <rsalvaterra> Yeah, it's Wave 1 hardware.
Mar 06 10:38:47 <mangix> wave 2 was more stable from what i remember
Mar 06 10:38:57 <rsalvaterra> I'll replace them, eventually. Probably with MT79xx.
Mar 06 10:39:15 <mangix> blocktrron: funny. that happens to me with stock firmware
Mar 06 10:39:22 <mangix> ct firmware does not crash
Mar 06 10:39:33 <blocktrron> crash?
Mar 06 10:39:49 <blocktrron> Or what do you mean with stock firmware?
Mar 06 10:40:13 <mangix> the ct-htt firmware
Mar 06 10:41:20 <rsalvaterra> blocktrron: It's a well-known crash. With the official firmware, the card just dies. With ct-htt firmware, it recovers.
Mar 06 10:41:34 <mangix> so the stock qualcomm ath10k firmware crashes for me when i enable 802.11w and takes the driver with it. ath10k-ct is able to restart the firmware and continue working
Mar 06 10:46:46 <blocktrron> For which card?
Mar 06 10:47:16 <blocktrron> I'm running SAE-MFP with QCA9880 and 9888 since over a year using the QCA firmware /driver
Mar 06 10:49:01 <mangix> blocktrron: qca9880
Mar 06 10:49:11 <mangix> a compex card. forgot the model number
Mar 06 10:50:03 <rsalvaterra> WLE900VX
Mar 06 10:50:37 <rsalvaterra> (They're the ones I have.)
Mar 06 10:53:48 <mangix> maybe it's better now. i think i last tested stock ath10k driver/firmware 2 years ago. been on ath10k-ct driver/firmware since
Mar 06 10:54:25 <mangix> rsalvaterra: don't hold your breath for 11ax minipcie cards
Mar 06 10:54:41 <mangix> even the turris people are having issues
Mar 06 11:18:01 <Q_> My QCA9880 keeps working with stock firmware, it crashes (and recovers) with the ct firmware.
Mar 06 11:19:09 <Q_> When I do a channel analysis with the stock firmware, I actually see more APs.
Mar 06 11:26:18 <rsalvaterra> mangix: Yeah, not holding… I'm fine with ac Wave 2 for the moment. :P
Mar 06 11:26:30 <rsalvaterra> I don't even have ax devices.
Mar 06 11:27:52 <Festivenari_> actually, I think to solve the issue, I need to start from a new .config file
Mar 06 11:27:58 <Festivenari_> I must've botched something up
Mar 06 11:43:44 <rsalvaterra> Sometimes I think the build system just hates me.
Mar 06 11:43:46 <rsalvaterra> "Oh, you're making kernel_oldconfig? I'm going to rebuild the whole toolchain before that, because f*** you."
Mar 06 14:27:37 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_ar71xx.html has been updated. (99.1% images and 98.5% packages reproducible in our current test framework.)
Mar 06 17:25:31 <grift> adrianschmutzler: i dont know what to put in the commit message. any hints?
Mar 06 17:25:46 <grift> dont want to add meaning less text so not sure  ...
Mar 06 17:33:54 <grift> k well i guess i will find something
Mar 06 17:35:35 <adrianschmutzler> if you don't know what to put there as reason for the changes, we probably don't need the changes
Mar 06 17:36:24 <adrianschmutzler> but, of course, version bump is a somewhat special case
Mar 06 17:36:35 <adrianschmutzler> typical message would be a shortlog of changes
Mar 06 17:38:17 <adrianschmutzler> if patches are adjusted something like this: https://github.com/openwrt/openwrt/commit/030bc39c350d301d3cbca4725e845a752c359c5f
Mar 06 17:39:19 <adrianschmutzler> in your case probably just a shortlog like this: https://github.com/openwrt/openwrt/commit/4799810745393742d4c58f398bb1a6cd2ee80d34
Mar 06 17:53:11 <grift> yes i will add shortlog, thanks
Mar 06 18:10:16 <grift> damnit another issue ... v3 ... that is why i try to not get involved in packaging
Mar 06 18:30:38 <grift> we probably should move checkpolicy to packages ...
Mar 06 18:31:44 <grift> i guess its for refpolicy
Mar 06 19:47:02 <Grommish__> adrianschmutzler: Haven't you learned not to leave grift or aparcar[m]1 or rsalvaterra to their own devices? ;p
Mar 06 19:50:37 <grift> dont commit my V3 patch set: i didnt test policycoreutils thoroughly enough
Mar 06 20:02:38 <aparcar[m]1> Grommish__: im missing context what's up?
Mar 06 20:04:46 <Grommish__> aparcar[m]1: Oh, nothing negative :)  grift was asking what to put for a commit message and adrianschmutzleranswered.  I was bring up the rabbit-hole of things that tend to happen when things get shuffled :D
Mar 06 20:05:18 <Grommish__> You know how it goes :)
Mar 06 20:07:45 <grift> i can understand both sides
Mar 06 20:07:59 <grift> i have that same passion for perfection when it comes to policy
Mar 06 20:08:07 <grift> to me packaging is nuisance
Mar 06 20:08:24 <grift> but if packaging is your thing then i can fully understand that you want perfection
Mar 06 20:09:11 <grift> well actually thats i guess a wrong analogy
Mar 06 20:09:21 <grift> as its not about packaging
Mar 06 20:09:23 <Grommish__> Oh, I was referring to the phenomia of fixing one thing that breaks soething else
Mar 06 20:09:43 <Grommish__> I had a car that did that, and i finally settled on not needing a gas guage and I never had another issue ;p
Mar 06 20:10:26 <Grommish__> I've come to appreciate the standardization of things where I once didn't
Mar 06 20:10:35 <grift> well yes but theres also a good side to that
Mar 06 20:10:45 <grift> it might lead of improvement in the end
Mar 06 20:10:54 <Grommish__> *nod*
Mar 06 20:11:26 <grift> due to "missing commit message" comment, i noticed two other bugs
Mar 06 20:12:02 <Grommish__> grift: You handled it better than i did when I hit that wall
Mar 06 20:12:16 <Grommish__> I jusst said never mind and abandoned the commit like a chit
Mar 06 20:12:27 <Grommish__> Not my brightest moment
Mar 06 20:14:08 <grift> i guess theres a couple of aspects to it: first is patience and the second one is confidence
Mar 06 20:14:38 <grift> at least with rebasing, testing etc
Mar 06 20:15:41 <grift> package maintenance can be hard
Mar 06 20:15:55 <grift> you have to know what changed and how that affects your package
Mar 06 20:16:09 <grift> and if something breaks you have to deal with it
Mar 06 20:16:28 <grift> its not just the technical aspect of packaging
Mar 06 20:17:35 <Grommish__> Yeah, mine was more of an ego issue where I took it as a personal affront as to why the version bump needed a commit  message, and since I had it working locally, I literally said "eh, I've got it, if you want it, you can commit it, if not, I don't care" :/
Mar 06 20:17:38 <Grommish__> again, not a highlight
Mar 06 20:18:20 <grift> yes i think i know what you mean but i do think thats also a confidence issue
Mar 06 20:18:37 <grift> becuase with enough confidence its no big deal to address it
Mar 06 20:19:09 <Grommish__> Right
Mar 06 20:19:47 <Grommish__> I just was pissy about it and I freely admit my failing at it :) I've done better since
Mar 06 20:20:04 <grift> it does also require a bit of patience and tolerance
Mar 06 20:20:34 <grift> but yes i totally understand
Mar 06 20:20:45 <grift> you see in this industry its often "hit and run"
Mar 06 20:20:53 <grift> you dump some code and never look back
Mar 06 20:20:58 <grift> and maintainers know that
Mar 06 20:20:59 <Grommish__> *nod* Which is exactly why the papertrail should be there
Mar 06 20:21:10 <grift> so they demand quality
Mar 06 20:21:28 <grift> because they know that probably someone else will have to pick up the pieces later
Mar 06 20:21:37 <Grommish__> Yep
Mar 06 20:23:27 <Grommish__> Its the nature of the project that people come and go
Mar 06 20:23:45 <grift> yes its a pity though
Mar 06 20:23:57 <Grommish__> or simply change devices and platfors
Mar 06 20:24:13 <Grommish__> I get to dip in the ramips targets here soon
Mar 06 20:24:22 <Grommish__> which I've never had the occasion to deal with
Mar 06 20:24:25 <grift> on the one hand people want to "grow" but on the other hand a lot of knowledge gets lost when people constantly get "promoted" away
Mar 06 20:24:35 <Grommish__> Its so much more complicated than the octeon target
Mar 06 20:27:26 <grift> i have zero affinity with switches, boards, chips and shorting stuff :-)
Mar 06 20:27:55 <guidosarducci> rsalvaterra: I've seen multiple reports of package build failures in recent weeks, which I can't reproduce and aren't reflected in buildbots. I've also encountered the unexpected tools/toolchain rebuilds you mention. Little doubt in my mind of build system problems. Extremely damaging because it raises doubts on well-written and tested PRs.
Mar 06 20:28:00 <Grommish__> :)
Mar 06 20:42:45 <lipnitsk> I have seen where a package build failure somehow becomes a package/libs/toolchain failure which wipes enough stuff to cause the full toolchain rebuild. I'll try to pay attention to it next time it happens to try and triage
Mar 06 20:44:27 <lipnitsk> dangole: maybe you should sync up with Adrian on the agreed way to merge things. Seems he didn't quite like your squashing of my ramips changes.
Mar 06 20:44:46 <lipnitsk> rsalvaterra: how is your RM2100 doing? Working ok?
Mar 06 20:55:12 <Borromini> lipnitsk: FYI, Hauke pushed a separate .102 bump to 21.02...
Mar 06 20:55:22 <lipnitsk> oh okay
Mar 06 20:55:25 <lipnitsk> let me see.
Mar 06 20:57:07 <Borromini> i'm hoping more MT7613BE stuff gets ported so we can see if i'm just the only one having problems with those radios
Mar 06 21:18:53 <Borromini> lipnitsk: kernel bumps aren't bundled with other patches, usually
Mar 06 21:19:15 <Borromini> sorry if i gave you the wrong impression in the PR comments.
Mar 06 21:19:53 <lipnitsk> yeah, well I'm glad Hauke bumped it - somebody needed to, so that we can have all the latest WireGuard patches
Mar 06 21:20:53 <lipnitsk> It's a bit of a conflict when you are cherry-picking since on master the change did contain the bump as well as patch update
Mar 06 21:21:11 <Borromini> :)
Mar 06 21:21:18 <lipnitsk> but it should all be cleaner now. I'm rerunning update_kernel.sh just to refresh all targets, but I've updated the branch already
Mar 06 21:23:02 <Borromini> ok, thanks
Mar 06 21:35:40 <guidosarducci> russell--: I'd appreciate a review of my iproute2 size update (https://github.com/openwrt/openwrt/pull/3961) as the maintainer (jow and ldir are pinged on a minor point). This has gone through much testing, and would be a key update before a 21.02 backport. Thanks again!
Mar 06 21:36:38 <Hauke> normally I do the kernel bumps for the branches independent of each other
Mar 06 21:37:09 <lipnitsk> yeah, it is probably better that way - patches may diverge
Mar 06 21:37:51 <lipnitsk> I'm fixing up the branch now after rebasing on top of the latest 21.02
Mar 06 21:39:20 <lipnitsk> man, refresh does take so long, I wonder if quilt can be improved in that regard..
Mar 06 21:39:37 <lipnitsk> two issues with quilt: 1. handle renames; 2. speed up refresh
Mar 06 21:42:27 <zx2c4> lipnitsk: i just made 080-wireguard.patch as a single patch that also doubles as an executable shell script that you can run to update itself... Genius or terrible? Unclear...
Mar 06 21:43:44 <Borromini> zx2c4: can i ask you about https://patchwork.ozlabs.org/project/openwrt/patch/20200512110634.21976-1-fe@dev.tdt.de/ ?
Mar 06 21:44:10 <Borromini> i wasn't able to find if in the end this got sent in for wireguard-tools proper or if it just kept lingering somewhere.
Mar 06 21:44:56 <Borromini> apologies if you responded to my previous highlight, been in and out for the past few days
Mar 06 21:45:01 <zx2c4> Borromini: check out upstream git repo :)
Mar 06 21:45:15 <zx2c4> https://git.zx2c4.com/wireguard-tools/commit/?id=957702af94af22e10377493608befd9750815b5d
Mar 06 21:45:23 <guidosarducci> Hauke: re: "make kernel_oldconfig", are you OK with using it and then manually fixing things up, or prefer taking the raw results? This is related to malta 5.10 update: https://github.com/openwrt/openwrt/pull/3881.
Mar 06 21:46:01 <Hauke> guidosarducci: fix it up in the same commit just mention waht you did
Mar 06 21:46:07 <Borromini> zx2c4: awesome, thanks =)
Mar 06 21:46:07 <Hauke> *what
Mar 06 21:48:42 <guidosarducci> Hauke: OK, thanks. So the main thing for you is knowing it's been run rather than skipped?
Mar 06 21:51:05 <lipnitsk> zx2c4: you mean that will replace the whole patch series so folks here are less scared?
Mar 06 21:59:37 <zx2c4> Yea
Mar 06 21:59:45 <zx2c4> One auto updating file
Mar 06 22:00:33 <lipnitsk> some dark magic?
Mar 06 22:01:09 <lipnitsk> does it just add a layer of abstraction somehow? is it still checked into the repo?
Mar 06 22:01:23 <mangix> Hauke: uClibc++ is now gone from the packages feed.
Mar 06 22:34:16 <lipnitsk> dangole: never mind, I just read https://github.com/openwrt/openwrt/commit/b4aad29a1d7ad77d67073c1c54b28c429c64ed9b#comments, looks like you guys figured it out.
Mar 06 22:48:07 <mangix> aparcar[m]1: can you see why kamailio and freeswitch are failing? I don't see it locally.
Mar 06 22:48:42 <aparcar[m]1> mangix: i never tried to compile it
Mar 06 22:50:16 <mangix> no I mean right now CI is completely failing: https://pipelines.actions.githubusercontent.com/5yKFRfuu84LeYF9JWXeroTFD7H8ygjTZsUcmjLvv85kJt4ah0c/_apis/pipelines/1/runs/3758/signedlogcontent/3?urlExpires=2021-03-06T22%3A48%3A18.2558517Z&urlSigningMethod=HMACV1&urlSignature=a1Grf6whcQcY%2BDS6FmUsXaYIHVKJnKrczudjMqi6ATk%3D
Mar 06 22:51:22 <mangix> CircleCI works fine
Mar 06 23:18:14 <zx2c4> lipnitsk: check it out... https://github.com/openwrt/openwrt/pull/3969
Mar 06 23:18:17 <zx2c4> it's kind of evil
Mar 06 23:18:35 <zx2c4> https://github.com/openwrt/openwrt/blob/895e97a1908f53db2b7cc4278b309106421f5b14/target/linux/generic/backport-5.4/080-wireguard.patch
Mar 06 23:19:55 <lipnitsk> zx2c4: so patch/quilt is happy to execute scripts in .patch files?
Mar 06 23:20:08 <zx2c4> lipnitsk: nono, you run it yourself when you want to update
Mar 06 23:20:28 <zx2c4> `./080-wireguard.patch` will cause it to update itself, for easier maintenance
Mar 06 23:20:52 <zx2c4> quilt/patch just sees it as a normal patch, with a big comment section at the top
Mar 06 23:20:53 <lipnitsk> I see. so quilt will just treat the script as a no-op message
Mar 06 23:21:52 <zx2c4> right
Mar 06 23:22:12 <zx2c4> downside is that by combining these all into one file, if it doesnt apply, its harder to see what broke
Mar 06 23:22:31 <zx2c4> upside is that its a cool hack
Mar 06 23:25:54 <lipnitsk> lol, yeah. a fun exercise if nothing else... I don't know, folks will probably complain or ask why this is so special. It might be worth seeing if this is generalizable at a higher level somehow. Let's see what core folks think of this idea.
Mar 06 23:26:53 <lipnitsk> alternatively maybe it is something acceptable for the update_kernel.sh script or the tools repo
Mar 06 23:27:49 <lipnitsk> zx2c4: the good news is that 5.4 is gonna be deleted from master soon enough. And 21.02 shouldn't need updating that often. What's the update frequency for the backports on average up till now?
Mar 07 00:46:22 <rsalvaterra> lipnitsk: I haven't tested the RM2100 yet, I was sleeping and/or out for a good part of the day. I have built an image, though. :)
Mar 07 00:51:44 <mangix> it appears I will join in the mt7621 fun soon
Mar 07 00:52:10 <mangix> I purchased the only OpenWrt supported ax device
Mar 07 00:52:21 <mangix> I doubt it'll even work
Mar 07 00:54:19 <mangix> LMFAO
Mar 07 00:54:20 <mangix> libbpf version 0.3.0 is too low, please update it to at least 0.1.0
Mar 07 00:55:01 <rsalvaterra> mangix: That's guidosarducci's department. :P
Mar 07 00:55:29 <rsalvaterra> He has a patch to fix that.
Mar 07 00:58:36 <pkgadd> mangix: the linksys e8450/ belkin rt3200 or totolink x5000r or UniFi 6 LR?
Mar 07 00:59:04 <mangix> pkgadd: totolink x5000r
Mar 07 00:59:05 <guidosarducci> mangix: there's a pkgconfig fix waiting to be merged that could be related: https://github.com/openwrt/openwrt/pull/3956
Mar 07 00:59:32 <guidosarducci> mangix: the problem isn't consistently reproducible however.
Mar 07 01:00:14 <mangix> meh just marked both as BROKEN
Mar 07 01:00:32 <pkgadd> hmm, I kind of doubt mt7621 is fast enough for 802.11ax, routing and the other stuff one might want to run on a fast WAN connection (sqm, vpn, ...) - the e8450/ rt3200 however...
Mar 07 01:00:47 <mangix> pkgadd: I don't have fast WAN
Mar 07 01:04:47 <pkgadd> it's a bit of a pity that ipq807x seems to be so difficult to get ethernet and wireless right
Mar 07 01:05:22 <mangix> yeah. that's why I don't bother with them
Mar 07 01:05:38 <mangix> there's a reason blogic calls QCA Qualcomm Crack Addicts
Mar 07 01:06:16 <pkgadd> yeah... still nice hardware
Mar 07 01:06:19 <mangix> anyway, core developer has the totolink. Should be in good shape.
Mar 07 01:07:26 <pkgadd> if it wouldn't be post-Brexit importing from the UK (and associated customs duties + other complications), I might have gone for the rt3200 nevertheless
Mar 07 01:11:00 <mangix> it was an impulse buy on my end
Mar 07 01:11:56 <pkgadd> yep, I'm close to it - but not for 20-25 EUR shipping and customs on top (which seems to be the rough range I'd have to consider)
Mar 07 01:12:09 <mangix> interesting that the other devices use mt7615e for 2.4ghz
Mar 07 01:13:52 <mangix> is that esata on the linksys device i see?
Mar 07 01:14:17 <pkgadd> afaik only USB3
Mar 07 01:15:07 <pkgadd> err, just USB2
Mar 07 01:15:36 <pkgadd> https://www.linksys.com/us/p/P-E8450/   https://www.belkin.com/us/p/P-RT3200/
Mar 07 01:15:58 <mangix> it says kmod-ata-ahci-mtk under device packages
Mar 07 01:16:06 <mangix> also that USB port looks weird.
Mar 07 01:16:22 <mangix> I think it's a combo port like the previous WRT series
Mar 07 01:17:49 <pkgadd> https://www.belkin.com/images/product_webdam/109153374/renditions/webdam.web.1000.1000.jpeg  I don't see anything weird/ eSATA'ish there
Mar 07 01:19:51 <dangole> no ahci in that device
Mar 07 01:19:55 <dangole> it's just USB 2.0
Mar 07 01:20:59 <mangix> why is kmod-ata-ahci-mtk included?
Mar 07 01:21:03 <dangole> (ahci is built-in on MT7622 kernel because SoC has AHCI controller)
Mar 07 01:21:31 <dangole> otherwise the recent kmod-ahci-renesas catastrophy would have affected mediatek target as well
Mar 07 01:21:50 <mangix> unfortunate
Mar 07 01:21:51 <dangole> it didn't because it's built-in... (imho shouldn't be)
Mar 07 01:21:54 <pkgadd> dangole: do you have a rough feeling where the routing limits are with mt7622b and this device?  can it achieve routing at 1 GBit/s wirespeed (soe margin left for e.g. SQM, etc.)?
Mar 07 01:22:41 <dangole> pkgadd: i haven't tried with SQM
Mar 07 01:23:08 <pkgadd> o.k.
Mar 07 01:23:10 <dangole> pkgadd: but generally feels super fast, SCP file upload to /tmp with 40 megabyte / second
Mar 07 01:23:52 <pkgadd> nice
Mar 07 01:23:59 <dangole> pkgadd: tell me what to test, i got the device wired up next to me
Mar 07 01:24:28 <mangix> danitool: iperf router to pc get 930mbps?
Mar 07 01:24:36 <mangix> dangole: ^^
Mar 07 01:25:10 <dangole> mangix: yes, of course. i'll post pastebin to iperf3 in a moment
Mar 07 01:25:24 <pkgadd> dangole: no need to test anything special, but a rough feeling if it can route at those ~930 MBit/s and how much CPU cycles are left (htop) would be very interesting to know
Mar 07 01:25:25 <mangix> i ask because of mt7621 does not
Mar 07 01:26:39 <pkgadd> I'm asking because of my 400/200 MBit/s line, my current ipq8065 can do that (rather comfortably) - but dabbling into SQM wouldn't be possible on that hardware
Mar 07 01:44:00 <dangole> mangix: https://asciinema.org/a/397173 (iperf3) and https://asciinema.org/a/397172 (htop) running in parallel
Mar 07 01:44:24 <dangole> pkgadd: ^^^^
Mar 07 01:45:24 <pkgadd> dangole: thanks a lot, so around 40% CPU usage on one of the two cores for ~900 MBit/s
Mar 07 01:45:39 <pkgadd> that's pretty promising
Mar 07 01:46:02 <dangole> the gmac has two interrupts, i set affinity for both to core 2 to have core 1 deal with wifi a bit faster (+20 Mbit/s)
Mar 07 01:48:13 <guidosarducci> dangole: nice performance. Can TX/RX use both CPUs?
Mar 07 01:48:34 <dangole> guidosarducci: in which sense?
Mar 07 01:49:11 <guidosarducci> dangole: e.g. is RX processing limited to 1 CPU.
Mar 07 01:51:15 <dangole> it got two interrupts which both fire during RX, you can set irq affinity to two different cores, if that is what you mean
Mar 07 01:52:19 <mangix> very nice
Mar 07 01:52:20 <guidosarducci> dangole: thanks, that's what I meant.
Mar 07 01:53:11 <dangole> guidosarducci: https://termbin.com/et5p
Mar 07 01:53:59 <dangole> (the few interrupts on the first core are traffic before i manually set them to core 2, default is affinity 0x3 for both irqs)
Mar 07 01:56:37 <guidosarducci> dangole: understood, I was wondering about the 3X skew. BTW, what's "mtk-ecc"?
Mar 07 01:57:18 <pkgadd> guidosarducci: should be the NAND driver
Mar 07 01:57:50 <dangole> exactly, that's the ECC engine used for both, SPI-NAND and parallel NAND
Mar 07 01:59:39 <lipnitsk> blogic: ping
Mar 07 01:59:43 <guidosarducci> dangole: neat, I haven't played with MTK before so that's new. I'm also surprised the tweaking the affinity made such a big difference in wifi speed.
Mar 07 02:00:19 <dangole> guidosarducci: it's trading ~40 MBit/s +/- Ethernet performance for ~20 MBit/s +/- Wifi
Mar 07 02:00:54 <dangole> i guess because Ethernet performance is better with less context switching while wifi works better with more parallelization (?)
Mar 07 02:02:55 <dangole> with all the offloading wifi anyway easily bottleknecks gigE. haven't tried bonding yet to see if we can get 2Gbit/s in that way...
Mar 07 02:04:01 <dangole> that ubiquiti unifi 6 lr device got 2.5Base-T, so i wonder how mt7622+mt7915e perform on that as AP...
Mar 07 02:04:06 <guidosarducci> dangole: I think that's a good trade off. Wifi performance always seems less predictable than ethernet. I think you're right re: switching: for forwarding use case on ethernet, CPU/memory locality is a preferred thing.
Mar 07 02:04:13 <dangole> but more than double the price...
Mar 07 02:05:09 <lipnitsk> @dangole any idea why we have mtk-eth patches under mediatek and ramips? Can we just consolidate them under generic? I'm talking about ./mediatek/patches-5.10/700-net-ethernet-mtk_eth_soc-add-support-for-coherent-DM.patch and ./ramips/patches-5.10/700-net-ethernet-mediatek-support-net-labels.patch. Should those just move to generic/pending-5.10?
Mar 07 02:05:14 <guidosarducci> dangole: I guess you pick your crack: QCA or MTK...:)
Mar 07 02:06:04 <dangole> guidosarducci: at least with mtk it gets very useful even with "only" 512MB of ram. ath11k wouldn
Mar 07 02:06:13 <dangole> 't work in a meaningful way i've heard
Mar 07 02:06:18 <pkgadd> dangole: afaik (unless anything changed rather recently), blocktrron hasn't been able to make 2.5BASE-T work yet (and it's not officially marketed to exist)
Mar 07 02:06:26 <pkgadd> on the unifi
Mar 07 02:06:37 <dangole> pkgadd: oh, that's sad.
Mar 07 02:06:52 <dangole> lipnitsk: i agree, and i can test on MT7622 :)
Mar 07 02:07:39 <lipnitsk> the labels thingy is pretty generic - a way to set MAC label from dts.. not sure why that needs to be ramips-specific. The coherent DM thing may not apply to ramips, or it might :) I can test on mt7621
Mar 07 02:08:10 <lipnitsk> dangole: okay, I'll put something together.
Mar 07 02:08:55 <dangole> lipnitsk: label mac from dts works on mt7622 as well, i didn't even know that needs an extra patch
Mar 07 02:09:25 <lipnitsk> works with dsa and everything?
Mar 07 02:09:34 <lipnitsk> maybe it's the devicetree structure, let me see.
Mar 07 02:09:58 <dangole> it set's the ifname under linux actually
Mar 07 02:12:28 <lipnitsk> yeah but from which node
Mar 07 02:12:39 <lipnitsk> ports?
Mar 07 02:13:14 <lipnitsk> or you mean, that the ifname is already set somewhere, no need to set it inside the driver?
Mar 07 02:13:36 <lipnitsk> maybe we can just drop that patch then.
Mar 07 02:13:41 <dangole> it get's a 'label' property in mtk_eth_soc.c and uses that as ifname if set
Mar 07 02:14:35 <lipnitsk> 'label' from which node though? switch0-ports-port@X?
Mar 07 02:18:37 <lipnitsk> it's the gmac node the eth driver looks at I think. switch nodes are handled in the switch driver
Mar 07 02:20:57 <guidosarducci> jow: I finally managed to get the DSCP/MARK chains all working in fw3, based on your samples. Still need to clean up then I'll post for you to see. One problem I ran into is with fw3_zone->devices having duplicate entries, creating duplicate rules.
Mar 07 02:21:40 <mangix> lipnitsk: putting patches in generic sounds great
Mar 07 02:22:08 <lipnitsk> yeah I'll move some generic patches out of platform, at least for ramips for now
Mar 07 02:22:40 <mangix> speaking of ramips, some patches need upstreaming :P
Mar 07 02:22:48 <lipnitsk> yes they do
Mar 07 02:22:59 <lipnitsk> It's kind of a mess to unravel..
Mar 07 02:26:26 <mangix> https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/patches-5.10/810-uvc-add-iPassion-iP2970-support.patch
Mar 07 02:26:30 <mangix> i have no idea what this is
Mar 07 02:29:26 <pkgadd> that should be a webcam, but why that's part of rampis specific patches...
Mar 07 02:29:40 <mangix> I sent https://github.com/openwrt/openwrt/blob/master/target/linux/mvebu/patches-5.10/303-linksys_hardcode_nand_ecc_settings.patch upstream. Maybe I should ask them to backport
Mar 07 02:30:25 <pkgadd> https://patchwork.kernel.org/project/linux-media/patch/1412966473-5407-2-git-send-email-blogic@openwrt.org/  that's slightly more enlightening
Mar 07 02:30:31 <pkgadd> D-Link DIR-930 IP cameras
Mar 07 02:31:19 <mangix> wonder why it was not merged.
Mar 07 02:33:20 <pkgadd> seems to be this thing, https://wikidevi.wi-cat.ru/D-Link_DCS-930L_rev_A1  (yes, DIR vs DCS, but I think so)
Mar 07 02:38:23 <lipnitsk> mangix: probably because blogic didn't have time to pursue it?
Mar 07 02:40:23 <mangix> lipnitsk: I mean, there are no messages on there
Mar 07 02:40:45 <lipnitsk> a couple here: https://lore.kernel.org/linux-media/1412966473-5407-2-git-send-email-blogic@openwrt.org/
Mar 07 02:41:01 <mangix> ah ok
Mar 07 02:42:40 <lipnitsk> this one kind of bothers me too: https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/patches-5.10/316-arch-mips-do-not-select-illegal-access-driver-by-def.patch seems to be an informational driver that's just disabled in openwrt for whatever reason. Why is it enabled on mainline by default.. probably should change that default to n and make it visible in menuconfig
Mar 07 02:43:01 <lipnitsk> ie upstream the patch.
Mar 07 02:49:57 <mangix> wonder if some of russell king's patches should be added
Mar 07 02:55:46 <lipnitsk> mangix: what are those?
Mar 07 02:55:55 <lipnitsk> mangix: backports from latest mainline?
Mar 07 02:55:56 <mangix> https://github.com/armbian/build/blob/master/patch/kernel/mvebu-current/10-mvebu-clearfog-pcie-updates.patch and https://github.com/armbian/build/blob/master/patch/kernel/mvebu-current/11-implement-slot-capabilities-SSPL.patch
Mar 07 02:56:18 <mangix> seems he's adding some feature
Mar 07 02:58:10 <mangix> lipnitsk: I have no idea
**** ENDING LOGGING AT Sun Mar 07 02:59:56 2021