**** BEGIN LOGGING AT Wed Apr 21 03:01:26 2021 Apr 21 06:20:03 nbd: any objections if I mail your mtk_eth_soc patches (with some minor rewordings and fixes) from pending-5.10 upstream, or are they not ready? Apr 21 06:46:42 21.01-rc1 tested on bcm53xx Luxul XWR-3150 - looks fine Apr 21 09:08:32 yay Apr 21 09:08:47 * stintel has working network on the SNIC10E ^^ Apr 21 09:09:12 woo Apr 21 09:11:48 well, partially. 1 of 2 interfaces is working. the 2nd is funky. tcpdump on it shows nothing, yet I can see what it's sending with tcpdump on another machine Apr 21 13:41:39 Jesus, Joseph and doggie-style Mary…! o_O https://www.phoronix.com/scan.php?page=news_item&px=University-Ban-From-Linux-Dev Apr 21 13:43:51 This is absolutely insane. https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/log/?h=umn.edu-reverts Apr 21 13:59:31 wow - how to destroy trust. stupid university Apr 21 13:59:38 yeah, those patch submission should've been marked appropriately, like for example [PATCH backdoor] Apr 21 14:01:18 well, the whole point was, "is it feasible?" Apr 21 14:01:25 and the only way to try that was to do it.... Apr 21 14:01:33 but I can also totally understand banning them now :) Apr 21 14:02:02 adversaries been doing exactly that for ages Apr 21 14:03:41 Too unethical for words. Apr 21 14:04:30 absolute train wreck :) Apr 21 14:05:16 There's an "I'm about to end this man's whole career" meme around here. Apr 21 14:07:04 And some of the patches already trickled down to the stable trees, according to gregkh. Apr 21 14:09:49 I love the response of we don't have to fill out your ethical behaviour forms, we're gonna ban you instead as it's much more reliable. PMSL Apr 21 14:10:34 I wonder which govt funded this - follow the money I say Apr 21 14:13:12 * russell-- wonders who is on the IRB that said, "yeah, okay, this is fine" Apr 21 14:15:55 *190* commits reverted. https://marc.info/?l=linux-kernel&m=161901009625117&w=4 Apr 21 14:16:00 The "easy ones". Apr 21 14:18:57 "IRB [...] determined this is not human research. We obtained a formal IRB-exempt letter" Apr 21 14:23:11 Uh… humans were being observed for their reactions, how's that *not* human research? Apr 21 14:23:33 NSF awards CNS-1815621 and CNS-1931208 Apr 21 14:23:48 "in part" Apr 21 14:26:58 stintel, I emailed the h2o maintainer packager about ruby just to be sure, and he says it indeed was not intentional Apr 21 14:27:07 stintel, i'm preparing a PR for later this week with a few improvements in the area :) Apr 21 14:27:52 Habbie: perfect! Apr 21 14:28:14 * stintel curses nvmem Apr 21 14:29:53 I have a mac address at offset 0x42 an nvmem device, but it seems impossible to use that. what is this badly documented nvmem-cells and nvmem-cell-names voodoo :/ Apr 21 14:33:00 not, perhaps a dumb suggestion, an alignment issue? you also can't read from 040? Apr 21 14:33:01 https://mjmwired.net/kernel/Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml very useful Apr 21 14:33:02 0x40 Apr 21 14:33:22 it's not even an option to read from nvmem with an offset, afaict Apr 21 14:33:43 I mean, not by specifying something a DTS file Apr 21 14:34:51 with the mtd-mac-address property you can specify a phandle + offset, but that seems not supported for nvmem-mac-address Apr 21 14:35:50 i removed the boost dep from net/dnsdist/Makefile, but it still builds Apr 21 14:36:05 probably because boost is still around from earlier? Apr 21 14:36:11 how do i 'clean' that? Apr 21 14:36:14 is it a PKG_BUILD_DEP ? Apr 21 14:37:11 in openwrt/packages, it is a DEPENDS (which I guess implies PKG_BUILD_DEP?) Apr 21 14:37:14 i removed it as DEPENDS Apr 21 14:37:20 which should fail the build Apr 21 14:37:33 because it -does- need to be a PKG_BUILD_DEP, but i take small steps so i know what i'm doing works Apr 21 14:38:21 it's possible that the runtime dependency check I pointed you to yesterday only runs at the end of make Apr 21 14:38:28 not sure tbh Apr 21 14:38:35 no, it's not about the runtime dependency check Apr 21 14:38:44 dnsdist cannot build without boost; but it can run without boost Apr 21 14:38:55 ah Apr 21 14:39:08 yeah in that case it's because it's still there Apr 21 14:39:19 ehr, try make package/boost/clean Apr 21 14:39:30 ok, that does something Apr 21 14:39:34 but that might not be enough Apr 21 14:39:35 i tried 'uninstall' which does not work :) Apr 21 14:40:19 ./staging_dir/hostpkg/include/boost/shared_array.hpp Apr 21 14:40:23 right, that looks like it did not work Apr 21 14:40:36 that's different Apr 21 14:40:41 that's hostpkg Apr 21 14:40:47 let me see Apr 21 14:40:50 right Apr 21 14:41:46 i could also nuke build_dir entirely, would give me back the 15GB i spent on x86 yesterday too :) Apr 21 14:41:58 make package/boost/host/clean Apr 21 14:42:03 try that Apr 21 14:42:05 tried that Apr 21 14:42:19 actually I'm not sure if there's something that cleans up staging_dir Apr 21 14:42:24 ok Apr 21 14:42:28 maybe someone more familiar with that stuff can answer Apr 21 14:42:34 then i'll nuke staging_dir Apr 21 14:42:42 thanks :) Apr 21 14:43:31 you're welcome Apr 21 15:01:36 looks like it's quite unhappy unless i also remove build_dir Apr 21 15:01:43 perhaps i should have done 'make clean', even simpler Apr 21 15:01:48 but we'll see Apr 21 15:52:01 surprisingly, without boost, the build fails on a missing 'bits/libc-header-start.h' Apr 21 15:55:15 ok, putting boost back in did not fix that Apr 21 15:55:17 exciting Apr 21 15:56:41 bbl Apr 21 15:58:13 Habbie: that's probably because you nuked staging_dir - I should have warned you that could result in all kinds of weird behavior Apr 21 15:58:36 sorry Apr 21 16:25:13 * Slimey hugs Apr 21 17:44:03 stintel, no worries :) Apr 21 17:54:50 russell--: Apr 21 17:54:53 oops Apr 21 17:55:47 rsalvaterra: Where's your CONFIG_HZ pr - I'm feeling dangerous and in the mood to just merge stuff Apr 21 17:56:26 ldir: I haven't sent a PR, because it's on top of my ubifs PR… which is still waiting to be merged. :P Apr 21 17:56:58 Here: https://github.com/openwrt/openwrt/pull/4051 Apr 21 17:58:33 not feeling *that* dangerous Apr 21 17:59:54 XD Apr 21 18:00:39 It's actually pretty innocuous, the idea is for ubifs filesystems be be created with zstd compression by default. ;) Apr 21 18:00:46 that's stuff I don't use, don't understand, so..... running away Apr 21 18:01:54 when people say 'will break sysupgrade' - but yes as a default is very good. Bloody backwards compatibility - baaaaaahhhhhh Apr 21 18:02:54 ldir: That sysupgrade breakage was indeed true, in a previous iteration, but that's long gone (at first I just yolodisabled both lzo and zlib). Apr 21 18:03:16 Now I'm aiming for a smoother ride. :) Apr 21 18:03:24 oh, so you think good to go then? Apr 21 18:04:05 I'm the author, so in my view everything I do is Perfect™. But that's why we have reviewers. :P Apr 21 18:05:03 (I'm running the series on my ubifs Redmi AC2100, just fine.) Apr 21 18:05:54 However, I could try and rebase the series in order to get the CONFIG_HZ patch first, and resend. Apr 21 18:07:03 unless I'm going blind the ubifs PR has no config_hz stuff anyway Apr 21 18:07:59 No, but it also touches kconfig files. Git might be unhappy, depending on the context. Apr 21 18:08:23 Give me a minute, I'm going to try. If everything goes well, I'll send the patch officially. Apr 21 18:08:29 and now I'm feeling really reckless and I want to merge 4051 .... it obviously needs a wider audience to test it :-) Apr 21 18:09:03 ok, point me at the PRs and I'll go daft with the merge script Apr 21 18:09:55 If you'd like to merge 4051, I'd say "go for it". The kernel patch has been accepted upstream. It's done, I was just waiting for feedback. Apr 21 18:11:50 In the long term, I'd like to disable lzo and zlib from ubifs. But that will require some sort of "flag release", in which the users will be forced to erase all data on sysupgrade. Apr 21 18:12:32 (I think that's what we do on every major relase, but I could be wrong.) Apr 21 18:13:37 done Apr 21 18:14:16 ldir: Great! Shall I prepare a PR for the tick? :) Apr 21 18:14:24 please do Apr 21 18:14:39 Alright, give me a minute… Apr 21 18:17:11 ldir: https://github.com/openwrt/openwrt/pull/4099 Apr 21 18:21:40 done - right that's my madness episode over for the day Apr 21 18:21:54 * rsalvaterra braces for impact Apr 21 18:22:04 Heheh! Thanks! ;) Apr 21 18:54:38 ldir: I just noticed 5.10.32 is out. Bumping. Apr 21 19:16:07 nbd: ping. would those mt76 April 16 commits be relevant to the MCU timeout issues i'm seeing on my MT7613 devices? Apr 21 20:27:13 earlier, i managed to build usign separately Apr 21 20:27:15 but i forgot how Apr 21 20:27:18 does anybody know? Apr 21 20:27:32 (make package/index is failing because of it) Apr 21 20:31:14 letting 'make' run a while until it got to it (after the kernel) worked.. Apr 21 20:34:41 looks like relevant output line from that might be make[3] -C package/system/usign compile Apr 21 20:39:26 nice! that SNIC10E running standalone OpenWrt using only 1 queue per ethernet interface already routes ~2.15Gbps with offloading enabled Apr 21 20:40:28 in my previous test I think I wrote flow_offload instead of flow_offloading which obviously didn't work Apr 21 20:41:50 and that's with both interfaces using the same interrupt. sirq at 12% which is 1 of 8 cores at ~100% Apr 21 20:41:57 damn this thing looks promising Apr 21 20:45:05 stintel, neat Apr 21 20:47:09 ok, forcing the 2nd ethernet to a different IRQ didn't help though Apr 21 20:47:23 if anything it made things worse Apr 21 21:16:41 rsalvaterra: > There's no reason to select a higher - why not? Apr 21 21:16:53 would have been nice to see that info in the commit message :P Apr 21 21:20:13 stintel: Hah… indeed. :) Apr 21 21:20:48 I bet it's not going to improve the 2.15Gbps on my NIC-router :P Apr 21 21:21:21 (The kernel gurus correct me if I'm wrong about what I'm going to write…) Apr 21 21:22:35 So, the timer frequency defines how many times per second the kernel scheduler is invoked, at most. Apr 21 21:24:41 Higher frequencies are useful for interactivity (although, to be honest, all my machines run non-preemptible 100 Hz kernels), but bad for throughput (as the scheduler doesn't do useful work). Apr 21 21:24:56 stintel: check https://github.com/openwrt/openwrt/pull/4041 for more complete nvmem based mtd-mac-address implementation Apr 21 21:29:17 stintel: Wait, you only get 2.15 Gb/s on that Cavium beast of a card? :P Apr 21 21:29:56 no he -already- gets that out of it :D Apr 21 21:30:36 i have shaved the dnsdist package plus deps from 20.0MB to 12.7MB Apr 21 21:31:33 Isn't that one of those cards which can basically do eBPF (and XDP) in hardware…? o_O Apr 21 21:31:56 Habbie: nice Apr 21 21:32:26 rsalvaterra: you might be mixing it with something else. octeon ethernet is in staging and nobody cares to improve it Apr 21 21:32:42 ynezz: thanks a lot! Apr 21 21:32:58 stintel: Quite possible… Apr 21 21:34:38 Ah, right, I was confusing with the Netronome and Mellanox card. :) Apr 21 21:35:55 ynezz: I still don't understand anything about nvmem-cells though. nvmem-cell-names = "mac-address" how does it know what cell is named mac-address, or how do you name a cell like that? I fail to get it from the docs or the code Apr 21 21:36:36 (WTF, Mellanox was acquired by NVIDIA…! o_O) Apr 21 21:37:49 oh Apr 21 21:37:51 I think I see it Apr 21 21:38:28 hi family! Apr 21 21:39:12 yes, it seems to be part of their strategy for things like https://www.nvidia.com/en-us/networking/products/data-processing-unit/ Apr 21 21:40:00 basically an Ethernet/Infiniband NIC (what Mellanox does) with an onboard ARM CPU running Linux and GPU-like accelerators Apr 21 21:41:14 you actually define the cell name in the DTS. and then the driver looks for an nvmem cell named mac-address. you no longer need to point it to an nvmem device Apr 21 21:41:33 https://www.nvidia.com/content/dam/en-zz/Solutions/Data-Center/documents/datasheet-nvidia-bluefield-2-dpu.pdf Apr 21 21:44:32 Do you know if there is a place where the Makefiles is resolved with all the values of the variables? I am upgrading hostapd and it is almost done, just need to fix something related with the multibinary/multicall, but I don't understand very well the Makefiles. I am getting at this point this error: make[3]: *** No rule to make target 'config.o', Apr 21 21:44:33 needed by 'wpa_supplicant_multi.a'.  Stop. Apr 21 21:49:36 ughhhh dts files. horrible format, so prone to typos/errors Apr 21 21:53:04 I'm seeing an issue on 19.07.7 where something dies and I lose all routing for a VLAN i have setup on my wrt1900acs. Any thoughts? Apr 21 21:53:18 It's an untagged VLAN assigned to a separate interfeace Apr 21 21:53:22 *interface Apr 21 21:54:01 Logs show nothing when this occurs and the only solution i can find is to reboot the router - this is a daily occurrence and seems to be worse with 19.07.7 Apr 21 21:55:54 The issue seems to occur when there is large amounts of data moving between the LAN and the VLAN interface Apr 21 22:10:26 i'm tailing the logs and there is absolutely nothing displayed when the error occurs Apr 21 22:29:25 can't get those damned nvmem-cells to work. guess it's not compatible with at24 **** ENDING LOGGING AT Thu Apr 22 02:59:57 2021