**** BEGIN LOGGING AT Tue Jul 16 03:02:17 2019 Jul 16 07:24:12 jow: I was debugging some weird crash in my app and I learned that uci_load() is not as trivial as it seemed to me Jul 16 07:24:14 jow: if you take a look at https://lxr.openwrt.org/source/uci/libuci.c#L210 it seems it always returns 0 Jul 16 07:24:15 except there is that UCI_HANDLE_ERR with some magic setjmp I've never heard about before Jul 16 07:24:17 so that function can 1) return an error 2) not set *package on errors Jul 16 07:24:18 it seems every time uci_load() gets called it should be checked for returned value, is that right? Jul 16 07:24:20 if so it seems we have few bugged places: Jul 16 07:24:22 rpcd: https://lxr.openwrt.org/source/rpcd/session.c#L837 Jul 16 07:24:23 luci2: https://lxr.openwrt.org/source/luci2-ui/luci2/src/rpcd/luci2.c#L225 and https://lxr.openwrt.org/source/luci2-ui/luci2/src/rpcd/luci2.c#L1247 Jul 16 07:36:23 rmilecki: I think, that rpcd/session.c is ok, because *p = NULL; and it's checked there after uci_load Jul 16 07:36:54 rpcd2/luci2.c might be an issue, because the pointer is not initialized to NULL Jul 16 08:05:03 cotequeiroz - thx. I'll have a try Jul 16 08:14:11 rmilecki: right, it should be checked Jul 16 08:14:36 rmilecki: however at least rpcd and luci2 check the package pointer right after Jul 16 08:15:24 rmilecki: which should be non-NULL when uci_load() suceeded Jul 16 08:15:41 rmilecki: and yes, (lib)uci uses some kind of setjmp/longjmp exception handling Jul 16 08:29:49 anyone know where dedeckeh is these days? Jul 16 08:30:07 ldir: I guess busy with a new job Jul 16 08:30:16 but you can drop him a mail Jul 16 08:30:27 Oh he has a new job? Jul 16 08:38:12 I thought so, but maybe I was mistaken Jul 16 08:40:11 luci2 does the check, but on uninitialized local variable, so it can contain garbage Jul 16 08:40:30 *package is not set to NULL explicitly before calling uci_load Jul 16 08:40:50 I was looking at bcf20e05832aa8b00ab4b5e67a112d7910cca2d0 and I didn't think his arguments for reverting quite added up Jul 16 08:41:05 I think, that the C standard gurantees, that only static variables are being initialized Jul 16 08:41:53 so the uci_load could fail, but the *package pointer could still contain something considered not NULL Jul 16 08:44:34 ynezz I think you're correct - it's whatever (was previously) on the stack, as the local vars exist in the local stack frame Jul 16 08:45:51 I would probably fix it by setting *p = NULL in uci_load Jul 16 08:46:53 and `if (!p) return 1;` after `p = ctx->backend->load();` Jul 16 08:48:18 ynezz: mkresin and I worked on a 'bizarre' checksum calculation failure and it turned out to be an uninitialised variable that sometimes worked, and sometimes didn't :-) Jul 16 08:51:32 joys of undefined foo Jul 16 08:58:22 ynezz: the return 0 is not reached if ctx->backend->load() fails Jul 16 08:58:39 it will longjmp away to an error return checkpoint Jul 16 08:58:57 afair Jul 16 08:59:30 right, it will jump to UCI_HANDLE_ERR(ctx); in line 214 Jul 16 09:00:24 which is a macro evaluating to a setjmp() instruction with a conditional return errcode Jul 16 09:05:32 ok, so then probably all the callers of uci_load should check uci_load's return code instead of the *package Jul 16 09:06:05 so rmilecki was correct Jul 16 09:27:46 ynezz: right, rpcd with that "struct uci_package *p = NULL;" seems safe Jul 16 09:30:42 ynezz: or preinitialize package with null Jul 16 09:30:54 right Jul 16 09:31:02 I can send a patch Jul 16 09:31:15 or maybe just fix it directly (no patch) Jul 16 09:31:17 seems obvious Jul 16 09:31:33 jow: or do you want to handle that? Jul 16 09:33:01 no, feel free to Jul 16 09:43:54 ynezz: jow: thanks for looking at that with me, fixed now https://git.openwrt.org/?p=project/luci2/ui.git;a=commitdiff;h=7c942bffdd21f52ad6273c73d5bd2868283f3c42 Jul 16 11:21:51 anyone run in to issue with setting chmod on the folder but as user, getting permissions denied during compile? Jul 16 12:10:06 rmilecki: you work on luci2? Jul 16 12:11:44 aparcar[m]: no Jul 16 12:11:57 I just checked all uci_load() calls from jow's lxr Jul 16 12:52:56 do devices have readable unique identifiers apart from the MAC address? Jul 16 12:56:38 charolastra: usually not. For devices using Winbond SPI flash there is a flash UUID available, and you'll need to hack m25p80 to read it. Jul 16 13:05:58 any trick to generate an ID from the MAC that isn't obviously incrementable? Jul 16 13:16:47 mangix: about turris issue 398: I had seen it before, and the workaround is to disable digests (make sure haproxy doesn't force-enable them). I haven't proposed a PR for 1.0.2 yet. Jul 16 13:32:55 Hey guys, a few days ago I was here regarding an issue with CONFIG_DOWNLOAD_FOLDER. Turns out it was a problem on my end, nothing to worry about. Thanks everyone who helped. Jul 16 13:45:47 Btw, I just created FS#2389 - https://bugs.openwrt.org/index.php?do=details&task_id=2389 - would anyone be interested in looking into that? Jul 16 14:16:59 don't see any rpi4 commits in the rpi-4.19.y branch yet :( Jul 16 14:24:49 stintel: i assume you're referring to the official raspberry pi kernel repo? i see pi4 commits there... Jul 16 14:25:06 for instance 80189f361601aa49bdc116fdad56a54121f675ff Jul 16 16:05:40 "make target/linux/install V=s" fails with: Jul 16 16:05:45 cp: cannot create regular file '/home/n/openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/root-ipq806x/init': No such file or directory Jul 16 16:05:55 are you out of disk space? Jul 16 16:06:34 /dev/mapper/lubuntu--vg-root 155G 78G 70G 53% / got a bit left... Jul 16 16:07:08 should root-ipq806x be linux-ipq806x? Jul 16 16:24:42 hmm, initially I did "make -j 3 target/linux/{compile,install} V=s" Jul 16 16:25:28 the "-j 3" bad for compile? might have used it for clean,prepare as well... Jul 16 16:26:57 I'd be surprised if you ran into a parallelism bug at only j3, Jul 16 16:27:07 does it happen every time? just run clean and build again? Jul 16 16:27:24 tyring again without it... slow system so will take a few... Jul 16 16:29:25 i might have seen some warning about -j 3 scroll by earlier... Jul 16 16:29:54 sometimes you see a waning that parallelism is being disabled for a certain directory, nothing to be concerned about Jul 16 16:30:49 it worked yesterday but then I "refreshed" today after about 5+ days... Jul 16 16:37:42 ath79/generic got a sha256sums.sig file while /nand got sha256sums.asc, whats happening? Jul 16 16:54:11 no, same error w/o -j 3 ... Jul 16 17:02:16 I think I'm looking at the wrong error... Jul 16 17:05:19 there is: "Makefile:29: recipe for target '/home/n/openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x/linux-4.19.57/.image' failed" Jul 16 17:06:53 and "Makefile:13: recipe for target 'install' failed" Jul 16 17:07:37 as well as: target/Makefile:23: recipe for target 'target/linux/install' failed Jul 16 17:08:13 and finally: "/home/n/openwrt/include/toplevel.mk:216: recipe for target 'target/linux/install' failed" Jul 16 17:09:53 * nmrh gets the feeling today he is a failure and will quitely try to fix it himself for a time Jul 16 17:10:12 you got any more log than that? there must be a reason that recipe failed... Jul 16 17:13:14 invisiblek: https://pastebin.com/wMHR8pNi Jul 16 17:13:59 this after clean,prepare and compile,install (which also failed) Jul 16 17:14:59 started from "make distclean" after git fetch this am Jul 16 17:15:14 building 19.07 / glibc, build fails: https://pastebin.com/zWSGuGzu Jul 16 17:16:15 webui of https://sourceware.org/git/glibc.git does not find commit 4802be92c891903caaf8cae47f685da6f26d4b9a too Jul 16 17:16:21 wonder if it's something dumb like that plus sign in there nmrh Jul 16 17:16:48 * nmrh looking Jul 16 17:22:04 invisiblek: if you mean the "+" in the /build_dir/target*+*, that's been there through successful builds Jul 16 17:41:13 nmrh: looks like some dirs just don't get created when building for that target. they must get created for another target Jul 16 17:42:03 for this device i had to mkdir the following dirs to get a successful 'make target/linux/install' from a clean build dir Jul 16 17:42:04 build_dir/target-mipsel_24kc_musl/root-ramips Jul 16 17:42:04 build_dir/target-mipsel_24kc_musl/root.orig-ramips/ Jul 16 17:42:04 build_dir/target-mipsel_24kc_musl/root.orig-ramips/tmp Jul 16 17:50:42 invisiblek: well I can try that but it feels wrong as I didn't need to to this last week... Jul 16 17:50:57 did you have a build dir that had built a full firmware or something though? Jul 16 17:51:14 or had built *something* else that may have created those dirs? Jul 16 17:51:29 ahh, that must be it, I think I did Jul 16 17:53:44 i'll see what happens if I build a full image first... Jul 16 17:54:25 somehow I thought I could get a initramfs image (automagically) without building a full image first Jul 16 17:54:31 you sohuld be able to Jul 16 17:55:29 well I'm building kernel 4.19 from cherry picked chunkeey's staging tree so maybe that has something to do with it Jul 16 17:55:45 nope, that has nothing to do with it Jul 16 17:55:50 it happens to me with a clean build dir too Jul 16 17:56:03 worked fine with a non-clean one, and works fine if i manually create those dirs before it Jul 16 17:56:50 i can "socialize" it in the forum and file a bug if necessary... Jul 16 17:57:07 i'm working on a patch, will put it on github and have convo there Jul 16 17:59:40 k, will look there in a bit Jul 16 18:00:08 i'm not super familiar with openwrt's build system yet, so don't hold your breath :P Jul 16 18:02:29 hmm, maybe you ought to just post on the forum nmrh. after thinking about it, 'make target/linux/install' should really only build the kernel i think...looks like it's trying to do more than that? Jul 16 18:02:55 (again, not too familiar with the build enviro, probably best to get an expert on it) Jul 16 18:05:36 I'll post it... this may be a "fringe" case so I don't expect a fix Jul 16 18:06:20 but first will try just making the directories and see if the kernel will install and boot (from ram) Jul 16 18:12:08 Hey! Jul 16 18:14:13 I am a student working on buildroot of openwrt as my project for Google Summer of Code. I wanted to know more about the reason why sha256sums.asc was renamed in some targets. For example, I was expecting https://downloads.openwrt.org/snapshots/targets/ath79/generic/sha256sums.asc but found https://downloads.openwrt.org/snapshots/targets/ath79/gener Jul 16 18:14:14 ic/sha256sums.sig instead. Jul 16 18:22:22 sudhanshug: you may have better luck asking again on "European" time (morning or early afternoon) Jul 16 18:22:40 also vacation season is here... Jul 16 18:23:48 sudhanshug: i believe jow updated the buildbots a bit Jul 16 18:23:54 probably just a cosmetic change Jul 16 18:24:08 sig is a more correct file ending than asc Jul 16 18:29:56 blogic: Okay. Thanks for the reply :D . Any particular reason you can think for this inconsistency? Actually I am trying to use a script to build custom images and I am experiencing errors because of this. Jul 16 18:31:27 when did this change ? Jul 16 18:31:48 my guess is that they are being refreshed now as the new build complete Jul 16 18:37:01 not sure, there is a change in buildbot.git from 2 weeksago that copies the file Jul 16 18:37:05 better wait for jow Jul 16 18:37:07 jow ^^ Jul 16 18:37:11 jow: ^^ Jul 16 18:39:57 invisiblek: mkdir -p dirs won't do it, an initramfs image still needs things like opkg Jul 16 18:40:58 right Jul 16 18:41:12 obviously..., for this its just easier to build a full image than create/update dependcies Jul 16 18:44:00 I'll still post my experience in the forum, but in an existing thread I've already got going Jul 16 20:17:33 rmilecki: Thanks for the clean-up efforts around syspugrade! Jul 16 20:17:42 :) Jul 16 20:17:59 i'm happy to hear someone appreciates that :) Jul 16 20:18:13 rmilecki: just testing the imx6 patch Jul 16 20:18:48 wanted to do it sooner, but got distracted by the broken perf Jul 16 20:18:53 After poking around in there with ath79-nand, it's definitely apprciated! Jul 16 20:19:02 ynezz: don't test it, it's broken ;) Jul 16 20:19:14 it misses RAMFS_COPY_BIN='jffs2reset' at least Jul 16 20:19:21 I've fixed that Jul 16 20:19:29 but it still doesn't work Jul 16 20:19:53 does it produce umount: can't unmount /overlay: Invalid argument Jul 16 20:19:56 or is that something else? Jul 16 20:20:19 MTD partition 'rootfs_data' not found Jul 16 20:20:31 umount: can't unmount /overlay: Invalid argument Jul 16 20:20:45 but I swear it was working before :) Jul 16 20:20:57 just going to test it without your patch now Jul 16 20:21:24 ynezz: umount /overlay is already handled by switch_to_ramfs() Jul 16 20:21:39 so it may be not needed in imx6's platform_do_upgrade() Jul 16 20:21:48 what's up with the rootfs_data? Jul 16 20:22:02 that's probably the jffs2reset Jul 16 20:22:10 oh Jul 16 20:22:20 but it should work... unless you're running initramfs? Jul 16 20:22:50 let me know if that jffs2reset / rootfs_data works without my patch, please Jul 16 20:23:16 /dev/loop0 on /overlay type f2fs Jul 16 20:23:33 /dev/root on /rom type squashfs Jul 16 20:25:47 ynezz: what about grep rootfs_data /proc/mtd Jul 16 20:25:58 it's emmc, no mtd Jul 16 20:26:13 ah and f2fs Jul 16 20:26:28 so i would say you were seeing that error also without my patch Jul 16 20:26:31 but check that please Jul 16 20:26:35 but jffs2reset would just delete the files in the overlay Jul 16 20:28:40 /dev/loop0 is mounted as /overlay, only erasing files Jul 16 20:28:49 Switching to ramdisk... Jul 16 20:29:24 oh, so that is a problem indeed Jul 16 20:30:06 jffs2reset is called to delete files from /overlay, but it cannot work in platform_do_upgrade() as it happens after switch_to_ramfs() which already unmountd /overlay Jul 16 20:30:18 ynezz: does my understanding sound correct? Jul 16 20:30:40 yep Jul 16 20:38:57 uh, not sure what to do with that... Jul 16 20:39:19 i was hoping we can totally get rid of platform_pre_upgrade() but imx6's seems like a case that really need it Jul 16 20:43:07 I remember, that it took me some time, to figure out the proper place for this config reset Jul 16 20:46:56 BTW, why do you want to get rid of this hook? Jul 16 20:49:17 i just thought it's not really needed Jul 16 20:49:29 now i see there is a single case where it is Jul 16 20:51:16 ynezz: can you show me "cat /proc/mtd" anyway? Jul 16 20:51:22 pastebin it maybe Jul 16 20:51:28 it's mepty Jul 16 20:51:34 s/mepty/empty Jul 16 20:51:43 ah Jul 16 20:51:52 just the header `dev: size erasesize name` Jul 16 20:52:05 ynezz: what is "rootfs_data" on your device then? Jul 16 20:53:31 i'm trying to follow (understand) that "/dev/loop0 is mounted as /overlay, only erasing files" Jul 16 20:53:59 jffs2reset is firstboot Jul 16 20:54:15 so it works across all platforms I would say Jul 16 20:54:46 it seems that "rootfs_data" volume is a /dev/loop0 block device thatis mounted as /overlay Jul 16 20:54:56 http://paste.ubuntu.com/p/Xb88hMJz8Q/ Jul 16 20:55:51 ynezz: any idea how does this work? https://git.openwrt.org/?p=project/fstools.git;a=blob;f=jffs2reset.c;h=dbe049881f5cbff97af411908406ffa0294a56b4;hb=HEAD#l122 Jul 16 20:57:24 the erasing part is probably in the kernel Jul 16 20:57:53 let me rephrase that Jul 16 20:58:16 if you look at jffs2reset.c, you'll see jffs2_reset() gets called *only if* volume_find("rootfs_data") returns something Jul 16 20:58:38 in your case jffs2_reset() got called because it printed "/dev/loop0 is mounted as /overlay, only erasing files" Jul 16 20:58:52 i'm just wondering how volume_find("rootfs_data") worked on your device Jul 16 20:58:59 where does your device has "rootfs_data" Jul 16 21:03:51 /dev/loop0: LABEL="rootfs_data" UUID="ec3f190d-e69e-4483-820d-aee0bd610507" TYPE="f2fs" Jul 16 21:04:41 ahh, it's a fs2fs label Jul 16 21:04:51 now I can understand it Jul 16 21:04:53 thanks a lot! Jul 16 21:06:27 yep, libfstools/rootdisk.c -> mkfs.f2fs -q -l rootfs_data Jul 16 21:07:13 ok, everything makes sense now :) Jul 16 21:22:22 blogic: Hauke: I have a question regarding the Lantiq PCI controller driver. currently there's a "req-mask" property which is "board-specific". what does this setting do exactly? based on the ifxmips_pci driver it seems to enable either 1 or 4 "external PCI masters". is there any downside to using a fixed value (4 external PCI masters) for all boards? Jul 16 21:23:56 xdarklight: if i recall, there is an external irq line Jul 16 21:24:09 and its wired to the pci/e slot Jul 16 21:24:16 if its not wired, then its floating Jul 16 21:24:22 and will cause irq storms Jul 16 21:26:36 blogic: OK, I found that some boards use up to 3 EIU interrupts for PCI interrupts. however, do I understand correctly that when I get the PCI subsystem to ignore let's say PCI_INTB/C/D if they are not configured then it should be safe to enable 4 external PCI masters? Jul 16 21:27:34 probbaly, yes Jul 16 21:27:42 well Jul 16 21:27:49 no, becasue they still fly Jul 16 21:28:02 so the irqs need to be disabled not ignored Jul 16 21:28:25 nmrh: yeah, you could argue a buildroot dependency failure, but I wasn't aware you wre trying to build a single internal target from a clean checkout, with nothing else built first. Jul 16 21:37:21 blogic: assuming I disable the "unused IRQ lines" (which in my words is: write a dedicated EIU interrupt driver) I can hardcode the "external PCI master" number Jul 16 21:39:38 blogic: to give you some context - I'm working on an upstream PCIe driver for the Lantiq SoCs. unfortunately this means reworking the PCI driver to use PCI_DRIVERS_GENERIC (instead of the MIPS specific pci_controller legacy code-path..). I'm already seeing the ath10k card (and it seems to work, but detailed testing is missing) on a Home Hub 5A with these changes: https://github.com/xdarklight/linux/commits/lantiq-pcie-driver-next- Jul 16 21:39:40 20190711 :) Jul 16 21:39:54 that link broke... here it is again: https://github.com/xdarklight/linux/commits/lantiq-pcie-driver-next-20190711 Jul 16 21:41:49 in the process of porting over the PCI driver I want to add the dt-bindings to comply with what upstream wants and the "req-mask" property is kinda in the way currently (one: because it doesn't match the naming schema for vendor-specific properties and two: because I didn't know how to describe it :)) Jul 16 21:53:35 rmilecki: should I still do the testing? I'm home now with the devices Jul 16 21:53:38 rmilecki: sorry for the delay... Jul 16 21:57:07 *yawn* Jul 16 21:57:17 so i built an automated QA framework today Jul 16 21:57:21 tuned for openwrt Jul 16 21:57:35 based on python + a daemon Jul 16 21:57:46 thing is called udron Jul 16 21:58:03 thing is called udrone Jul 16 21:58:13 you have a device you want to test Jul 16 21:58:16 + N drones Jul 16 21:58:21 all have udrone installed Jul 16 21:58:43 there is a multicast protocol for assigning drones to groups and sending them commands and getting replies Jul 16 21:59:05 this is all controlled from a python script which abstract each drone away into a class Jul 16 21:59:45 and then you can either write test cases in json -> https://pastebin.com/tgmc6uy8 (that is my unit test script) Jul 16 21:59:51 or even directly in python Jul 16 22:00:00 all the fundamental building blocks are there Jul 16 22:00:23 reading/writing uci, doing ubus, executing commands, reading/writing files Jul 16 22:00:44 now i need to add a few complex calls in python that will allow handling networking Jul 16 22:01:09 so a "assoc to an AP" will be a uci_set + reload_config call Jul 16 22:01:21 and it'll do the param->uci mapping for you Jul 16 22:01:32 also built plugins for dns stress testing and so on Jul 16 22:01:49 have a long list, like a call to toggle the port status Jul 16 22:02:04 so you can test if a unit survives 1000 link status changes Jul 16 22:02:20 or what happens if 16 drones dis/assoc to wifi in 30s cycles Jul 16 22:02:31 ... Jul 16 22:02:31 ... Jul 16 22:02:39 should be in git shortly :-D Jul 16 22:03:15 and *drumroll* there is even a doc that describes the protocol, one on howto use the python and its apis and a 3rd for how to build the testbed Jul 16 22:03:24 wow Jul 16 22:03:30 and now, after 16+ hours hacking on this today I am off to bed Jul 16 22:03:49 https://pastebin.com/sP6ypYBk <- the output of running the unit test Jul 16 22:03:50 karlp: building a full image fixed it, just needed to "talk it through" so ty for responding Jul 16 22:08:59 blogic: sounds great Jul 16 22:09:25 blogic: does it also include device flashing? Jul 16 22:15:34 aparcar[m]: you have full ubus and uci control and can ul/dl files Jul 16 22:16:22 and inside python you can create complex calls which wrapper low level building blocks Jul 16 22:16:40 so adding a sysupgrade cmd is less than 10 lines of python Jul 16 22:33:15 blogic: so how are the drones connected? let's say I break a device, how does it recover? Jul 16 22:35:05 this is intended for different QA testing, so you don't try to break your drones :) Jul 16 22:43:34 ynezz: but when I kill the network by accident? Jul 16 22:43:52 ynezz: so docker containers would be something to work with as well? **** ENDING LOGGING AT Wed Jul 17 02:59:57 2019