**** BEGIN LOGGING AT Tue Apr 06 02:59:57 2021 Apr 06 04:58:18 ashkan Apr 06 05:44:35 guidosarducci: i'm not good on backports, since I don't build "releases" in my normal workflow Apr 06 06:09:49 Hauke: oh, I need to fix that tonight. thanks for reporting back Apr 06 07:29:18 russell--: Fair enough. The 21.02-to-master delta is small enough I didn't need to make changes, just repeat testing from the master PRs. I expect it's all OK, but any suggestions for testing or corner cases would be welcome. Apr 06 11:21:23 blocktrron: ACK ? https://git.openwrt.org/?p=openwrt/staging/xback.git;a=commit;h=d23297c33b3a94a7a0ff21cc831502e1354b5180 Apr 06 11:37:21 _lore_: I've just scheduled an installation for 802.11ac dynack testing Apr 06 11:38:22 We should have 2 AC sectors (wave 1 2x2) in IBSS and AP/STA at sea in a few weeks from now Apr 06 11:38:38 distance will be roughly 22km again, like last time for 802.11n dynack testing Apr 06 11:39:20 both points are directly reachable through fiber for easy testing and flashing Apr 06 11:46:15 <_lore_> xback: have you implemented it for ath10k? Apr 06 11:47:27 _lore_: Ben Greear already did so it seems for a client of his. He was going to ask them if it could be mainlined Apr 06 11:48:15 It's been a while since I've seen Ben here. I'll ping him via mail Apr 06 11:53:22 <_lore_> ah ok Apr 06 11:53:30 <_lore_> nice Apr 06 11:53:58 <_lore_> if he shares the code we can probably have common library or similar Apr 06 12:21:15 is there an easy flag to turn off -Werror? Apr 06 14:43:26 ynezz: I just started testing 5.10 kernel on imx6 Apr 06 14:43:42 ynezz: did you encounter the PCI sysfs spamming on your devices? https://pastebin.com/raw/D0NHAnbH Apr 06 15:42:52 Hrrm, openwrt 21.02SNAPSHOT seems to be breaking/self-rebooting on BT HH v5 type A ... Apr 06 15:43:38 I'll try to swap the HH v5 type A's on other HH v5 a working as AP here where I have better logging (serial console etc.) Apr 06 15:43:48 may have device with older -master fw Apr 06 15:43:57 Suspecting this ath10k candelatech firmware issue or so Apr 06 16:33:37 xback: I vaguely remember such stuff Apr 06 16:34:29 xback: FYI there is WIP of imx split into subtargets https://git.openwrt.org/?p=openwrt/staging/pepe2k.git in order to support cortexa7 imx6 cores Apr 06 16:37:43 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_tegra.html has been updated. (0% images and 98.1% packages reproducible in our current test framework.) Apr 06 21:56:22 nice, esp32-c3 (risc-v based) can be ordered! Apr 06 21:57:19 ordered 20 at once, aiming to replace all my ESPs with them Apr 06 22:31:50 ynezz: jow https://github.com/openwrt/openwrt/pull/3855#pullrequestreview-627425248 please comment Apr 06 22:40:19 aparcar[m]: fwiw, I approved it Apr 06 22:44:33 guidosarducci okay please convince stintel to merge it *hide* Apr 06 22:44:59 hey I approved it, just wait for the 2nd approval and merge it yourself ;) Apr 06 22:50:07 well I got sort of a disapproval from ynezz Apr 06 22:52:04 1 disapproval isn't the end of the world Apr 06 22:52:41 we had a disagreement, asked for documentation about the counter proposal, got zero response, other devs liked my PR, so merged it anyway Apr 06 22:52:46 people disagree Apr 06 22:52:54 aparcar[m]: stintel: thanks for looking over things so far. Disapproval regarding what? TBH, having folks post concerns in the PR itself would make for easier discussion, as I can't respond to something I can't see. Apr 06 22:54:38 don't let it stop progress Apr 06 22:55:06 especially now since we've just branched, there is room for new/experimental/maybe-even-broken stuff in master Apr 06 22:55:24 if something really messes up we can revert, as we agreed in the second last meeting Apr 06 22:59:47 to proceed with that we need the buildbots to use the latest docker image which contains those packages. since ynezz maintains a good chunk of them we should wait for his response Apr 06 23:10:04 aparcar[m]: True. Aside from my PR, there's a general question of consistency too. I simply added build-time checks for needed host prerequisites, one of which is pre-existing, so this seems the Right Thing To Do. That it highlighted a deficiency on buildbots is a good thing IMO. Apr 06 23:13:51 aparcar[m]: does it increase the kernel size? If so, then nack :) Apr 06 23:13:59 stintel: agree with the sentiment, though that doesn't keep me from testing as thoroughly as I can. Not fun when others break things you use. :-/ (BTW, that's a nice little MCU you're getting) Apr 06 23:15:01 guidosarducci: 20 of them - my first RISC-V HW as the HiFive Unmatched delivery was delayed with ~2 months :( Apr 06 23:15:26 and new build deps, meh Apr 06 23:15:42 guidosarducci: and 100% agree with others breaking things you use, I've been complaining about that a lot recently Apr 06 23:16:21 guidosarducci: but the PR seems mostly new/optional stuff so the chance for breakage is probably limited Apr 06 23:16:22 jow: it doesn't change the default kernel size. Enabling it, as with KALLSYMS, will add to size. Unlike KALLSYM, BTF is off by default in debug and release builds. Apr 06 23:17:38 well, I am very sceptic about that entire (e)BPF business atm Apr 06 23:18:09 stintel: BTF support came in close to the 5.4 kernel release, and by 5.10 is much more widespread. Apr 06 23:18:13 I won't use it, I won't ,maintain it and it appears to introduce a lot of complexities and new dependencies. So nack/neutral from me Apr 06 23:18:13 I can't wait until we fully embrace it Apr 06 23:18:16 BPF is hawt Apr 06 23:18:19 I'll complain once it starts breaking stuff Apr 06 23:18:58 jow: reasonable enough Apr 06 23:19:11 though I'd suggest you try getting some hands on experience with it Apr 06 23:19:16 I liked what I touched so far Apr 06 23:21:54 so for what is that BTF stuff needed? Apr 06 23:21:57 for XDP? Apr 06 23:22:15 jow: few deps and little complexity that I see. It's simply an extra kernel debug option. It also exposed various upstream problems with cross-compilation, which I've all upstreamed. Apr 06 23:22:19 XDP is one application. improved debugging/tracing/... is another Apr 06 23:22:50 I will not mention firewall5 ;) Apr 06 23:23:12 jow: there are 2 main BPF usage tracks: packet processing (your tc and XDP hooks) and... Apr 06 23:24:10 jow: ... tracing/monitoring/debug, the same space that 'perf' operates in, but on steroids. BTF enables much more on the tracing side with BPF. Apr 06 23:24:26 and this is relevant for OpenWrt how exactly? Apr 06 23:25:04 I mean it took *years* to embrace DSA which is arguably a lot less complex than cross compiling object code on-target to load it into an in-kernel VM Apr 06 23:25:34 jow: it as relevant as 'perf', more so as being easier/featureful to use. Apr 06 23:25:50 I could think of 1 thing: SQM is completely unusable for me on APU2 (which is considered powerful hw), it limits my 1Gbps uplink to maybe 160Mbps, the new, BPF-based tracing/debugging tools might be able to shed a light on "why" this happens Apr 06 23:25:57 the other option is "just disable SQM" Apr 06 23:26:33 jow: apples and oranges. Also there's no cross-compilation on-board. Apr 06 23:27:20 stintel: yes, my original motivation for fixing bugs in iproute2 and better enabling BPF support in OWRT was around SQM/QOS! Apr 06 23:28:18 well that's good to know Apr 06 23:29:14 I am forced to disable SQM, but that means WFH videoconf is subject to wef9pj23r-9023r90-u2rt3-]9u02r3-0r23 when some other device hogs bandwidth Apr 06 23:29:47 load a Debian/CentOS/Gentoo and debug it there Apr 06 23:30:09 I run OpenWrt on my device Apr 06 23:30:23 loading Debian/CentOS/Gentoo on it for just debugging purposes makes no sense Apr 06 23:30:42 if OpenWrt makes that kind of debugging difficult, maybe I should reconsider using OpenWrt at all Apr 06 23:31:52 stintel: that seems pretty low for an APU2. What's the UL/DL asymmetry? Apr 06 23:32:14 guidosarducci: 1000/600 Apr 06 23:32:27 guidosarducci: no sqm -> 900/600 on speedtest.net to local node Apr 06 23:32:34 guidosarducci: sqm on -> maybe 160/160 Apr 06 23:32:36 if I'm lucky Apr 06 23:32:47 Thanks for the information. I'll pass on it though Apr 06 23:33:04 I am sure it'll find another contributor to ack it Apr 06 23:34:59 stintel: nice base stats, but 320 Mbps aggregate is very, very low. So many other things could be wrong however... Apr 06 23:35:32 guidosarducci: I welcome any hints to debug this Apr 06 23:36:01 but I'm mostly becoming an old(ish) fart with a strong opinion but little skill Apr 06 23:37:30 stintel: Yeah, I can sympathize. How bad is the bloat/latentcy without SQM. Often we find with higher-speed links it's not that bad. Your videoconference comment above garbled... Apr 06 23:37:32 guidosarducci: and that's not even aggregate, that's single direction testing :P Apr 06 23:37:53 guidosarducci: if I'm in a videoconf and usenet starts going it's over Apr 06 23:44:17 stintel: Yikes! Worse than I thought... I assume this is configured to use CAKE with priority tiers? The videoconf/usenet conflict could be due to lack of or misconfigured prioritization. Does you CPU usage stay low through all this? Apr 06 23:46:25 stintel: btw, what results do you get for non-SQM speedtests (e.g. DSLreports) that measure bloat and induced latency? Apr 06 23:47:15 let me just try that Apr 06 23:58:21 stintel: point of comparison, from a throughput test on I believe APU2, sees ~700Mbps with SQM in single direction (https://forum.openwrt.org/t/comparative-throughput-testing-including-nat-sqm-wireguard-and-openvpn/44724?u=guidosarducci). Are you using a VPN/wireguard? Things get much worse. Apr 06 23:59:19 guidosarducci: I've some IKEv2 tunnels (strongSwan) Apr 06 23:59:28 but the slow traffic is not going over them Apr 07 00:00:01 also tried to migrate to WG but that's a horrible disaster, I though strongSwan was difficult to get reliable ... WG is ... I've no words Apr 07 00:00:12 the worst I've tried since I've started using OpenVPN 20 years ago Apr 07 00:02:03 stintel: the posted measurements were pushing all traffic through VPN/wireguard. Probably OK if you're using low bandwidth through the tunnel. Apr 07 00:02:48 I will bookmark that post and pay some attention to it on Friday probably (I went from full-time to 4 days per week so I'll have time) Apr 07 00:02:54 thanks Apr 07 00:04:53 the performance limits of the apu2 are a bit surprising (considering that the CPU isn't that bad), but rather well established I think Apr 07 00:05:31 stintel: np, the only way to troubleshoot these things is systematically, "shotgun" approach of trying random things is popular but doesn't work. Apr 07 00:05:44 should be even worse on xBSD Apr 07 00:06:16 pkgadd: well, he's seeing 4-5X lower throughput than others reported, so worrisome. Apr 07 00:06:37 yes Apr 07 00:06:54 I would have expected roughly a 500 MBit/s figure with sqm Apr 07 00:07:00 +/- Apr 07 00:08:33 and VPN shouldn't hamper it that much either, yes, it's all single-threaded, but the VPN stuff itself should 'just' hog one core, sqm another Apr 07 00:08:36 pkgadd: yes, at least that. So many way things can go wrong, but few ways of getting it right. :-/ Apr 07 00:10:59 not it's consistent, enable SQM, speed drops below 200Mbps Apr 07 00:11:28 I'd love to debug that with someone who has time for it and knows what he/she's dealings with Apr 07 00:11:35 someday Apr 07 00:16:57 stintel: sure, catch me one evening when both free. cheers. Apr 07 00:17:20 guidosarducci: you in CEST? Apr 07 00:18:52 stintel: no, PST (-8ish) Apr 07 00:18:56 ow Apr 07 00:19:09 I'm EEST (+3) Apr 07 00:19:31 we'll see, thanks for the offer already Apr 07 00:20:44 stintel: np, take care. Apr 07 01:05:43 If there a flag similar to SMALL_FLASH for SMALL_RAM? Or a way to exclude a package if the target doesn't have xxxx RAM size? Apr 07 01:06:54 other than the two you mentioned, no - you'd have to introduce this flag (and you will find outliers in quite a few targets) Apr 07 01:07:18 Is there actually a SMALL_RAM? ny idea where it's defined? Apr 07 01:07:33 especially as shared/ userland packages generally cover a number of different targets at the same time Apr 07 01:07:39 I will tree-grep for it Apr 07 01:08:04 low_mem small_flash Apr 07 01:08:04 pkgadd: Right, but I'm talking about Suricata, which really shouldn't be available to devices below 512MB RAM Apr 07 01:08:16 pkgadd: Thanks :) Apr 07 01:08:46 I suspected as much, a 512 MB RAM requirement will rule out most (mips-) targets Apr 07 01:09:09 still, there are wide differences between devices in the same target Apr 07 01:09:12 The ER10x can run Suricata, as long as it doesn't use the et/open list Apr 07 01:09:26 and it's ramips, so I was hoping it was defined somewhere Apr 07 01:09:36 Hmm Apr 07 01:09:59 HOnestly, I bet the ER10x could run it if I enabled zswap Apr 07 01:10:08 but I wanted to talk to rsalvaterra first about it Apr 07 01:10:24 and mips24kc does cover (among others) lantiq (not enough RAM), ath79 (not enough RAM) and mt7621 (may actually have enough RAM on a handful of individual devices) - not really possible to make a decision based on that Apr 07 01:10:42 pkgadd: *nod* Apr 07 01:10:58 Same for some of the Octeon targets Apr 07 01:11:19 The shield can run it, but the er/erlit won't.. Not sure on the er4 Apr 07 01:12:04 pkgadd: Suggestions on a way to do it without having to DEPENDS by hand the targets? Or ust leave it to the enduser to not screw it up Apr 07 01:12:53 I think only the later works Apr 07 01:13:03 Joy :D Apr 07 01:13:08 aside from excluding some of the really ancient targets Apr 07 01:13:40 Would it feasible to put technical tables in the targets? Apr 07 01:14:06 Granted, it would be a core change, but hmm Apr 07 01:14:08 I'd pretty guarantee those get outdated very, very soon Apr 07 01:14:55 as there will only start to appear 1-2 outliers witch more/ less RAM - but no one will remember to update the tables Apr 07 01:14:56 well I mean in the target/linux/image/ Makefies Apr 07 01:15:15 like DEVICE_RAM := 1GiB Apr 07 01:15:24 sure, but there won't be any functional effect of those settings Apr 07 01:15:27 Those won't change for individual targets Apr 07 01:15:53 and accordingly the settings will be missed/ cargo-culted over, etc. Apr 07 01:16:22 Hmm.. Wonder if just having it exposed would be useful to anyone but me Apr 07 01:16:51 I can't really come up with a reason Apr 07 01:18:13 low_mem and small_flash make sense for the targets that are really bad, but marking the particular good ones not really Apr 07 01:18:36 and the former settings only affect the non-shared packages (kernel) in particular Apr 07 01:20:01 Yeah. the level for low_mem/small_flash isn't useful for what I'm trying to do Apr 07 01:20:09 Ah well Apr 07 01:21:19 yeah, those basically only cover 4 MB flash and <<=32 MB RAM Apr 07 01:22:28 Yeah, the et/open ruleset is 16Mb in text size itself. Well, they'll just need accountabiity and I'llput a warning in the description Apr 07 01:22:38 and hope for the best Apr 07 01:22:52 if it hurts, don't do it ;) Apr 07 01:23:22 Oh, it WORKS.. I just don't want someone with an Archer C7 bricking their device because they didn't know better Apr 07 01:24:15 it's tp-link it deserves to be bricked :P Apr 07 01:24:21 * stintel hides Apr 07 01:24:26 haah Apr 07 01:24:32 firstboot is always there Apr 07 01:25:04 To check, verify, and uninstall if necessary? Apr 07 01:25:16 I could probably do it in Package/postinst too Apr 07 01:25:29 or preinst and abort the install? Apr 07 01:26:24 why would you? Apr 07 01:26:51 to keep people from being stupid? Apr 07 01:27:12 'but I just need it to do mailing logs, that's surely gonna work on my wrt-54gl!?!" Apr 07 01:27:26 pkgadd hahahahahah Apr 07 01:27:26 :D Apr 07 01:27:38 Grommish sup Apr 07 01:27:42 wait what. doesn't that do wpa8 and 10 terrabit?! Apr 07 01:27:47 Tapper: Sir, how are ya Apr 07 01:28:05 Good man just about to get off to bed. Apr 07 01:28:08 Apr 07 01:28:13 I hope you have a good day. Apr 07 01:28:22 it's generally a bad idea to restrict availability/ installability just because (most of) the devices (or a target) won't really make sense to run it Apr 07 01:28:23 Tapper: *nod* It's late there :) Enjoy the sleep! Apr 07 01:28:28 I am going to try and get on the discord for a chat tomorrow Apr 07 01:28:29 Tapper: you just made it better by asking if we did Apr 07 01:28:32 lol Apr 07 01:28:38 Tapper: I hope you did too Apr 07 01:28:55 if the package is to heavy for your usecase, you'll notice soon enough Apr 07 01:29:03 hahahaha Apr 07 01:29:04 * Tapper Hugs stintel! Apr 07 01:29:20 package too heavy .. that's what she said Apr 07 01:29:24 or something Apr 07 01:29:33 * Tapper waves. "later people" Apr 07 01:29:37 * stintel leaves and goes to bed, hugs Tapper on the way there Apr 07 01:29:42 pkgadd: My concern is damage to the device, but.. I can lockout the lower end and yolo the rest Apr 07 01:29:46 Tapper: Night! Apr 07 01:29:51 stintel: Night! Apr 07 01:31:30 Grommish: case in point, years ago (well, over a decade, actually), I was not happy at all that Windows SBS2008 rejected installing on a device with <8 GB RAM - sure, it doesn't make sense to actually do that, but it was a test device I could spare for doing a particular test - and it didn't matter to me at all that performance was cr^wbad Apr 07 01:32:07 Yeah.. but what happens when Suricata deathloops on a OOM-killer ;p Apr 07 01:32:17 and locks the device Apr 07 01:32:40 end of the story, I had to steal 4 GB RAM out of my own system for the installation (only top remove them again just afterwards) and replace its good Intel e100 network card with rtl8139 (as the former wasn't supported either) - I was not happy about that trouble Apr 07 01:32:49 I know they should know better, but.. You've seen the forums Apr 07 01:33:09 Wait, you had a E1000 that didn't work? Apr 07 01:33:17 How the hell did you manag that ;p Apr 07 01:33:28 Grommish: e100, not e1000 Apr 07 01:33:31 Ah Apr 07 01:33:50 there are no intel drivers for e100 after vista Apr 07 01:34:12 but there are for rtl8139… Apr 07 01:34:22 I had a E1000 4-port in my iDataplex blade for a while, couldn't kill the thing Apr 07 01:35:42 that experience made a quite an anti-fan for intel (well, that and repeated data loss -tx unit hang- on very different e1000 and e1000e cards spanning over half a decade) Apr 07 01:36:05 s/intel/\&\ ethernet/ Apr 07 01:36:08 *nod* Apr 07 01:38:12 I paid a lot of money for e100 in the 90s/ early 00s, because it was better than rtl8319 - but those cheap rtl8139 cards are still supported everywhere Apr 07 01:40:01 pkgadd: One of these days, I need to pick your brain on a few things regarding converting an existing DSA for use on another board, and for issues I'm having with host/install being called every time Apr 07 01:42:39 please don't ;) I'm not that deep into that topic yet - and I don't really have DSA hardware to play with either (looking for something tough) (o.k., that is partly a lie, I do have a 4/32 tl-wr941nd v2 with a marvell fast-ethernet switch and DSA driver, forgive me for skipping that one - and I do have two realtek switches, which don't really offer much opportunity to play with (running in Apr 07 01:42:45 production) either --> that's why I'm looking for something cheap to play with) Apr 07 01:43:56 I want to convert the RTL8366RB to RTL8367RB based on the hardware spec doc I found Apr 07 01:44:02 But, I won't :) Apr 07 01:46:28 maybe my nbg6817 learns dsa first (of the devices I can actually use), but there are still mdio issues to sort out there Apr 07 01:46:44 (before I can try DSA on it) Apr 07 01:48:18 *nod* Currently, i'm mixing DSA and swconfig on the same device and I"m being told that isn't great Apr 07 01:48:54 it's at least a very hard cut between the two subsystems Apr 07 01:49:37 configuring VLANs on a device with more than one switch isn't fun to begin with (lots of unwritten gotchas), but wrapping your head around DSA and swconfig at the same time isn't funny Apr 07 01:49:42 Yes, but I'm having issues on the switch0 (swconfig) having 1 dead port of the 5 Apr 07 01:50:07 mt76 switch uses DSA, the rtl uses swconfig.. 9 of the 10 ports are working, one isn't ;/ Apr 07 01:50:19 yep; I remember - sorry, can't really contribute there Apr 07 01:50:53 Eh, It'll happen eventually. I found the datasheet, it uses the SMI, I just need to learn how to fix it up Apr 07 01:52:35 Anyway, enough for now.. I'll dole out the questions slowly because I know you're already super busy and really lacking interest in a device you don't own.. Next time, it'll be general package info, which will be more up your alley :D Apr 07 01:52:48 Thanks again! **** ENDING LOGGING AT Wed Apr 07 02:59:57 2021