**** BEGIN LOGGING AT Tue Jan 21 02:59:56 2020 Jan 21 08:35:29 KanjiMonster: that make is still running? :) Jan 21 10:05:38 xback, when trying to build 5.4 it errors out with the following statement: Jan 21 10:05:45 Package kmod-crypto-ecdh is missing dependencies for the following libraries: ecc.ko Jan 21 10:06:12 nitroshift: yes. a lot of libs moved to another folder Jan 21 10:06:20 heh :| Jan 21 10:06:31 nitroshift: There is a reason why the patch is marked as WIP ;-) Jan 21 10:06:48 xback, i know, trying to sort out patches for mvebu Jan 21 10:07:02 and a config too Jan 21 10:07:34 brb, smoking break Jan 21 10:21:11 back Jan 21 10:52:53 ynezz, jow: an update on the time64 / y2038 work I mentioned two weeks ago: the rebuild of adelielinux against the latest musl libc is going better than expected so far, and I've started to document packages that have known problems at https://docs.google.com/spreadsheets/d/1Z1sDq1X6iRpJW30R-ezERoFBbLFmFYlZ7g2_1RUbqdA/edit#gid=0 Jan 21 10:53:59 most of these I suspect won't be relevant for openwrt because they are not even packaged Jan 21 11:10:03 jow: where is this ubus event coalescing done? I'm trying to skim the procd code for it, but I'm not really seeing it. Jan 21 11:34:28 karlp: the service list in procd is a vlist structure which basically is an avl tree with versioned node members. Upon receiving a service update message (sent as json from the init script), the service description is added in a newer version to the vlist and the vlist is flushed Jan 21 11:34:51 the flushing will invoke service_instance_update() with the old and the new service state version Jan 21 11:35:50 which will call into instance_update() which will compare the states through instance_config_changed() Jan 21 11:36:00 only if changes occur, the service is reloaded Jan 21 11:36:48 which means that if multiple events are triggered which recreate the service, only the first one is handled and subsequent ones are ignored since they do result in the same state as the just restarted service Jan 21 11:37:34 I'm actually getting two events when the states should be different, not two duplicates. Jan 21 11:43:29 I'm at least doing a "uci show" just before both times I make the reload_config call, so I see that they should be two different configs. Jan 21 11:44:26 so I have service BB that does uci commit / reload_config in both stop/start, because it's actually not a service, it's modifying the config of another service, which doesn't allow dynamic reconfig. Jan 21 11:45:26 and doing /etc/init.d/BB restart is not restarting the other service, which is fine... but I still don't see why it isn't happening, when both the stop and start are both sending the ubus config event changes for the parent service. Jan 21 11:46:59 the config.change event is intercepted by https://lxr.openwrt.org/source/procd/service/service.c#L548 Jan 21 11:47:14 that calls into https://lxr.openwrt.org/source/procd/service/trigger.c#L294 Jan 21 11:47:42 which executes the json scripts assigned to the event (see: ubus call service list '{ "verbose": true }') Jan 21 11:48:56 the script is typically something like [ "config.change", [ "if", [ "eq", "package", "XXX" ], [ "run_script", "/etc/init.d/XXX", "reload" ] ], 1000 ] Jan 21 11:49:15 the 1000 is the settle time iirc Jan 21 11:49:48 the "run_script" command of the JSON script will invoke https://lxr.openwrt.org/source/procd/service/trigger.c#L155 Jan 21 11:50:42 and trigger_command_add() will not requeue the same command/trigger if the execution delay period is not reached Jan 21 11:50:51 that was my understanding Jan 21 11:54:18 procd.sh defines the 1000ms as PROCD_RELOAD_DELAY=1000 Jan 21 11:56:09 so the coalescing of events happens within the 1000ms reload delay, or more correct, all commands that are to be executed as result of the events are only executed once within a 1000ms timeframe Jan 21 13:03:39 nitroshift: xback: dirty patch for kmods: https://paste.debian.net/1126975, might not be a final one, also needs partially: https://patchwork.ozlabs.org/patch/1226007 Jan 21 13:10:58 tmn505, thanks **** BEGIN LOGGING AT Tue Jan 21 13:30:05 2020 Jan 21 13:40:18 cmake's weird, procd complains abotu not finding ubus, but ubus doesn't complain about not finding libblobmsg_json. Only difference I can see is that there's an if(build_static) split, but it has a find_library for both sides. Jan 21 14:57:33 I am having serious trouble with ath79 master on tp-link c7v4 and c6v2(us). JFFS2 is read-only and all attempts to erase fail, so /overlay doesn't come up. Maybe related, the tplink,archer-c6-v2-us image cannot sysupgrade to itself unless I -F it :( Jan 21 14:57:42 could not find any related reports. Jan 21 15:58:43 hmm, openwrt-19.07 branch, ath79 on tp-link (several models): also cannot sysupgrade to itself, "image check failed". Jan 21 15:59:12 I am using 19.07.0 on c7v5 and c6v2 (non-US) without any obvious issue Jan 21 15:59:45 master is broken, I broke it yesterday, sorry for that Jan 21 16:00:15 I'm going to revert those changes as I'm leaving thus can't fix that kernel patch :( Jan 21 16:01:02 seems like linux-mtd is dead/overhelmed, because that patch was sent to review, but didn't got any reply yet Jan 21 16:01:14 s/to review/for review/ Jan 21 16:01:24 nonethless I should better test this Jan 21 16:02:07 discussion is here https://patchwork.ozlabs.org/patch/1217561/ Jan 21 16:02:41 reverting de80424f7 is temp workaround Jan 21 16:21:59 ok. one of my issues is API-destroying maintenance that was done to sysupgrade, plus something really broken when you don't ucert sign images. will track that further before I say anything about it. Jan 21 16:22:24 the other issue is the mtd being read-only and breaking the jffs2 build, will try the revert and see if that fixes it Jan 21 16:22:39 ynezz: thanks! Jan 21 16:28:32 can somebody explain me what setting "default TARGET_INITRAMFS_COMPRESSION_LZMA" in config/Config-images.in does? Jan 21 16:29:50 I just see people enabling it for the target when the add ramdisk to features, but nobody explains what it's good/required for Jan 21 16:30:25 I wonder because ath79 has ramdisk support but no "default TARGET_INITRAMFS_COMPRESSION_LZMA" so far Jan 21 16:30:39 it might have been added when the kernel default was "not lzma" ? Jan 21 16:31:00 and by the time ath79 rolled around, it was already the default? Jan 21 16:31:53 adrianschmutzler: include/kernel-defaults.mk: echo -e "$(if $(CONFIG_TARGET_INITRAMFS_COMPRESSION_LZMA),CONFIG_INITRAMFS_COMPRESSION_LZMA=y\nCONFIG_RD_LZMA=y Jan 21 16:32:13 so adding two config options into kernel config Jan 21 16:34:07 ynezz: ah, thanks. so, would we want to enable it for ath79 here: https://github.com/openwrt/openwrt/pull/2580#discussion_r369093354 Jan 21 16:34:08 ? Jan 21 16:34:44 dunno, is it broken? :) Jan 21 16:35:42 statement is that it is required to support mikrotik devices, without detailed justification Jan 21 16:38:14 binwalk -e bin/targets/ath79/generic/openwrt-ath79-generic-tplink_archer-c7-v5-initramfs-kernel.bin -> 512 0x200 LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 11448616 bytes Jan 21 16:38:15 that's what I do not understand, ath79 has KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | ... everywhere, and ramdisk enabled, so what do I need the kernel config options for, then? Jan 21 16:40:45 because of that tp-link specific header? Jan 21 16:45:20 initramfs is embedded in kernel. It can be compressed prior to embedding. And for most targets the whole kernel is compressed too. Jan 21 16:46:01 okay, so we are discussing compression applied at two different "levels" here? Jan 21 16:46:09 Embedding a compressed filesystem might actually make it bigger: https://lore.kernel.org/lkml/57EAD77B.7090607@klondike.es/ Jan 21 16:46:59 adrianschmutzler: I think, so, that `| lzma` step is probably similar result as that kernel config option Jan 21 16:47:17 So it makes sense for booting initramfs images when bootloader doesn't support good compression for the kernel I guess. Jan 21 16:47:42 adrianschmutzler: so you would perhaps double lzma that initramfs, once in kernel, second time with `| lzma` Jan 21 16:47:56 thats probably why it's disabled? Jan 21 16:47:59 That lzma step counts on bootloader to work properly to uncompress the whole kernel image. And certain (e.g. ralink u-boot fork) bootloaders are actually not capable to do it in certain conditions. Jan 21 16:48:22 So you might want to use uncompressed kernel but compressed rootfs for initramfs booting targets like that. Jan 21 16:48:41 well, in ar71xx/mpc85xx/ramips/... it's enabled, but in ath79 is disabled. Jan 21 16:49:03 but ramips doesn't use `| lzma` or is it? Jan 21 16:49:10 It usually does Jan 21 16:49:19 and the PR wants to enable it on entire ath79 because it states that mikrotik needs it. Jan 21 16:49:27 There was a tweak to lzma step to make it a bit more edible for the broken uboot. Jan 21 16:49:38 adrianschmutzler: I'd say let the commiter provide full rationale for that. Jan 21 16:50:17 PaulFertser: I think he has not fully understood it as well. But we could just try without and if it's working, do not touch it Jan 21 16:50:18 Because it's just a matter of size of the resulting kernel image. It should be bootable in any case. Jan 21 16:50:21 git grep KERNEL_INITRAMFS.*\|.*lzma | grep -c ramips -> 0 Jan 21 16:50:57 ynezz: TARGET_INITRAMFS_COMPRESSION_LZMA Jan 21 16:51:04 In config/Config-images.in Jan 21 16:51:17 yes, that's what I'm saying Jan 21 16:51:25 https://github.com/openwrt/openwrt/blob/master/config/Config-images.in#L21 Jan 21 16:51:52 that TARGET_INITRAMFS_COMPRESSION_LZMA=y in ramips is `KERNEL_INITRAMFS = ... | lzma` in ath79 Jan 21 16:51:59 hmm, annoyingly enough, 19.07 (branch) *is* creating signed sysupgrade images, that cannot verify themselves (but *do* try, and fail, and break sysupgrade). Still tracking, looks like I need ucert-full to try to debug it further. Jan 21 16:52:05 I wonder if I fail to boot initramfs on ramips because of that double lzma thing. Jan 21 16:52:37 I don't see `| lzma` used in ramips for KERNEL_INITRAMFS Jan 21 16:53:04 (git grep returned 0 occurences) Jan 21 16:54:11 So you mean the kernel feature is enabled but the initramfs is not packed. Jan 21 16:54:33 it's not enabled in ath79, you pack it with | lzma Jan 21 16:54:46 it's enabled in ramips, you don't | lzma Jan 21 16:54:57 but in ar71xx you do both Jan 21 16:55:03 Oh weird, then I do not understand it. Jan 21 16:57:43 adrianschmutzler: maybe because of ar71xx/legacy ? Jan 21 16:58:22 ynezz: possible, I never really dealt with ar71xx/legacy, so I do not understand it's requirements. Jan 21 16:58:56 just checked mpc85xx, there we have the kernel option, but no lzma for KERNEL_INITRAMFS Jan 21 16:59:07 so this would match the situation on ramips Jan 21 16:59:35 I have impression that this KERNEL_INITRAMFS doesn't specify what to do with the initramfs image, it's the pipeline for the whole kernel (with initramfs appended). Jan 21 17:00:12 that's my understanding as well Jan 21 17:00:37 as you need that header for bootlader Jan 21 17:02:39 are there any working commands for tp-link c7v5 boot with initramfs? Jan 21 17:07:17 Kernel build compresses the generated cpio file on its own if the kernel option INITRAMFS_COMPRESSION_LZMA is set. Jan 21 17:07:47 In usr/gen_initramfs_list.sh Jan 21 17:09:08 well, ath79 is not going to sysupgrade if you have ucert on the image, because whatever it attaches (or whatever fwtool detaches) is not something ucert groks (it has binary gunk on it). How nice. Jan 21 17:09:58 hopefully that bug is not active on the openwrt.org builds :p but all of mine will need sysupgrade -F to salvage. Jan 21 17:46:12 okay, thanks for explaining so far! Jan 21 18:22:29 adrianschmutzler: for fun i've been trying to verify your email signature and failing ... emails are delivered via gmail, tried downloading original message and using munpack to get parts, but gpg2 says "BAD signature" ... same thing for zorun signed emails. Jan 21 18:22:59 f00b4r0: ping - cake issue update ? Jan 21 18:23:44 russell--: Can this be an effect of the mailing list? Jan 21 18:25:50 karlp: btw, your xgettext comment prompted me to review the LuCI language string and xgettext is indeed a quite viable option with a bit of pre- and postprocessing Jan 21 18:26:18 karlp: it also is smarter than the simple Perl scanning script, it ignores commented out code for example Jan 21 18:26:33 *language string extraction Jan 21 18:31:00 adrianschmutzler: i was fully prepared to blame google ;-) Jan 21 18:32:23 well, I use outlook with gpg4win here atm, so enough to go wrong on my side. Jan 21 18:32:33 last time i checked with direct mail it worked though. Jan 21 18:32:37 BAD signature here too. Jan 21 18:33:06 Oh, now it's good. Jan 21 18:33:30 I received the key and mutt showed and verified it. Jan 21 18:33:46 But with separate file it was complaining. Jan 21 18:34:33 karlp: this also fixes expressions like _("foo" + "bar" + "baz") ... very nice Jan 21 18:45:32 oh, that's interesting: Jan 21 18:45:47 "What happens if you do not add this line here?" -> lzma stuff Jan 21 18:45:53 "The board fails to decompress the kernel when booting the initramfs image via TFTP:" Jan 21 18:45:59 https://github.com/openwrt/openwrt/pull/2580#discussion_r369176737 Jan 21 18:47:02 "You're absolutely right." Jan 21 18:47:33 Yes, that contradicts the report before. Jan 21 18:48:55 Also, his feedback kinda suggests there's a bug in "OpenWrt kernel loader". But it might also mean that he's loading to some inapproriate address and so when decompressing a kernel with uncompressed initramfs the "big" initramfs overwrites something in that loader. Jan 21 18:49:41 So it's like parts of loader are overwritten by the uncompressed big (since initramfs is not compressed) kernel image. Jan 21 18:50:37 lyma compression fails tnd to be offset issues Jan 21 18:50:46 lzma decompression fails tnd to be offset issues Jan 21 18:51:04 so the ram needs to hold the lzma, the decompressor and the final image Jan 21 18:51:28 if the decompress overrides the origianl image or decompress code it'll fail Jan 21 18:51:45 this is normally the root cause of the bug he talks about Jan 21 18:52:29 the lzma-loader uses the stock lzma lib code so chances are slim its a loader bug Jan 21 18:53:21 so, how to address this then? Jan 21 18:53:21 Yes. So it's more likely that the lzma loader is located at a bad place. 80A00000 is just ~10 megabytes away from kernel image start. Jan 21 18:57:06 adrianschmutzler: I'd suggest changing LZMA_TEXT_START=0x80a00000 in image/Makefile to something more appropriate so that a bigger uncompressed initramfs would fit without overwriting the loader. Jan 21 19:03:43 PaulFertser: what would be a reasonable value? What are the boundary conditions for choosing? Jan 21 19:03:59 And would I change this for all devices then, or make it variable? Jan 21 19:04:55 adrianschmutzler: I think it should be closer to the end of the RAM. So assuming all devices have at least 32 MiB it can be about that minus the loader size. Jan 21 19:05:43 Ah, I was thinking the wrong way. So this value determines the start of the loader and the uncompressed image is BEFORE Jan 21 19:06:08 and thus it overwrites the loader if too big Jan 21 19:07:54 so, how do I determine the size of the loader? Jan 21 19:10:08 adrianschmutzler: ./staging_dir/toolchain-mips_24kc_gcc-8.3.0_musl/bin/mips-openwrt-linux-size $(find -name loader.elf) Jan 21 19:10:12 (I do not have it built right atm) Jan 21 19:10:28 that's enough for me to go on Jan 21 19:12:21 dedeckeh93: ping wrt odhcpd ipv6 relay mode Jan 21 19:18:47 we should put the lzma-loader at max_ram - 1MB Jan 21 19:19:13 kernel tends to be 6-8 mb on ath79 Jan 21 19:19:25 but initramfs will be much bigger Jan 21 19:20:20 blogic: If I touch it, should I change it for all targets at once, or just ath79 then. Jan 21 19:20:22 ? Jan 21 19:24:43 blogic: what about 30 MB, so we have comfortable 2 MB for the loader? Jan 21 19:25:06 imho it should be the default and an override on per device basis Jan 21 19:25:23 30 would break 16mb devices if we have any left Jan 21 19:25:32 ah wait Jan 21 19:25:48 lzmaloader is larger as it has the kernel embedded Jan 21 19:25:56 what the current offest ? Jan 21 19:26:00 10mb ? Jan 21 19:26:03 yes Jan 21 19:26:16 0xa000... ? Jan 21 19:26:26 0x80a00000 Jan 21 19:26:36 1mb Jan 21 19:26:43 0x80... is kseg1 Jan 21 19:27:06 https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/image/Makefile#L13 Jan 21 19:27:17 so on 32mb+ devices 0x81a00... should be good Jan 21 19:27:43 so, 26 mb Jan 21 19:27:54 that is 24 mb in so the lyma can be 8mb - the loader + offset Jan 21 19:27:59 err 26 Jan 21 19:28:03 well Jan 21 19:28:14 0x818... 24 Jan 21 19:28:17 giving us 8mb Jan 21 19:28:25 maybe I just set it for ath79 for the moment, there we can be sure that we have no 16 mb devices Jan 21 19:28:34 yup Jan 21 19:28:46 i would go for 0x81800000 Jan 21 19:29:02 btw, in that linked file we have KERNEL_LOADADDR at the top but then hardcode the address in loader-common Jan 21 19:29:03 3/4 for decompressed and 1/4 for compressed Jan 21 19:29:20 basic rule is lzma does 1/6 - 1/7 compression Jan 21 19:29:35 can I put the variable there and then use a variable for the LOADER_ADDR as well? Jan 21 19:30:36 i.e. LZMA_TEXT_START=$(LOADER_START) LOADADDR=$(KERNEL_LOADADDR) \ Jan 21 19:30:46 or is something speaking against this. Jan 21 19:30:48 z Jan 21 19:30:49 ? Jan 21 19:42:40 https://git.openwrt.org/?p=openwrt/staging/adrian.git;a=commitdiff;h=6b3561dd83d5d7cecce652dac25b47c2985d729e Jan 21 20:00:09 adrianschmutzler: looks legit, try it on a device to make sure it works Jan 21 20:01:04 thanks. I've asked roger already. Jan 21 20:12:03 looks like the votes have a bias towars v5.4 kernel Jan 21 20:12:29 on a pure tech side, v4.19 is EOL end of 2020 Jan 21 20:12:39 so making a release is sketchy imho Jan 21 20:33:37 hi, does make sense a phy_id value of 0xa600e00 on an ethernet switch port? Jan 21 20:33:55 this is a value extracted from the manufacturer source code Jan 21 20:35:29 it's for a bcm53 switch Jan 21 20:36:22 Openwrt doesn't complain with this value, and all seems to work ok.. Jan 21 20:53:01 I do not have bugtracker permissions, can someone please assign https://bugs.openwrt.org/index.php?do=details&task_id=2759 to dedeckeh93 or someone else who cares about odhcpd? Jan 21 21:08:02 PaulFertser:I will have a look; but odhcpd does not craft neigbor solicitation packets. The NS packets are generated by the kernel due to ping6 requests generated by the odhcpd Jan 21 21:11:08 dedeckeh93: thank you! Hm, indeed, the report is about ICMP packets that are not relayed but locally generated. But something must be special about the relaying case as default OpenWrt install uses ULA and is compatible with macOS Jan 21 21:14:06 jow: you're very welcome :) Jan 21 21:19:11 thanks for your pointers on procd's event processing, still trying to digest it and test some things, but today was a bit rough on getting things done Jan 21 22:10:59 blogic: kernel 4.19 is used in debian stable so it will get longer support Jan 21 22:11:20 and it is also very likely that greg will support it longer for andoid Jan 21 23:04:30 just added my vote for skip 4.19 ;) **** ENDING LOGGING AT Wed Jan 22 03:01:07 2020