**** BEGIN LOGGING AT Thu Jun 06 02:59:57 2019 Jun 06 04:29:07 I can provide shelter here up north for overheated devs. They are predicting warm weather - 19 degrees Jun 06 06:33:52 lynxis: morning. do we have any agenda for sunday already? I'm undecided whether I should take the train to hamburg on sunday evening or monday morning Jun 06 08:09:37 anybody planning to push something to master anytime soon? testing automated builds :-) Jun 06 08:14:08 I can push something if you want Jun 06 08:14:43 no need to rush things but if you had something already queued, curious to see if cds will pick it up Jun 06 08:16:56 ynezz: cheers :) Jun 06 08:17:21 I've few more ready, so I can push them one by one if it helps you Jun 06 08:19:05 btw what are you cooking? Jun 06 08:20:10 decided to give https://github.com/ovh/cds a try Jun 06 08:21:27 right now it's just downloading my rpi0w diffconfig from github gist, builds from that, when done sysupgrade my test rpi0w and if that succeeds it should sysupgrade the other 4 I have Jun 06 08:22:46 some day I hope to have all my (diff)configs in a git repo, and autobuild for all my devices, with auto sysupgrade (if I have a non-production device to autotest before doing prod) Jun 06 08:24:49 it tried to start a build after your commit but something already failed :P Jun 06 08:27:06 looks nice Jun 06 08:30:30 it's a bit of a pity it does not support regular git repos Jun 06 08:30:37 but only github gitlab or bitbucket Jun 06 08:32:23 because of the webhooks? Jun 06 08:33:22 no, it can also just poll the repos. I guess they have no use for normal git repos because _everybody_ uses github gitlab or bitbucket Jun 06 08:36:42 jow: any opinion on https://github.com/openwrt/packages/pull/9064 ? Jun 06 08:45:56 stintel: purely fyi, the last 2 kernel bumps included a lot of memory leak fixes and a bunch of fixes for btrfs Jun 06 08:46:28 xback: ah, thanks! I had to reboot that VM recently because everything oom'd Jun 06 08:50:40 stintel: Didn't see this till now... but have just pushed something. Jun 06 08:52:51 ldir: ooh it's working this time :) Jun 06 08:53:16 you wait till it finds my patch.... then booooooom :-) Jun 06 08:54:07 I'm running this thing on ppc64le which upstream didn't support, tried master to see if that would help. had to hack it eventually but didn't go back to release tag. did that now and now the repository puller seems to work Jun 06 09:02:53 well if you get a successful kernel build out of it I'll be very relieved. Jun 06 09:04:52 quick question, rpcd.init looks mixed old/procd triggers? https://github.com/openwrt/openwrt/blob/master/package/system/rpcd/files/rpcd.init Jun 06 09:04:52 Is this a bug stop()/reload() is not used by procd? Jun 06 09:11:34 ldir: it just passed toolchain :) Jun 06 09:11:40 we will know soon Jun 06 09:14:02 ah but I'm not building with all kmods so it's not going to be built Jun 06 09:15:47 andy2244: it will work, but yes, looks rather unnecessary Jun 06 09:16:12 ok Jun 06 09:18:49 ldir: congratz on your patches :) Jun 06 09:19:38 good to know I can officially point my RCU questions to you know ;-) Jun 06 09:20:34 mangix: that PR looks fine to mer Jun 06 09:20:50 mangix: merged it Jun 06 09:20:55 thanks for the heads up Jun 06 09:25:10 xback: as long as you don't mind copy/pasted answers...'cos that's what I did with the code :-) Jun 06 09:25:53 the kernel space has been accepted. The user space not yet but has been through a few review rounds and the obvious nasty edges taken off. Jun 06 09:27:23 now gone quiet whilst I guess David Ahern catches up/thinks - but I've resolved issues pointed out by Steven Shemminger who was always quick to jump on stuff he didn't like so I'm trying to be patient and hopeful. Jun 06 09:30:25 ahh bummer my last step doesn't work :( Jun 06 09:31:00 andy2244: fixed Jun 06 09:42:14 oh dear - looks like I broke the build Package kmod-sched is missing dependencies for the following libraries: nf_conntrack.ko Jun 06 09:43:18 I'll revert 'cos I have to go out and can't fix *now* Jun 06 09:46:06 reverted Jun 06 10:14:44 ynezz: is that patch still relevant? -> https://patchwork.ozlabs.org/patch/1007625/ Jun 06 10:15:55 last email from ynezz seems to imply it's dead. Jun 06 10:16:21 hello Jun 06 10:18:18 KanjiMonster: yes, it should be, @chunkeey has confirmed to me, that he was experiencing the same problem Jun 06 10:18:46 karlp: see? that's why I'm asking first ;P Jun 06 10:20:24 well, it doesn't fix any real world error which could be caused by for example any package in the tree currently Jun 06 10:20:58 I was able to hit it only by compiling the libgpiod from Git, not from the release tarball Jun 06 10:23:33 don't know if this is good enough reason to merge it Jun 06 10:24:27 I'll probably include it in my staging tree for some time and if I don't hit any issue, then I'll simply push it? Jun 06 10:25:38 maybe test it with packages that use the autoreconf FIXUP (I assume that's the touched code?), to check for build regressions? Jun 06 10:28:07 sounds like a plan Jun 06 10:28:48 great Jun 06 10:35:04 is that possible (using blobmsg) to add anything to nested objects? Jun 06 10:35:11 let's say I have: { "admin": { "id": 0 }, "user": { "id": 3 } } and I want to have "name" next to the "id" Jun 06 10:35:23 i wish to do sth like blobmsg_for_each_attr(cur, b->head, rem) { blobmsg_add_string(b, "name", "Rafal"); } Jun 06 10:37:22 rmilecki: modifying a blob_buf while you're iterating over it is very unsafe Jun 06 10:37:25 don't do that Jun 06 10:37:56 is there any other/working/safe way? Jun 06 10:38:27 use a new buffer and move the data over while modifying it where necessary Jun 06 10:38:31 blobmsg_open_* seems to be always creating new property, I can't use it for opening existing one Jun 06 10:39:16 blobmsg_add_* operates on a growing linear memory buffer Jun 06 10:39:33 ok, I see Jun 06 10:39:38 so adding something in the middle would involve some more complex logic with lots of memmove Jun 06 10:39:58 understood, thanks Jun 06 10:41:04 taking that into account, using a new buffer will be faster anyway Jun 06 11:17:54 hrm, I'm hitting a race condition when trying a build with -j8 and per device rootfs, it runs package/install far too early, then complains about missing packages not yet build Jun 06 11:21:16 indeed, I wasn't able to reproduce it reliably, so hard to fix, so I've ended with the workaround, using the same approach as on the buildbots `make defconfig prereq tools/install ...` and moved on Jun 06 11:22:46 rmilecki: any luck with urngd? Jun 06 11:28:54 ynezz: I can currently reproduce it with 100% reliability ;) Jun 06 11:30:25 lucky you Jun 06 11:38:32 now if I only knew how to debug (and fix) it ... Jun 06 11:42:49 sometimes `make -d` helps Jun 06 11:43:25 in some cases I've found remake useful Jun 06 11:56:13 oooh Jun 06 11:56:17 actually the issue isn't that Jun 06 11:58:02 the issue is that appearently CONFIG_ALL with ath79 created an invalid config for me Jun 06 12:01:32 PROVIDES seem to break dependencies in menuconfig - having kmod-cfg80211=y (depends on iw) with iw=m and iw-full=m is allowed by menuconfig, and the default result for ALL Jun 06 12:03:44 help for PACKAGE_iw says "Selected by: PACKAGE_kmod-cfg80211 [=y] && y && !PACKAGE_iw-full [=m]", the latter probably should be "&& !PACKAGE_iw-full=y" Jun 06 12:04:18 nothing to do with per device rootfs Jun 06 13:26:05 * ldir is back Jun 06 13:27:27 I think I've spotted what I did wrong in the act_ctinfo backport - it looks like I should have added act_ctinfo to SCHED_MODULES_FILTER in netsupport.mk Jun 06 13:28:14 anyone able to confirm/deny this thought ? Jun 06 13:31:39 that guess is based on the fact that act_connmark has similar functionality/dependencies and it is included in the sched_modules_filter Jun 06 13:32:02 if unsure, try it :) Jun 06 13:33:01 I'm 99% sure but I didn't see the buildbot error and am unsure how to re-create. Jun 06 13:34:42 use the same config.seed Jun 06 13:35:43 curl http://downloads.openwrt.org/snapshots/targets/ar71xx/generic/config.seed > .config; make defconfig Jun 06 13:37:15 it's probably CONFIG_ALL_KMODS=y that triggers it Jun 06 13:40:27 ok, I'll give those a try :-) Jun 06 14:32:09 hmm, I think I'm just going to have to submit it to a buildbot and pray - building on macos with a buildbot config errors on packages. Jun 06 14:32:30 ynezz: it's clunky, but it seems to work -> https://pastebin.com/EJ7p64ji Jun 06 14:36:35 KanjiMonster: sorry, I'm perlblind Jun 06 14:37:03 ynezz: that's why I included the examples at the bottom ... I probably should have included the befores ... Jun 06 14:37:54 haha perlblind, good one Jun 06 14:39:16 ynezz: here, now with a "diff" of the generated kconfig ;) https://pastebin.com/0n3vH0Ah Jun 06 14:40:14 y&&y :) Jun 06 14:41:02 the issue before is that for !PACKAGE_iw-full is true also if iw-full is only =m, so if iw-full is =m, iw wouldn't be selected even if kmod-cfg80211 =y Jun 06 14:41:16 y alone means this symbol is y Jun 06 14:43:52 (in theory kconfig also supports >=, >, < and <=, but these either produced syntax errors or weird side effects) Jun 06 14:46:10 and *poof* another afternoon gone with debugging/fixing a completely unrelated issue to what I actually wanted to do Jun 06 14:47:15 * ldir knows that situation well Jun 06 14:48:12 yep Jun 06 15:02:45 anyone know if neighbor report requests are considered robust (in that they should be encrypted when pmf is enabled)? Jun 06 15:04:10 KanjiMonster: there's no need for "...".$_."...", can simply write "...$_..." Jun 06 15:04:35 or ${_} if what follows happens to be an alphanumeric char Jun 06 15:05:05 jow: I just followed the style that was already there, I'm not very perliterate Jun 06 15:05:48 fair enough, but the very same line already does direct interpolation ("$condition && ") Jun 06 15:05:58 so I see no reason to not do it for $_ as well Jun 06 15:06:45 "(PACKAGE_${_}=y&&y||PACKAGE_${_}=m)" or "(PACKAGE_$_=y&&y||PACKAGE_$_=m)" looks cleaner to me Jun 06 15:07:12 sorry for the bikeshed Jun 06 15:07:53 * ldir suggests KanjiMonster raises him a bus shelter and see who blinks first ;-) Jun 06 15:09:16 jow: nah, it's fine. seems to work fine, so I'll use that :) Jun 06 15:17:19 blogic, you worked on the ath10k eth-tx type, instead of native-wifi, right? While poking around, I notice there is a memmove in ath10k_tx_h_nwifi. Maybe that is why nwifi is so much slower? Jun 06 15:32:22 ok Jun 06 15:39:50 where does the date/time in "uname -a" output come from? Jun 06 15:40:14 I thought it was when the kernel was built, but I've got a timestamp of may 21, at 7:48am, for an image I just built. Jun 06 15:40:44 probably because your kernel wasn't rebuilt Jun 06 15:40:59 I ran "make clean" between each one. Jun 06 15:41:37 and i would never hvae been building at 7:48am. Jun 06 15:42:26 the vmlinux file is dated jun 6, 15:32, so. "right now" Jun 06 15:42:47 ah right, that's probably the "reproducible build" logic kicking in Jun 06 15:43:26 hrm, sounds very plausible. Jun 06 15:44:26 got time for maybe one more rebuild run today... Jun 06 15:45:40 so far, 4.9.167, 170, 172, 173, 174, 175 and 176 all reboot correctly, and 177, and 179 all hang on reboot, ever single time on two instances of the same device. Jun 06 15:46:17 ynezz:177 includes the ath79 perf irq change, it's the only thing I can think of that even looks remotely close to maybe relevant. Jun 06 15:47:31 karlp: the datestamp in uname should be derived from the commit time of the topmost git commit Jun 06 15:47:48 (which is used as value for SOURCE_DATE_EPOCH) Jun 06 15:48:11 jow: that's still only May 17 14:34:09 2019 +0200 though. Jun 06 15:48:25 not May 21 07:48:48 2019 Jun 06 15:48:45 (from top of git log at least) Jun 06 15:50:48 karlp: and if you revert that commit, then it works? Jun 06 15:51:47 karlp: if thats the case then there must be something fishy in that kernel version not playing well with that change Jun 06 15:51:53 that's what I'm doing now, just wondeing if you saw anything else whil you were looking at it. Jun 06 15:52:12 I'm 4.14+, sorry Jun 06 15:53:56 anyway, it was ath79 which had a problem with perf tools, that was the reason for the patch initially Jun 06 15:54:35 it was working fine ar71xx, so maybe ar71xx needs some adjustments now Jun 06 15:56:21 so, flashing these devices with my ath79 builds they reboot just fine. Jun 06 15:56:29 so yay, the future is safe at least :) Jun 06 15:57:02 can you install perf and try perf top on ar71xx? Jun 06 15:57:33 yeah, next step. gonna build without this first. Jun 06 15:57:47 in the past I've have problems even building perf, let alone running it. Jun 06 15:58:29 well, opkg install Jun 06 16:11:54 * ldir yay! buildbot has built at least 1 target with my patch Jun 06 16:12:24 yay! Jun 06 16:12:40 my build pipeline is working too :) Jun 06 16:13:16 I lie... 3 targets! and a fanatical devotion to the pope Jun 06 16:13:18 guess I need to figure out how scripts/env works to integrate it, so I can build for more than just rpi Jun 06 16:14:07 and custom feeds via env sounds very handy for this as well :) Jun 06 16:16:02 right, 4.9.177 without the ath79 perf irq patch reboots too. Jun 06 16:16:17 do you want me to try "perf top" on ,... which versions? before, after something else? Jun 06 16:17:29 and there it is https://downloads.openwrt.org/snapshots/targets/layerscape/armv7/kmods/4.14.123-1-008d72fd9a412f0a357e3c4e7b147027/kmod-sched-ctinfo_4.14.123-1_arm_cortex-a7_neon-vfpv4.ipk all 4.5K of it. Jun 06 16:18:20 ldir: does this module do anything on its own, without userspace config ? Jun 06 16:22:02 stintel: no. Jun 06 16:23:12 I have a tc userspace update sat here, wasn't going to push that until I was happy the kernel module patch built ok. Jun 06 16:27:42 stintel: I was hoping the tc patch would also have got more of a go/no go from upstream iproute2-next by now. Jun 06 16:32:36 stintel: they've stopped saying 'improve this, do that' - now it has gone quiet- which I take as a positive thing. Jun 06 16:35:32 ok. from a quick glance, this sounds like something useful on home internet connection in combination with sqm Jun 06 16:39:20 I couldn't possibly comment ;-) Yes, exactly that. Jun 06 16:40:27 ynezz: perf top runs on my 4.9.177-minus your patch. I'll rebuild plian 177 _with_ your patch and perf, are you expecting it to fail or something else? Jun 06 17:02:15 karlp: is this ar71xx ? Jun 06 17:05:45 yeah. Jun 06 17:06:00 on 1806 branch. ath79 on master reboots just fine. Jun 06 17:06:14 haven't tried ar71xx on master, not a future path (for me at least) Jun 06 17:18:03 WARNING: previous mirror push of repo 'openwrt/staging/stintel' to host 'git-02' failed, status is: Jun 06 17:18:07 2019-06-05.04:29:28 26230 FATAL: W any openwrt/staging/stintel server-lede DENIED by fallthru Jun 06 17:18:12 hmmz Jun 06 17:23:47 ynezz: "perf top" runs with and without your patch, but with it, reboot hangs. I'm out for the day, I can do any more testing tomorrow, I don't have any other leads on what to do though. Jun 06 17:30:32 I didn't think ynezz perf related interrupt alloc'n patch even touched ar71xx - it was for ath79 only. Jun 06 17:32:31 karlp: which patch/commit are you looking at? Jun 06 18:52:29 hi, does the enviroment of include/image.mk has any json handling methods available? Jun 06 18:53:08 Lantiq XWAY XRX 200 VDSL chip Jun 06 18:53:08 Driver commands Jun 06 18:53:08 I Want to force disable interleave and G.INP Jun 06 18:53:11 help plz Jun 06 18:53:16 maybe jshn.sh? Jun 06 18:53:50 Reaper_2077: maybe the forum has some information available? Jun 06 18:54:07 Checked it Jun 06 18:55:24 didnt find answer Jun 06 18:55:28 I lokked and Jun 06 18:56:00 Mediatek vdsl chip on ZTE H168N has command that in some configurations succeeds in forcing fast path Jun 06 18:56:08 Looked on the net* Jun 06 18:56:20 I have lantiq based Jun 06 18:56:32 I dont know the way Jun 06 20:31:27 karlp: I've checked this and think, that the problem with 18.06/4.9 is, that it's still using legacy IRQ arch/mips/ath79/irq.c but master/4.14 is using irqchip drivers (commit 51fa4f8912c0934cf1410f435516d2abbcf88a9e) Jun 06 20:34:50 but master/4.14 is still using backported/pending stuff from 5.1 Jun 06 20:38:12 in other words, this perf fix patch should be reverted from 4.9, 4.14, 4.19, 5.0 stable kernels, but I've no clue how it get there, as I didn't Cc: stable Jun 06 20:38:31 ah, [PATCH AUTOSEL 4.9 18/25] MIPS: perf: ath79: Fix perfcount IRQ assignment Jun 06 20:39:38 I recall that there were, at least at one tome, persistent kmod archives for snapshots -- are they still around? Jun 06 20:40:06 NM, found the post Jun 06 20:42:49 ldir: ar71xx/ath79 share same arch/mips/ath79 core Jun 06 21:05:26 ynezz: commits also get backported if they have a Fixes: tag (sometimes even if -stable is not Cc'ed) Jun 06 21:07:40 xdarklight: it didn't have either a1e8783db8e0d58891681bc1e6d9ada66eae8e20 Jun 06 21:08:44 AUTOSEL. Looks like the neural network backported a patch it should not have Jun 06 21:09:21 ynezz: indeed. reply to their backport email and explain why it shouldn't be backported and from which versions it should be reverted. the -stable guys are quick at sorting this out if they know about the breakage Jun 06 21:16:28 xdarklight: will do, thanks **** ENDING LOGGING AT Fri Jun 07 02:59:57 2019