**** BEGIN LOGGING AT Thu Jun 25 02:59:57 2020 Jun 25 04:13:14 build #420 of layerscape/armv8_64b is complete: Failure [failed kmodconfig] Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv8_64b/builds/420 blamelist: Natalie Kagelmacher , Hans Dedecker , David Bauer , Sungbo Eo Jun 25 05:23:24 test 1 2 Jun 25 05:29:16 3 Jun 25 06:04:14 thinking of buying a Xiaomi's AX3600 Jun 25 06:29:24 infradead going down was weird, i see they've redone some of their archives Jun 25 06:29:30 not for openwrt tho Jun 25 06:46:24 wilson3757: what SoC is in that xiaomi Jun 25 06:46:26 ? Jun 25 06:46:56 qualcomm arm64 4 core Jun 25 06:50:34 IPQ8071A Jun 25 06:51:11 wilson3757: i think it's WIP, the mailing list Jun 25 07:10:36 Borromini: calling it work in progress is imho a bit early at this stage. yes, there is the initial ipq807x target support for ipq8074, but that's still rather incomplete. yes, ipq8071 is interesting and comes at a tempting price. yes, several regular contributors have expressed their interest in the xiaomi ax3600 (respectively ordered it) Jun 25 07:14:19 but there are no patches in flight, nor anyone known to work it yet, nor did the device get delivered so far. yes, there are some early users investigating the ax3600 and ax1800, including serial console access and decoding the root password, but I wouldn't go as far as calling that active porting work yet Jun 25 07:17:36 it's likely to get supported, but no ipq807x consumer device has seen tangible progress, akin to anything like 'patches', so far Jun 25 07:18:47 slh64: i literally said 'the mailing list' Jun 25 07:19:13 it being a WIP Jun 25 07:22:07 it may be a question if varying definitions, but for me personally, the term WIP would at least involve someone having booted an initramfs image, even if x, y and z were still non-functional, but the progress isn't at that stage, yet Jun 25 07:23:06 slh64: yeah it looks likepeople are confident , the thing should be fast enough to not have to care about network accelerator support Jun 25 07:23:48 ipq8074 is damned fast, ipq8071 remains to be seen Jun 25 07:24:54 but ipq8071 is the only affordable entry into ipq807x at this point Jun 25 07:27:32 build #414 of archs38/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/archs38%2Fgeneric/builds/414 Jun 25 07:30:14 I'm not seeing IPQ8074 being any faster than, say, an AMD GX-412TC (on the PC Engines systems). Jun 25 07:33:08 2-wide superscaler, 8-stage pipeline, in-order, dual-issue (on some instructions only)… sure, it's running at 2 GHz, but it's not doing much per clock. Jun 25 07:34:37 rsalvaterra: QCA has the better marketing bureau of course. Jun 25 07:34:47 and ARM is cool now. Jun 25 07:35:46 Besides, it's 64-bit ARM, so all instructions are 32 bits wide. The cache won't be happy at all. Jun 25 07:35:57 vulnerabilties been found for arm64 lately, patches to glibc and gcc Jun 25 07:35:59 would be neat to see Ryzen embedded systems we can buy Jun 25 07:36:14 rsalvatera: the gx-412tc is a bad/ too old example, it can do routing at 1 GBit/s wirespeed, but just barely. it's totally at its limit there. the ipq8074 hk01 devboard comes with two 10GBASE-T interfaces - and actual consumer devices ship with one 2.5- or 5 GBit/s interface, so yes, ipq8074 is faster (especially if it can do NSS/ NPU offloadingl Jun 25 07:37:01 wilson3757: I don't think the Cortex-A53 is affected, being in-order. Jun 25 07:37:56 slh64: can you make cake work with the NSS processor? No? In that case, it doesn't exist. :P Jun 25 07:37:57 https://www.phoronix.com/scan.php?page=news_item&px=ARM64-Linux-5.8-BTI-SCS Jun 25 07:38:40 that's probably the wrong link Jun 25 07:39:07 https://www.phoronix.com/scan.php?page=news_item&px=Arm-Straight-Line-Speculation Jun 25 07:40:11 cake, probably not, but the NSS firmware has QoS support, it's probsbly not on par with cake though - but the apu2 won't di caje at 1 GBit/s linespeed either, nor can it support 802.11ax Jun 25 07:40:20 wilson3757: Exactly, the A53 doesn't execute speculatively. It's in-order. Jun 25 07:42:07 slh64: Not being able to cake-shape at 1 Gb/s is a problem I'd love to have. Jun 25 07:42:11 good news on that front then Jun 25 07:42:30 the apu2 doesn't do much more than 200Mbps with cake, iirc Jun 25 07:42:33 do not get me wrong, I don't underestimate x86_64 at all, but the gx-412tc in particular is old and not really competing (the situation would be totally different for more recent amd or intel CPUs, not necessarily highend either) Jun 25 07:42:52 so if I'm upgrading tot 1000/1000 I'll have to find a new router Jun 25 07:44:16 stintel: Even my Archer C6 v2 shapes at 200/20 Mb/s. Sure, I can't even SSH into it, but it does it, barely. Jun 25 08:04:12 Ho-hum. I just noticed zstd isn't available to zram. And also doesn't appear on the OpenWrt configuration (library/crypto sections of the kernel modules). Cute. Jun 25 08:23:11 it's still pretty new isn't it Jun 25 08:25:23 Hmm… The relevant part (crypto API integration) is over two years old. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/crypto/zstd.c?id=d28fc3dbe1918333730d62aa5f0d84b6fb4e7254 Jun 25 08:25:59 So, from the master-supported kernels, that means only 4.14 is out. Jun 25 08:26:16 what can i say :D. I learned about zstd just a few weeks ago myself. Jun 25 08:27:37 Borromini: I don't blame you, compression is usually boring. But zstd is very interesting, since it's both very fast and compresses as well as zlib. Jun 25 08:27:48 yes i've read up on it a bit Jun 25 08:28:44 For the poor sod with a 32 MiB router, it could make a huge difference. Jun 25 08:30:35 And I never thought I'd live to qualify as "very interesting" something coming out of Facebook. :P Jun 25 08:36:47 hey, what can i say Jun 25 08:36:58 we've seen microsoft endorse linux, contribute to the kernel Jun 25 08:37:03 strange times we live in eh :D Jun 25 08:41:14 Oh, dear…! And zram expresses a strict dependency on lz4, which also doesn't make sense (it only depends on lzo). Jun 25 08:41:56 I guess I'll bite the bullet and try to disentangle this mess… Jun 25 09:45:58 jow: hey, currently sven is doing a PR (since 1 year) to change the luci.mk. As he patched the freifunk berlin firmware with it, the packages are not building with normal image builder (they are just empty). Since my plan is to build our software with image builder on openwrt master branch, this is a very blocking fact. I made a PR reverting that. Could u say something to this, if u want to merge this PR or not and Jun 25 09:45:59 when? If it takes more than a month I would be adamant that the stuff is reverted temporarily. Jun 25 10:04:26 nick[m]1: I don't really like the luci.mk change tbh Jun 25 10:04:58 nick[m]1: if you want to use a reduced variant in the freifunk feed, you could simply ship an own copy of it, that would also avoid a cross-feed dependency Jun 25 10:09:48 jow: okay. could u maybe be honest to sven and say that this will not be merged? :S I want to stay compatible with openwrt master and shipping my own luci.mk seems like forking into a direction that will cause problems in 1 or 2 years... I don't understand why is is so important for him to change the luci.mk, or why he cares so much about it. :/ For me it is really unimporant since I just make use of it and I will Jun 25 10:09:48 change my luci-app to be aligned with the newest luci.mk... Jun 25 10:10:04 jow: btw thanks for your answer Jun 25 10:13:54 jow: to make it complete, here is the discussion: https://github.com/freifunk-berlin/firmware-packages/pull/207#issuecomment-649030851 Jun 25 12:01:27 Alright, I think I've got it Jun 25 12:01:33 root@heimdal:~# cat /sys/block/zram0/comp_algorithm Jun 25 12:01:34 lzo [lzo-rle] Jun 25 12:01:34 root@heimdal:~# Jun 25 12:01:41 No lz4, yay! Jun 25 12:13:36 awesome. I've got a lua gc issue with uloop Jun 25 12:15:58 karlp: there's only so much weirdness I can handle… :P Jun 25 12:16:20 working: https://paste.centos.org/view/b5667a66 Jun 25 12:17:56 not-working: https://paste.centos.org/view/e31ef519 log of not working: https://paste.centos.org/view/e2d03e71 Jun 25 12:18:09 only difference is moving stuff from "main" to a function Jun 25 12:18:25 it's like the closure/upvalue or something isn't being capture properly across the C api Jun 25 12:19:51 Wait, inotify? If you're watching for files, shouldn't you be using fanotify? Jun 25 12:20:39 kinda not the point, also, from man fanotify "no support for create.... events" Jun 25 12:21:19 also, inotify bindings exist Jun 25 12:25:28 I have a workaround. yay: https://paste.centos.org/view/bd35d471 Jun 25 12:25:39 I hate it :) Jun 25 12:32:28 karlp: looks like your event handle fd goes out of scope and gets finalized and garbage collected Jun 25 12:32:49 you need to plug it into some registry, e.g. a weak table Jun 25 12:33:14 it's the userobject returned from fd_add that goes out of scope Jun 25 12:33:21 yes Jun 25 12:33:39 but I cna't _do_ anything with that as a user, so it was not at all obvious that I needed to keep it. Jun 25 12:33:58 you can uzse it to remove it from the loop again I guess? Jun 25 12:34:05 there's no method for doing so., Jun 25 12:34:14 other than somehow letting it become garbage collected Jun 25 12:34:16 so it seems a Lua wrapped struct uloop_fd Jun 25 12:34:18 but = nil won't do that. Jun 25 12:34:59 or, if I read the code enough, is there a :delete method on it that's not visible Jun 25 12:36:01 yes, it has a metatable assigned with a :delete() method Jun 25 12:36:08 https://lxr.openwrt.org/source/libubox/lua/uloop.c#L222 Jun 25 12:36:42 assigned to the userdata here: https://lxr.openwrt.org/source/libubox/lua/uloop.c#L259 Jun 25 12:37:06 I can see why it behaves the way it dos now, but it still feels likea "you're not holding it properly" failure :| Jun 25 12:38:31 when you said, "store it in a weak table" what did you mean? Jun 25 12:39:18 sorry, you need a normal table Jun 25 12:39:47 a weak table does not increases the refcount of its items, so they're still subject to garbage collection Jun 25 12:39:57 but here you want the opposite, you do want to keep holding a ref Jun 25 12:40:09 what's a weak table though? Jun 25 12:40:18 https://www.lua.org/pil/17.html Jun 25 12:42:04 oh, I've never ever wanted to look a tthat sort of thing, seemed like a way of helping to optimize the gc, Jun 25 12:42:21 just keeping it as a global works. Jun 25 12:42:26 righr Jun 25 12:42:28 *right Jun 25 12:43:03 this has taken way too long. because it was from the gc, I was getting realyl inconsistent behaviour trying to run it locally Jun 25 12:43:22 finally figured it out by my patched with debug uloop on the device itself, Jun 25 12:43:39 locally would sometimes fail, sometimes not, and never with debug turned on :| Jun 25 13:31:13 jow: could u have a short look at this? https://github.com/freifunk-berlin/firmware/issues/821 Jun 25 13:31:26 jow: it is about uci:get with a whole path and permissions Jun 25 13:33:20 jow: am I right or is this a bug of luci uci itself? Jun 25 13:39:46 nick[m]1: no, looks like this code was always broken Jun 25 13:40:28 Does anyone know how much RAM the sysupgrade switch to the ramdisk actually uses? Jun 25 13:41:03 jow: thank u! just wanted to know if that is correct what I claim Jun 25 13:41:24 nick[m]1: it has nothing to do with permissions though Jun 25 13:41:47 the first argument to get() or get_first() should be a "package name" which is the filename of the /etc/config/* file Jun 25 13:41:52 it must not be an absolute path Jun 25 13:42:59 Afternoon jow, hi nick[m]1 Jun 25 13:44:20 Grommish: hi? ;) Jun 25 13:44:46 jow: thank u! u are right, even if I give '*' permission it does not work. Jun 25 13:44:49 nick[m]1: hah I just usually don't see activity here Jun 25 13:46:05 I'm trying to see how much RAM sysupgrade uses when it switches to the RAMdisk. I've got an 800MB host image I have to load and flash and I'm not sure how much I have left during the upgrade Jun 25 13:49:12 jow: You were the person who wrote the freifunk berlin landing page, or? xD Now I have to fix your bugs 12 years later. xD Jun 25 13:50:41 nick[m]1: first, I was Freifunk Leipzig, not Berlin. And second, the profile stuff was not made by me ;) Jun 25 13:54:46 jow: Maybe u want to join freifunk berlin? ;) I need help to port everything to new luci version. :P Freifunk Leipzig joined team gluon, or? Jun 25 14:04:53 I guess so, haven't been active in years Jun 25 14:05:56 Finding a package maintainer in OpenWrt is… "fun". :P Jun 25 14:06:19 Can be.. Which one? Jun 25 14:07:06 Who maintains the ./package/kernel/linux/modules dir? Jun 25 14:07:46 * rsalvaterra looks at jow Jun 25 14:08:34 rsalvaterra :D Jun 25 14:10:27 nbd168 on Github Jun 25 14:10:35 https://github.com/openwrt/openwrt/commits/openwrt-19.07/package/kernel/linux/Makefile Jun 25 14:10:49 Can try there Jun 25 14:11:19 Granted, i realize you are being retorical :D Jun 25 14:12:33 From the activity history, I'd say it's most likely Petr or Hauke (or both). Jun 25 14:13:30 Isn't the real solution to submit a patch? Jun 25 14:14:11 or an "RFC patch" Jun 25 14:16:10 Sure, ldir, but I like to keep the --to list short. Or should I send the patch to the mailing list only? Jun 25 14:18:07 just send it to the mailing list - I've never directed patches specifically - I've taken maintainer as a hint rather than absolute, especially in the main repo. packages repo it has a bit more focus. Jun 25 14:18:55 Ok, will do, thanks for the tip. :) Jun 25 14:19:45 They're automagically picked up by patchwork, anyway. Jun 25 14:25:29 I guess I've been spoiled by the get_maintainer.pl script from the kernel… Jun 25 14:25:52 we even dropped target maintainers recently Jun 25 14:26:21 https://git.openwrt.org/9ba09653 Jun 25 14:27:36 stintel: Less cathedral, more bazaar. I like it. :P Jun 25 14:28:09 occasionally bizarre as well Jun 25 14:28:28 LOL Jun 25 14:29:22 Oh, I remembered, have you started watching the AGC restoration videos? Jun 25 15:09:44 jow: heh, was trying to tidy/enhance the argument checking in fd_add, and using absolute instead of relative indicies for the arguments, so they don't move around. the "get_sock_fd" helper doesn't work properly on an absolute index, only on the relative one :) Jun 25 15:11:39 you mean the stack indixes for the function args? Jun 25 15:13:27 yeah, I think I've got a fix for it to accept both. Jun 25 15:13:36 eyah Jun 25 15:14:35 https://paste.jvnv.net/view/TMPhx Jun 25 15:16:54 ah, that looks ... dnagerous somehow Jun 25 15:17:01 what about lua_gettop() ? Jun 25 16:31:42 Trying to wrap my head around how to express conditional dependencies (on specific kernel versions), in the modules' makefiles… :/ Jun 25 16:34:14 For example… Jun 25 16:34:14 DEPENDS:=@!(LINUX_4_14||LINUX_4_19) +kmod-nls-base Jun 25 16:34:14 … means the module depends on kmod-nls-base if the kernel version isn't either 4.14 or 4.19, right? Jun 25 16:37:14 jow: any idea why the dispatcher should say " Unable to dispatch: /cgi-bin/luci/freifunk "? Jun 25 16:37:36 although I remove everything and only have an empty function Jun 25 18:48:55 rsalvaterra: no, it means it always depends on kmod-nls-base and on a kernel not being version 4.14 or 4.19 Jun 25 18:49:12 so it will not be available on 4.14 or 4.19 Jun 25 19:07:40 jow: Great, thanks! Jun 25 19:08:36 So, something like this… Jun 25 19:08:40 DEPENDS:=+!LINUX_4_14:kmod-crypto-acompress Jun 25 19:09:49 … does it mean kmod-crypto-acompress is a dependency if the kernel version isn't 4.14? (It's what I'd like to express.) Jun 25 19:24:46 rsalvaterra: yes, only depend on kmod-crypto-acompress if the kernel is 4.14 Jun 25 19:25:51 Nice! Thanks a lot! Jun 25 19:27:04 Trying to promote zstd to a first-class citizen. :P Jun 25 19:28:19 (The problem is that zstd isn't supported by the crypto API on Linux 4.14.) Jun 25 19:28:27 I guess you want to express a kernel X or later dependency Jun 25 19:28:42 so better blacklist all too old kernels to make it future-safe Jun 25 19:28:55 Right now, this is my diff… Jun 25 19:28:58 define KernelPackage/lib-zstd Jun 25 19:28:58 SUBMENU:=$(LIB_MENU) Jun 25 19:28:58 TITLE:=ZSTD support Jun 25 19:28:58 + DEPENDS:=+!LINUX_4_14:kmod-crypto-acompress Jun 25 19:28:58 KCONFIG:= \ Jun 25 19:28:59 + CONFIG_CRYPTO_ZSTD \ Jun 25 19:28:59 CONFIG_ZSTD_COMPRESS \ Jun 25 19:29:00 CONFIG_ZSTD_DECOMPRESS \ Jun 25 19:29:00 CONFIG_XXHASH Jun 25 19:29:01 - HIDDEN:=1 Jun 25 19:29:01 FILES:= \ Jun 25 19:29:02 + $(LINUX_DIR)/crypto/zstd.ko@ge4.19 \ Jun 25 19:29:02 $(LINUX_DIR)/lib/xxhash.ko \ Jun 25 19:29:03 $(LINUX_DIR)/lib/zstd/zstd_compress.ko \ Jun 25 19:29:15 yes, right Jun 25 19:29:25 Aw, crap. It's considered flooding. Sorry about that. Jun 25 19:31:02 Here it is: https://0bin.net/paste/+CAqsol5+IomdSzb#ee7BGQl3BL5GYZz+TYLlcQTiUQOIYNr6s56o4br+e6K Jun 25 19:50:23 Oh, wait. If the kernel version is, or isn't 4.14? I want kmod-crypto-acompress to be a dependency only if the kernel version *isn't* 4.14 (and assuming the next nearest version is 4.19, which it seems to be). Jun 25 19:56:33 exclamation mark negates Jun 25 19:56:51 +!LINUX_4_14:foo - select foo if kernel is not 4.14 Jun 25 19:57:05 +LINUX_4_14:foo - select foo if kernel is 4.14 Jun 25 19:59:31 That was my expectation too, but wrote "yes, only depend on kmod-crypto-acompress if the kernel is 4.14", so that threw me off. :D Jun 25 20:13:28 ynezz you send me some of your development scripts the other day, do you also have something to run the musl builds directly on a x86/64 debian host? Jun 25 21:41:40 jow: not sure why it would be dangerous? (I can't see my patches on the list, will retry that tomorrow) Jun 25 21:42:47 the old get_sock_fd did a pushvalue(idx -1) , which only worked if idx was a negative (relative) index, to accoutn for the getfield which pushes on to the stack. Jun 25 21:43:05 if you gave it an absolute position, it wasn't moving, and the idx -1 was then wrong. Jun 26 01:54:56 build #421 of layerscape/armv8_64b is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv8_64b/builds/421 **** ENDING LOGGING AT Fri Jun 26 03:01:39 2020