**** BEGIN LOGGING AT Fri Jun 14 02:59:58 2019 Jun 14 06:26:05 tmn505_: I've two 4.19 related fixes for tegra queued in my staging tree, could you please check it? Jun 14 06:30:04 Hauke: we're now preparing switch to 4.19 https://pad.riseup.net/p/openwrt-4.19 and I've some 4.19 related fixes queued in my staging tree, could you please check it once you've a minute? Jun 14 07:02:14 i want to decrypt shc compiled shell scripts. the scripts are on MIPS architecture Jun 14 07:02:47 unshc.sh does not work for me Jun 14 08:04:34 *yawn* Jun 14 08:32:04 heh great. the dahdi 3.0.0 bump would fix 4.19 but break 4.14 Jun 14 08:32:06 le sigh Jun 14 08:32:29 oh well, all the more reason for people to bump their favorite target to 4.19 ;) Jun 14 08:33:04 oh dear. I suddenly remember what a pita it was to bump brcm2708 to 4.14 Jun 14 08:33:40 I wish I'd had time but more so expertise to pull off such stunt so that openwrt devs would accept it too :p Jun 14 08:34:17 stintel: a cluchy workaround would be to mark it as non-shared and select a version based on the kernel version Jun 14 08:35:09 olmari: just give it a try, we can comment if something is not OK, we can assist if you have questions, ... Jun 14 08:35:17 and once you've done it, it's easier to do it again ;) Jun 14 08:36:27 One Hacklav summit finland 2019½ first (: Jun 14 08:36:41 Hacklab* Jun 14 08:52:24 KanjiMonster: thanks for the hint. are you referring to a specific commit? Jun 14 08:52:25 stintel: in the converse direction, we should probably drop 4.19 from openwrt-4.19 - it will get out of sync with master fast, and probably never bumped, so people shouldn't even try to use it Jun 14 08:52:59 xback: https://git.openwrt.org/f96fbf03281a69dc48cfea90044b21e30c15b7c7 Jun 14 08:53:47 KanjiMonster: thanks, will do in the future :) Jun 14 08:54:22 xback: sure, thanks. It's just a minor thing, so no big deal if missed :) Jun 14 08:55:07 i'll check to fix the marvell stuff asap .. got a bit overloaded at work the past few days .. Jun 14 08:56:07 xback: removing 4.19 from openwrt-19.07 is probably also in your interest ;) Jun 14 09:02:04 KanjiMonster: yeah, I noticed kernel-version was missed in this one: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=000d400baa0af2e42c9a462e42df7dc9abde1ec7 Jun 14 09:03:49 xback: ah, lol, didn't know we already did it. that commit never made it to the commits ML, was probably too large Jun 14 09:06:42 I'm confused. that commit drops 4.19 stuff ? Jun 14 09:06:56 ah it's the 19.07 branch Jun 14 09:07:07 * stintel crawls back under a rock Jun 14 09:07:21 stintel: thanks for thr symbol fix Jun 14 09:07:29 xback: you're welcome :) Jun 14 09:07:56 kernel bumping is really getting a lot of work with all the changes and our branches :) Jun 14 09:08:11 my first commit in over a month :/ Jun 14 09:08:22 and upstream is quite aggresive with hard changes the past few weeks .. Jun 14 09:09:39 xback: maybe talk to aparcar[m] - he's going to setup some CI for staging trees iirc. maybe you can work with him to automate your workflow wrt testing kernel bumps Jun 14 09:10:37 going to put meson target on my whiteboard todo. now that we've branched, it's time to add it, directly with 4.19 kernel Jun 14 09:10:55 but last time I worked on it to address comments from the ML, I broke it :P **** BEGIN LOGGING AT Fri Jun 14 09:31:24 2019 Jun 14 10:11:02 Hi all, what exactly does SOFT_FLOAT do? Jun 14 10:18:09 Neighbor11111115: makes the toolchain use floating point operations in software, instead of trying to use fpu instructions (hardfloat), which is several times faster on systems without an fpu (else the kernel would need to handle/emulate fpu instructions, which is very very slow) Jun 14 10:18:30 thanks KanjiMonster :) Jun 14 10:20:38 Neighbor11111115: when possible, it also disables the fpu emulator in the kernel, shrinking it a good chunck Jun 14 10:24:45 very good to know, thanks Jun 14 10:40:04 ynezz: will you reorder the 4.19 bump commit so that it's after all the fixes? Jun 14 10:48:30 yes Jun 14 10:48:41 perfect :) Jun 14 11:38:50 I have an idle question for yall: why do you make building a kernel without modules so hard? (Like the whole config system spins around modules (without option to build it in the kernel), and lots of things are built outside of the kernel tree, etc etc...) Jun 14 11:40:14 bah. [220085.859305] unregister_netdevice: waiting for wan to become free. Usage count = 1 Jun 14 11:40:17 had to reboot my router Jun 14 11:43:17 urjaman: because it is easier to maintain for us this way Jun 14 11:44:10 non-module kernels are of no interest for release targets so they're an unnecessary maintenance burden Jun 14 11:44:47 and afair some modules cannot be made builtin at all Jun 14 11:45:29 despite that; our kmod packaging system can cope with situations where the packaged .ko files are builtin; buildroot will simply generate empty kmod ipk archives then Jun 14 11:45:55 as if i had space for opkg :P Jun 14 11:46:02 you cannot do this through menuconfig though - you'll have to resort to make kernel_menuconfig to override the menuconfig defaults Jun 14 11:46:08 its not primarily about opkg Jun 14 11:46:24 there are offline ways to pack images from pieces as well Jun 14 11:47:16 using kernel_menuconfig plus disabling target opkg + enabling opkg metadata stripping should get you quote far wrt. static kernel Jun 14 11:47:26 wireless drivers will need to be separate though Jun 14 11:47:35 not surte if it is even possible to make wifi drivers builtin Jun 14 11:47:47 context: i'm "re-doing" (because it seems easier, and hopefully i can make it easier to keep in sync) this hack https://github.com/urjaman/openwrt-w268r Jun 14 11:48:02 oh - another important point of making modular kernels: many vendor uboots enforce kernel image size limits which are very tight Jun 14 11:48:17 having builtin modules will most certainly make the vmlinux image too big to boot Jun 14 11:48:34 i had not too many problems using the in-kernel wifi drivers back then :P Jun 14 11:49:20 the thing boots a kernel+initramfs all-in-one had has 2M of flash Jun 14 11:49:34 so yeah i wont hit the size limit of the kernel image, the kernel image is everything that exists :P Jun 14 11:49:48 *and has Jun 14 11:51:12 so anyhow, what exactly do you need that cannot be done with "make kernel_menuconfig" ? Jun 14 11:54:34 the build system needs a bunch of knifing to not try doing any module work (iirc the symtab, and ofc calling the kernel module build) ... and you've added more out-of-kernel modules for things like leds and buttons if i read right ... Jun 14 11:56:13 so why dont you develop things like that in the kernel tree and push them upstream too? Jun 14 11:57:02 urjaman: some of these likely will never be accepted, or were previously rejected Jun 14 11:58:34 or upstream opted for completely different approaches which are either not yet available in the version we use or require significantly more complex / larger infrastructure to use Jun 14 11:59:04 but yeah the point is, once you're trying to squish a system so small that it's just kernel and initramfs in one, modules just make no sense from a size point of view (they take RAM in the filesystem, and then they take more RAM when loaded), and the module loader and such infra also is bloat Jun 14 11:59:24 and some external modules just aren't "ours", so upstreaming them isn't really our job Jun 14 12:02:00 also I'd like to point out that *compressed* kernel image sizes are already creeping over 2 MiB on some targets, without any initramfs included Jun 14 12:03:41 yeah the current build (i havent squished it pretty much at all yet) of the new system is like 2.5M ... and i need it to be within 1664 kB Jun 14 12:09:10 but yeah i'm just kinda doing this for the challenge, just noting that 1. the modules are a source of bloat and 2. building them out-of-tree makes them harder to get rid of (and not expecting much if anything to ever go anywhere except my repos...) Jun 14 12:09:48 building them out of tree makes them easier to mantain for us though Jun 14 12:13:06 also there's stuff like: the package for the mac80211 kernel module ... includes more than just the kernel module Jun 14 12:13:27 (it has the scripts and whatnot to make the wifi go) Jun 14 12:14:02 so if you disable that package (and use the in-kernel mac80211), you need to go and re-add the scripts Jun 14 12:16:58 in a perfect world those scripts could be in some other package that the kernel module package pulled in (and that you could also just put a check in menuconfig instead) but since it wouldnt be of any use to you ... sigh, i guess i'll just copy the script around Jun 14 12:18:52 mostly i'm trying to balance being able to rebase this thing without too many conflicts and 2. the rebase not missing too many things updated in upstream... Jun 14 12:24:00 it likely will get only get harder; IIRC switching from 4.14 to 4.19 was 100k alone (compressed) Jun 14 12:30:14 yeah likely i will not try that (i mean, unless i get more crazy later) Jun 14 13:03:51 heh more Senao CAP4200AG clones Jun 14 13:10:14 but 128/32 Jun 14 13:10:33 jow, quick question. Is resolv.conf the only file that is used for resolving DNS? As you explained the other day, I understand that netifd generates resolv.conf.auto and that resolv.conf links to it. And when dnsmasq is run it removes the symbolic link and generates its own resolv.conf Jun 14 13:11:07 so dns resolving exclusively uses resolv.conf (presumambly this is all done in libc). Is that correct? Jun 14 13:13:30 By DNS resolving I mean local DNS resolving not forwarding, thanks Jun 14 13:24:11 Neighbor11111115: /etc/resolv.conf links to /tmp/resolv.conf (which is generated by the dnsmasq init script), while dnsmasq itself uses /tmp/resolv.conf.auto (which is generated by netifd) Jun 14 13:24:41 dnsmasq doesn't replace the symlink (or touches the persistent filesystem in any other way by default) Jun 14 13:25:43 Neighbor11111115: local libc resolving only uses /etc/resolv.conf as authorative source Jun 14 13:25:55 that happens to be a symlink to /tmp/resolv.conf Jun 14 13:26:35 /tmp/resolv.conf is either a further symlink to /tmp/resolv.conf.auto when no dnsmasq is running or its a plain file populated with just "nameserver 127.0.0.1" when dnsmasq is running Jun 14 13:26:55 Thanks guys, that clears it up for me Jun 14 13:27:02 so with dnsmasq: /etc/resolv.conf -> /tmp/resolv.conf ("nameserver 127.0.0.1") Jun 14 13:27:12 xback: please let me know how you perform tests, hopefully I can automate it Jun 14 13:27:14 without dnsmasq: /etc/resolv.conf -> /tmp/resolv.conf -> /tmp/resolv.conf.auto Jun 14 13:28:15 yup that makes complete sense, thanks! Jun 14 13:29:03 (I think that /tmp/resolv.conf.auto is still a somewhat misleading name... should be resolv.conf.upstream or resolv.conf.netifd or something) Jun 14 13:29:42 or maybe even just /tmp/nameservers.conf Jun 14 13:30:29 well anyhow, there's more important matters to take care of Jun 14 13:40:55 yeah, we already bikeshed proposed stuff enough, no need to also do it to already existing things ;P Jun 14 14:43:59 aparcar[m]: will do somewhere next week. thanks! Jun 14 15:15:59 is teardown supposed to be called when the wireless interface goes from disabled=0 to disabled=1? Jun 14 15:16:11 I assumed it did but it doesn't appear to be doing so now. Jun 14 16:00:38 If anyone wants a minor chuckle at my latest commit message in net-next https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=733f0766c3dea0a92573e38acb62ace3cf4e58c6 Jun 14 16:21:14 ldir: Nice to see honest acknowledgement of prior work! Jun 14 16:27:51 I'd like to think that Dave had a little grin as he applied a straightforward and honest patch :-) Jun 14 16:46:06 ldir: thanks for the link, now I know how this extack works Jun 14 17:36:06 ynezz: I wil have a look at the 4.19 change in the evening Jun 14 17:37:40 haha ldir you type like me! Jun 14 17:38:03 * Tapper hugs ldir Jun 14 17:38:19 It's OK mate you get used to it! Jun 14 18:36:25 cotequeiroz: ping Jun 14 18:51:12 mangix: pong Jun 14 19:02:34 cotequeiroz: I saw a report of kmod-cryptodev breaking OAEP on OpenWrt 18.06 Jun 14 19:03:13 Where is it? Jun 14 19:03:19 https://gitlab.labs.nic.cz/turris/turris-os-packages/issues/398 Jun 14 19:03:46 notice cryptodev_digest_update: illegal inputs Jun 14 19:05:46 jow could you please mirror opkg to github with enabled PRs so I can setup a CI test? Jun 14 19:06:03 cotequeiroz: this is with openssl 1.0.2. I know you did work with 1.0.2 that got lost with the update to 1.1.1 Jun 14 19:06:11 jow also I'd be happy if you could check the license patch Jun 14 19:06:12 Digest support is broken in 1.0.2 as well. It does not handle context copy. Jun 14 19:08:07 I'd say disabling digests is the right thing to do. I'm still trying to fix them in 1.1.1 (https://github.com/openssl/openssl/pull/9051), but I admit I can't imagine where they would be useful. Jun 14 19:09:10 aparcar[m]: not before monday Jun 14 19:09:27 cotequeiroz: is it the same as OpenSSL 1.1.1 (/etc/openssl.conf)? Jun 14 19:09:30 actually not before wednesday next week Jun 14 19:09:38 hopefully Jun 14 19:09:58 jow: ok Jun 14 19:11:26 openssl 1.0.2 cryptodev engine does not support configuration parameters. That was added only in master (future 3.0.0), and I backported the patches here. Jun 14 19:11:29 thanks! Jun 14 19:13:45 It would be harder (not too bad, but not worth to try to cherry-pick) to backport them to 1.0.2, as the engine was completely redone between 1.0.2 and 1.1.1. Jun 14 19:14:27 ah that's unfortunate Jun 14 19:15:14 I would fix this by either disabling digests by default, or never built them. The are many downsides to using an engine for digest. Jun 14 19:16:33 The cost of the ioctl call is too high, and digests are fast in software. Then, there's the problem of context copying. Openssl contexts are kept in user memory, cryptodev stores them in kernel space. Jun 14 19:17:04 where would they be disabled? Jun 14 19:22:05 There is a specific option for them: OPENSSL_ENGINE_DIGEST. I know haproxy used to mistakenly select the symbol, but I don't know if the fix was backported to 18.06 or not. Jun 14 19:26:40 does OAEP fall under digests? Jun 14 19:27:14 hmmm quick google search says yes Jun 14 19:28:47 OAEP uses digests (crypto hashes) Jun 14 19:30:28 haproxy needs a patch to not select unnecessary openssl symbols in 18.06. Jun 14 19:34:24 Even though OPENSSL_ENGINE_DIGEST defaults to off, once haproxy is fixed, we should probably bump openssl rev as well to "signal" the need to install a new version that avoids that pitfall. Jun 14 19:36:35 But first see if the problem is indeed solved by disabling engine digests. Jun 14 19:51:49 Naive attempt: https://github.com/openwrt/packages/pull/9232 Jun 14 19:54:21 u-boot can attempt to boot off a image over ftp or tftp correct? Jun 14 19:54:37 for testing without writing to flash Jun 14 19:54:42 Slimey: yes Jun 14 19:55:06 i just have to make the correct image for it i guess Jun 14 19:56:20 the way it works on my omnia is I tftp kernel, dtb, and zImage Jun 14 19:56:42 then boot Jun 14 19:57:40 https://paste.ubuntu.com/p/Sbq97YMvsZ/ Jun 14 19:57:58 device is similar to Senao CAP4200AG Jun 14 19:58:14 but has larger flash, 32M instead of 16M Jun 14 19:58:19 mangix: I would keep the changes to a minimum. I can attest ENGINE_DIGEST will do no harm, but anything else may result in other packages breaking/expected features missing... Jun 14 20:00:01 ENGINE_CRYPTO would not break anything, but may inadvertently disable hardware crypto support. Jun 14 20:03:12 By selecting all these symbols, haproxy had effectively set new defaults for them, which we would be changing now. ENGINE_DIGESTS will only disable static (not exported) functions, so it is OK. Jun 14 20:09:45 cotequeiroz: IIRC, there's some kind of spelling error in the OpenSSL Makefile that turns engine on. Jun 14 20:09:55 also similar to AirTight C-55 :o Jun 14 20:12:50 I know, but turning engines on does not mean that cryptodev will be built. The configure script only enables it for BSD, so Linux needs -DHAVE_CRYPTODEV, which is not mispelled. Jun 14 20:16:00 The main trouble are the other features, such as NPN, DTLS, COMPRESSION, PSK, SRP, EC (EC2M _may_ be OK to take out), and so on. DTLS does nothing to the library, but changes header definitions. Jun 14 20:20:49 By looking at the code, the trouble seems to be a NULL data pointer passed to cryptodev_digest_update (here's where the error happens https://github.com/openssl/openssl/blob/7a7afc559ebc0ad88390cc62bfc34c221d595831/crypto/engine/eng_cryptodev.c#L803) Jun 14 20:23:09 I'll see about testing it locally, and if able, I'll open a PR upstream. I'd still recommend to turn off digests for the lack of copy support and poor performance. Jun 14 20:24:38 cotequeiroz: I posted a comment saying something similar Jun 14 20:24:48 Looking at the link you gave me, there is a problem with /dev/crypto permissions, which probably need fixing if we want non-root process to use it. Jun 14 20:25:58 ah yes that was done by me Jun 14 20:26:46 https://github.com/openwrt/openwrt/commit/c6cef6dde743c9d1b52426f4aa2e7068fde43e7e Jun 14 20:53:21 hi folks. I have not been tracking openwrt well. When is 19.x due out? Jun 14 20:55:25 dtaht84: it has been branched. I do not believe an announcement was made Jun 14 20:55:36 Soon (TM) Jun 14 20:58:43 Thx! Jun 14 22:25:47 =) **** ENDING LOGGING AT Sat Jun 15 02:59:57 2019