**** BEGIN LOGGING AT Fri Dec 18 02:59:56 2020 Dec 18 06:09:38 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_omap.html has been updated. (0% images and 97.1% packages reproducible in our current test framework.) Dec 18 07:04:59 #freenode_#openwrt Dec 18 07:05:01 oops Dec 18 07:22:33 nbd, ping Dec 18 11:19:37 nbd, sorry, had to travel, back to the office now Dec 18 11:19:58 regarding your 5.10 wip Dec 18 11:20:16 nitroshift: pong Dec 18 11:21:47 patch /target/linux/generic/pending-5.10/611-netfilter_match_bypass_default_table.patch needs to be removed Dec 18 11:22:20 i'm currently updating to 5.10.1 and i've already fixed up that patch locally Dec 18 11:22:22 it will crash on boot Dec 18 11:22:31 oh, nice :) Dec 18 11:22:51 did it crash with rc7 as well? Dec 18 11:22:53 this is what i got with it applied: Dec 18 11:22:54 https://pastebin.com/NBHEZi7n Dec 18 11:23:04 i skipped rc7 Dec 18 11:23:31 so what version were you using? Dec 18 11:23:53 i was using rc5 and went straight to release Dec 18 11:24:11 and the patch applied cleanly? Dec 18 11:24:21 or did you have to fix it up? Dec 18 11:24:21 second hunk didn't Dec 18 11:24:37 removed that part and it applied cleanly Dec 18 11:24:50 you simply removed the hunk without fixing it up? Dec 18 11:25:29 i tried to fix it but i forgot i had a build running Dec 18 11:25:51 that explains the crash then Dec 18 11:25:55 yeah Dec 18 11:26:06 the fix for the hunk is trivial Dec 18 11:26:10 READ_ONCE replaced with rcu_access_pointer Dec 18 11:26:26 currently doing a fresh build with my fixed version Dec 18 11:26:30 :) Dec 18 11:26:58 it's expected that patches like this cause weird breakage if you leave out a random part :) Dec 18 11:32:39 nbd: is this related to swconfig? https://github.com/openwrt/openwrt/blob/master/target/linux/mvebu/patches-5.4/700-mvneta-tx-queue-workaround.patch Dec 18 11:34:03 mangix: not at all Dec 18 11:34:12 it's related to pushing traffic from multiple cpu cores at the same time Dec 18 11:34:33 when i tested it, there was apparently fixed priority scheduling between queues Dec 18 11:34:44 and the one on the first core got all of its packets out and other cpus were starved Dec 18 11:36:58 nitroshift: 5.10.1 support tested and pushed to my staging tree Dec 18 11:40:11 nbd: so DSA with its single interface limitation is also affected? Dec 18 11:40:18 nbd, NICE, THANKS :) Dec 18 11:42:07 sorry for caps :| Dec 18 11:47:15 mangix: i haven't tested this with dsa, but i'd expect it to be affected too Dec 18 11:47:26 since dsa slave devices don't have their own queues Dec 18 11:47:43 and typically multiqueue is used to have one queue per cpu Dec 18 11:48:07 a proper fix would be to figure out how to configure hardware queue priority settings Dec 18 11:48:12 in the mac registers somewhere Dec 18 11:48:23 and make sure they have equal weight/priority Dec 18 11:48:30 maybe round-robin scheduling Dec 18 11:52:12 hmm OK. I assume this was tested with an armada 38x device? Dec 18 12:00:42 i don't remember if i tested on 38x or the older one Dec 18 12:15:48 so I take it's a bit early to try test driving 5.10? :P Dec 18 12:16:08 my wife will kill me if she cannot netflix. Dec 18 12:16:29 i'm already playing fast and loose by running master everywhere :P Dec 18 12:23:10 mangix: i could easily reproduce it with iperf (not iperf3) and -P 4 Dec 18 12:37:46 Hauke: btw. the iw commit in your staging tree lacks your s-o-b Dec 18 12:38:09 master everywhere++ Dec 18 12:38:30 nbd: noted. the armada question was mostly about the impact of HWBM. Dec 18 12:38:46 i don't think hwbm affects it Dec 18 12:39:00 i think it's a property of the hw queueing part only Dec 18 12:39:29 back when i looked at this, i didn't find any code in the driver that even configures queue priorities Dec 18 12:39:46 so my guess is that they're simply left at hw power-on defaults Dec 18 12:39:50 or configured by the boot loader or something Dec 18 12:41:02 hmm OK. I'll try to find time to run some tests. Dec 18 12:58:03 Borromini: steal my HA setup and you can reboot without impacting netflix :D Dec 18 13:14:35 :P :P Dec 18 13:27:07 Borromini: I used to do that. Then I got lazy and switched to TurrisOS. Dec 18 13:27:33 which still has weird bugs. Dec 18 13:29:10 Borromini: I see your "running master on the device wife also uses" and I raise you "running master on the device parents also use". :P Dec 18 13:29:13 :P Dec 18 13:29:33 rsalvaterra: haha i won't go there. friends and family are on a curated stable ;) Dec 18 13:29:38 bbl. Dec 18 13:31:28 oh my parents are on the ISP controlled device. living 2000+km away and not my problem now :P Dec 18 13:32:55 stintel: Hm… I wouldn't let my family use the ISP's CPE… :/ Dec 18 13:33:02 relatives are part of the extended testbed Dec 18 13:33:27 russell--: That's the spirit. XD Dec 18 13:33:31 traffic generators Dec 18 13:33:56 rsalvaterra: they also use apple, lost cause, I gave up long time ago Dec 18 13:34:34 Ouch… Dec 18 13:34:36 my dad's imac had to be returned because dead, they complained it ran too hot Dec 18 13:34:46 yeah who the f* designed it you numbnuts Dec 18 13:34:56 the fail in this company is strong Dec 18 13:36:05 The only good Mac is the DC 2,3 GHz air-cooled G5 (PowerMac11,2). Dec 18 13:36:14 Because it's, well… all IBM inside. Dec 18 13:57:48 russell--: thanks, this would solve the issue with exposed partitons, but I can't apply the same scheme, since the flash space needs to be continuous with nothing inbetween (art partition) to use concatenate driver. Dec 18 14:26:20 nbd: ok will fix this Dec 18 14:29:29 ynezz: i cant type in lede-adm somehow Dec 18 14:29:39 ynezz: should we not call it 21.01 ? Dec 18 14:34:05 blogic: you were talking about a 802.11ax patchset you've prepared Dec 18 14:34:43 Is this public anywhere? I'm playing around with my UniFi 6 Lite and would like to avoid doubling the effort :P Dec 18 14:43:54 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_lantiq.html has been updated. (98.2% images and 97.0% packages reproducible in our current test framework.) Dec 18 15:17:39 Is it a known issue (or is that considered an issue), that DEVICE_PACKAGES are ignored on initramfs images when CONFIG_TARGET_MULTI_PROFILE, CONFIG_TARGET_PER_DEVICE_ROOTFS and CONFIG_TARGET_ALL_PROFILES are set? Dec 18 15:18:41 This is easily reproducible: curl https://downloads.openwrt.org/snapshots/targets/ipq40xx/generic/config.buildinfo > .config && make defconfig && make Dec 18 15:19:41 tmn505: known, e.g. https://github.com/openwrt/openwrt/pull/3557#issuecomment-720799897 Dec 18 15:20:02 though I'm not aware with the details, I just remember that linked discussion Dec 18 15:22:50 I've got report that the necessary package for installation is missing on initramfs image (uboot-envtools) and internet is not always available on the device during installation. Dec 18 15:24:38 I'll take a look at it, but if it's to complicated I'll send a patch to include the package for whole target. Dec 18 15:25:43 from the comment there, initramfs images do not include DEVICE_PACKAGES as you stated Dec 18 15:26:13 but no idea whether that's intended or can be changed Dec 18 15:28:24 That's why I'm asking. Dec 18 15:34:58 maybe ask blocktrron directly, he seemed to be at least aware Dec 18 15:41:40 adrianschmutzler: I'll wait till after the weekend if someone else knows somethin about this, then will drop comment in that PR. Dec 18 15:55:58 blocktrron: I'll publish it in 1-2 days Dec 18 15:56:06 blocktrron: what SoC is that using ? Dec 18 15:56:58 mt7621/mt7915 ? Dec 18 15:59:22 cororect Dec 18 15:59:49 U6-LR ist MT7622/MT7915 Dec 18 16:04:48 avail in the eu store as of monday for 172e Dec 18 16:04:55 oh nice Dec 18 16:05:18 the U6 Lite employs RSA verification on the FIT config Dec 18 16:05:36 I'm a bit worried for the LR, as it seems to support a trusted bootchain Dec 18 16:05:51 correct me on that if I'm completely wrong here? Dec 18 16:07:53 hmmz Dec 18 16:09:10 blocktrron: way around it ? Dec 18 16:09:20 like do you get uboot console ? Dec 18 16:09:21 For the lite or the LR? Dec 18 16:09:46 either Dec 18 16:10:01 we could just build a new uboot ;) Dec 18 16:10:20 unless they support arm tz Dec 18 16:42:49 blogic: sorry, was keeping my kitchen from burning down Dec 18 16:43:38 Anyways, for the Lite it's a "rename signature to signaturr in the control fdt", repackage and write back Dec 18 16:44:16 For the LR, they are using a way older U-Boot which i wasn't able to locate the signature at all. Dec 18 16:44:44 So they might not verify the signature at all ATM and flash a newer U-Boot in the future. Dec 18 16:45:10 But this is a guessing game until we have the real hardware. Dec 18 16:45:46 THey did the same with the nanoHD (shipping with old U-Boot and not verifying the signature) which they later fixed by upgrading the U-Boot Dec 18 16:46:29 mt7915 performs pretty good, even though HE80 is capped at 550 Mbit/s due to the CPU Dec 18 16:47:02 ok Dec 18 16:47:17 even with flow offload ? Dec 18 16:47:29 the mt7621 can do above 550 on AC cards Dec 18 16:47:38 Should this improve WiFi performance? Dec 18 16:47:45 well Dec 18 16:47:59 it'll reduce network overhead thus freeing up cpu cycles Dec 18 16:48:02 blogic: do you get some error message/hint when you try type in #openwrt-adm ? Dec 18 16:48:15 ynezz: that I need to be registered but I am Dec 18 16:48:23 Good to know, I'll re-test with flow offloading and report back :) Dec 18 16:48:23 i'll close irssi and reconnect Dec 18 16:48:53 blogic: you're not registered Dec 18 16:49:22 oh, weird Dec 18 22:01:09 aparcar[m]: you know you were just contacting openwrt-devel@lists to say that noö-one ever uses openwrt-devel@lists? Dec 18 22:01:21 are we missing something? Dec 18 22:04:40 karlp: lol Dec 18 22:05:00 karlp: I'll fix fhat Dec 18 22:34:50 karlp: done, thanks for the ping Dec 18 23:13:09 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 97.4% packages reproducible in our current test framework.) Dec 18 23:26:08 mangix: thanks for merging #14223 Dec 19 00:06:11 aparcar[m]: not a problem :) **** ENDING LOGGING AT Sat Dec 19 03:00:07 2020