**** BEGIN LOGGING AT Mon Oct 15 03:00:01 2018 Oct 15 04:37:21 jwh: i sysupgrade my x86 device just fine Oct 15 04:42:14 yeah I didn't know sysupgrade could read the .img files, never actually upgraded an x86 box yet, normally just get replaced over time Oct 15 05:46:35 Hello, Was wondering if the intel edison could be used as an openwrt router Oct 15 05:48:38 oh hm, thats cute, kernel panic Oct 15 05:49:00 not long after I enabled netfilter offloading, coincidence? Oct 15 06:19:07 jwh: I have seen similar behaviour on ipq806x and maybe lantiq, but given that I don't need offloading to achieve my maximum WAN throughput, I didn't dig any deeper and am very hesitant to cry wolf Oct 15 06:19:36 hmmm Oct 15 06:19:45 first time I've tried it, sooooo Oct 15 06:19:57 turned it off again now, will see if it panics again Oct 15 06:20:08 (if it does I've got a problem, the working day is starting) Oct 15 06:20:11 heh Oct 15 06:29:58 I should probably cook up some way of doing a/b firmware Oct 15 07:13:05 pkgadd: hasn't broken since, hoping it was a coincidence, was looking forward to flow offloading Oct 15 08:02:53 Quick question, maybe anyone knows: Is there a other way to get the actual hostname.domain pair other than uci on a default image, assuming its configured outside of Dnsmasq ? Oct 15 08:14:02 ok found it myself, 'cat /proc/sys/kernel/hostname' Oct 15 09:45:56 russell--: on rollback the saved state is restored, overwriting everything that happened in between Oct 15 09:46:24 russell--: which version did you test? Oct 15 10:29:18 jow: it was 18.06.1 Oct 15 10:29:46 or whatever is most recent stable (i usually don't use such things, but i was helping someone else) Oct 15 10:30:28 yeah, 18.06.1, on a ubnt-erx Oct 15 10:33:23 https://downloads.openwrt.org/releases/18.06.1/targets/ramips/mt7621/openwrt-18.06.1-ramips-mt7621-ubnt-erx-squashfs-sysupgrade.tar Oct 15 10:39:50 btw, who signs to the sha256sums file and with what key? Oct 15 10:42:18 ah, found it, i think. can someone confirm the full public key fingerprint? Oct 15 11:02:41 pkgadd: ok confirmed Oct 15 11:25:26 russell--: after fixing SPI controller driver & sending pinctrl driver upstream, I just starter looking at filesystem Oct 15 11:25:35 i don't understand how things are suppose to work I'm afraid Oct 15 11:25:42 i've vm.dirty_expire_centisecs set to 300 Oct 15 11:25:51 which means 3 seconds I believe Oct 15 11:26:24 I started with a simple test: 1) boot 2) date > /root/foo.txt 3) wait 5 seconds 4) power cut Oct 15 11:26:44 I added pr_info to the wbuf_timer_callback_nolock() so I can see it's executed after 3+ seconds Oct 15 11:26:53 after power cut + booting again my foo.txt is empty Oct 15 11:27:21 i thought that everyting will get flushed/written/synced ater wbuf_timer_callback_nolock() Oct 15 11:27:26 that happens with both: 4.4 and 4.14 Oct 15 11:43:01 russell--: i'm looking at /etc/config/ files now Oct 15 11:43:13 russell--: i'm trying to follow that: "yeah, basically. for me only files that aren't changed from /rom/etc/config/ don't make it to flash" Oct 15 11:43:50 russell--: so I first booted my device, then confirmed that /overlay/upper/etc/config/dropbear and /rom/etc/config/dropbear are both 134 B Oct 15 11:44:00 i waited for "uptime" to show 2 minutes Oct 15 11:44:05 then I power cut Oct 15 11:44:15 after booting again, my /etc/config/dropbear looks OK Oct 15 11:44:26 it's with today build, 4.14.75 Oct 15 11:47:13 rmilecki: maybe they meant "fresh" files that didn't exist in /rom and not files that weren't changed in content? Oct 15 11:47:49 KanjiMonster: well, my /etc/config/network looks OK Oct 15 11:48:06 and /rom/etc/config/network doesn't exist, so it's a fresh file Oct 15 12:08:42 oh, the default vm.dirty_expire_centisecs in 3000, not 300 Oct 15 12:16:08 OK, so I understand how wbuf_timer_callback_nolock() is called now Oct 15 12:16:11 when I do: Oct 15 12:16:15 date > foo.txt Oct 15 12:16:25 wbuf_timer_callback_nolock() gets called for the first time after 5 seconds Oct 15 12:16:51 that call will make sure foo.txt file gets written (without the content though!) Oct 15 12:17:31 wbuf_timer_callback_nolock() also gets called twice, 3000 cs (30 s) +- 10% after "date > foo.txt" Oct 15 12:17:47 those 2 calls make sure that content of foo.txt gets written to the flash Oct 15 12:18:30 so does changing vm.dirty_expire_centisecs fix the issue? Oct 15 12:22:01 nbd: i can't reproduce issue that russell-- was experiencing Oct 15 12:22:43 nbd: vm.dirty_expire_centisecs controls in how many cs (centiseconds), since writing, content get flushed Oct 15 12:22:49 it works as expected i'd say Oct 15 12:23:04 not sure why "touch foo.txt" doesn't use vm.dirty_expire_centisecs , but it's a minor problem Oct 15 12:23:36 unless... Oct 15 12:24:00 russell--: what's the content of /overlay/upper/etc/config/dropbear in your case? Oct 15 12:24:29 nbd: also russell-- was complaining (AFAIR) that even after waiting vm.dirty_expire_centisecs before power cur, he could still see the problem Oct 15 12:24:42 maybe it's a problem with russell--'s NAND driver after all? Oct 15 12:25:05 * rmilecki going to eat a dinner Oct 15 14:16:21 hm Oct 15 14:16:28 so maybe its not flow offloading Oct 15 14:16:43 it lasted much longer (10 hrs as opposed to 30 mins), but its just rebooted again Oct 15 14:17:09 can I just change the coredump pattern to be in /overlay so it gets saved? Oct 15 14:25:56 dedeckeh: sorry Hans, I was holding out for a 'test9' or even an 'rc-1' for that typo patch. Oct 15 14:40:00 ldir:I've BROKEN_RTC enabled; to my surprise the compilation failed ... Oct 15 15:13:28 hm Oct 15 15:13:49 fatal error in interrupt, not enough lines on the terminal to see backtrace :( Oct 15 15:27:34 it didn't dump a crash log or anything :( Oct 15 15:28:36 oh, my bad Oct 15 15:29:01 useless ilo console isn't working so I can't even attach to serial Oct 15 15:40:13 maybe ebtables is just broken still Oct 15 18:56:13 rmilecki: after firstboot the content of /etc/config/dropbear is normal; after a powercycle (with no sync), the file is shown to be the correct length, but filled with all NUL (0x00) bytes. this is consistent on all the NAND based devices I have that are on a 4.14 kernel, including primarily a meraki mr24 and ubnt erx. Oct 15 19:01:15 what? Oct 15 19:01:17 that's crazy Oct 15 19:02:41 russell--: ok, just to make it 100% clear, I'll describe what I'm doing Oct 15 19:03:33 russell--: 1) I do "sysupgrade -n /tmp/openwrt.trx" 2) I wait for sysupgrade & reboot 3) I check dropbear with "cat /etc/config/dropbear" 4) I power cut 5) I boot again 6) I check dropbear with "cat /etc/config/dropbear" Oct 15 19:03:45 russell--: do those steps sound correct to you? Oct 15 19:04:41 yeah, although i use hexdump -C instead of cat Oct 15 19:04:57 ok, I'll replace "cat" with "hexdump -C" Oct 15 19:05:04 let me repeat the test now Oct 15 19:05:58 it's all good here... Oct 15 19:06:04 i'm using bcm53xx Oct 15 19:06:10 i'm not using the stock config, and if it is a timing thing, maybe different files will be effected or maybe none at all. Oct 15 19:06:49 russell--: can you try with the stock config? Oct 15 19:07:10 yes Oct 15 19:07:44 I just treid "hexdump -C /etc/config/*" and no suspicious file there Oct 15 19:08:20 this will take a few minutes ... Oct 15 19:08:26 no problem Oct 15 19:08:40 i can try to hunt down that problem, bisect if needed Oct 15 19:08:47 but I need to reproduce anything first ;) Oct 15 19:11:47 yeah, definitely Oct 15 19:18:16 i'm doing the ubnt-erx, because the power plug is easier to get to Oct 15 19:18:44 also just sync'd up to master (i was a few days old) Oct 15 19:27:11 rmilecki: yeah, i see the same thing with a stock .config Oct 15 19:27:22 crap... Oct 15 19:27:37 the same thing being /overlay/upper/etc/config/dropbear is filled with nul's Oct 15 19:27:50 you sure you have 4.14? Oct 15 19:28:02 root@OpenWrt:~# uname -r Oct 15 19:28:03 4.14.75 Oct 15 19:28:13 Linux OpenWrt 4.14.75 #0 SMP Mon Oct 15 11:42:55 2018 mips GNU/Linux Oct 15 19:28:41 [ 0.536953] nand: Macronix MX30LF1G18AC Oct 15 19:28:43 [ 0.540814] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 Oct 15 19:28:46 and it's nand obviously Oct 15 19:28:58 russell--: are you attending summit? Oct 15 19:29:03 sadly no Oct 15 19:29:08 crap ;) Oct 15 19:30:23 this is my diffconfig: Oct 15 19:30:25 CONFIG_TARGET_ramips=y Oct 15 19:30:25 CONFIG_TARGET_ramips_mt7621=y Oct 15 19:30:25 CONFIG_TARGET_ramips_mt7621_DEVICE_ubnt-erx=y Oct 15 19:31:29 CONFIG_TARGET_bcm53xx=y Oct 15 19:31:30 CONFIG_TARGET_MULTI_PROFILE=y Oct 15 19:31:32 CONFIG_TARGET_ALL_PROFILES=y Oct 15 19:31:34 (...) Oct 15 19:31:35 CONFIG_TARGET_PER_DEVICE_ROOTFS=y Oct 15 19:31:37 CONFIG_PACKAGE_iperf=y Oct 15 19:31:38 CONFIG_PACKAGE_uclibcxx=y Oct 15 19:31:45 i've CONFIG_TARGET_PER_DEVICE_ROOTFS and all devices selected but it should not matter Oct 15 19:32:16 [ 1.205726] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xda Oct 15 19:32:16 [ 1.218371] nand: Macronix NAND 256MiB 3,3V 8-bit Oct 15 19:32:16 [ 1.227739] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 Oct 15 19:32:24 oh my, ramips has a lot of subtargets Oct 15 19:33:02 i've seen the same thing on the apm821xx meraki mr24 as well Oct 15 19:33:18 target/linux/ramips/patches-4.14/ doesn't look to scary, I think I could work on that one too Oct 15 19:34:32 russell--: with so many targets tested, it's hard to believe it's target specific Oct 15 19:34:38 but somehow I can't reproduce it Oct 15 19:34:57 ok and you use Macronix as well Oct 15 19:35:45 i thought i saw it on another device too, but i'm not remembering now which one it was ... looking... Oct 15 19:37:25 ah, yeah, the dir860l-b1, another ramips mt7621 based device Oct 15 19:38:27 ER-X is ~45 EUR here, affordable Oct 15 19:39:07 and the other NAND based device i have is an older mikrotik rb493g, ar71xx, but still on 4.9 and i don't see it there. Oct 15 19:39:33 yeah, they are about $50 here, i think the last time I got one it was $54. Oct 15 19:39:46 DIR-860L is not available in Poland anymore Oct 15 19:40:23 they went through a period of being super cheap, then kind of shot through the roof price wise Oct 15 19:40:42 i got a few for $30 a years or two ago Oct 15 19:41:07 mikrotik rb493g is expensive, about 150 EUR Oct 15 19:42:43 and outdated. lol, i have an amusing story. i got a volume price where the vendor had pretty clearly dropped a digit. I got 5 of them for $100 or something ridiculous. i kept expecting to get a sad email, but a few days later they arrived at the door. Oct 15 19:43:11 493g eh Oct 15 19:43:18 are all 9 ports switch ports? Oct 15 19:43:40 jwh: there are 9 ports on two switch chips Oct 15 19:44:07 so, ports on switch0 have to go through the cpu to get to ports on switch1 Oct 15 19:45:23 i used one as a gateway device for a few years, before the APU came along. Oct 15 19:47:12 ah Oct 15 19:47:50 looks like quite a nice device actually Oct 15 19:48:09 it had a few quirks Oct 15 21:56:31 russell--: russell-- https://github.com/openwrt/packages/pull/7200 Oct 15 21:59:08 that one didn't seemed cve-worthy. if patch segfaults, you are going to notice it, it's not going to crash the system. Oct 15 21:59:53 it's still listed as a CVE though Oct 15 22:07:07 make system doesn't notice when busybox-related configs have changed and so it doesn't rebuild Oct 15 22:07:26 (just ran into that again) Oct 15 22:09:35 Hello. Anyone know how to combine Kernel + squashfs to create a -factory.bin image? Oct 15 22:09:57 what target? Oct 15 22:10:09 ramips/mt7621 Oct 15 22:10:24 I'm developing support for Strong 1200 Oct 15 22:10:37 https://forum.openwrt.org/t/support-for-strong-1200/22768 Oct 15 22:11:32 The OEM firmware looks into the uImage header to get the kernel size and flash it Oct 15 22:11:42 My example: Oct 15 22:12:09 $ file openwrt_factory2.bin Oct 15 22:12:09 openwrt_factory2.bin: u-boot legacy uImage, WR1201_8_128, Linux/MIPS, OS Kernel Image (lzma), 1916595 bytes, Sun Oct 14 19:51:28 2018, Load Address: 0x80001000, Entry Point: 0x80001000, Header CRC: 0xE877B222, Data CRC: 0x9B9DA22A Oct 15 22:12:57 When I flash this image, the web portal report this: upgrade_fw cmd:/bin/mtd_write -o 186 -l 1916659 write /var/cgiqQN8YC Kernel Oct 15 22:13:01 one of the other subtargets probably has a factory image, could just enable it Oct 15 22:13:53 I've tried some other examples, but they don't feed my needs Oct 15 22:14:04 Most of them pad extra bytes at the end of Kernel Oct 15 22:14:28 yeah Oct 15 22:14:33 In my case, I need to "include" or combine with squashfs Oct 15 22:14:55 uimages should be universal enough though, since they have headers Oct 15 22:15:41 I tried manually hack the uImage header and increase the size of the kernel until the end of the file (kernel+squashfs), but the trick not work because of the offset... Oct 15 22:18:27 So my question is: There is some way to "combine" the kernel and squashfs? Oct 15 22:19:08 huh Oct 15 22:19:27 aren't there seperate mtd partitions for kernel and rootfs? Oct 15 22:19:40 nop Oct 15 22:19:48 the OEM have only Kernel xD Oct 15 22:19:56 what on earth Oct 15 22:20:09 you'd have to redefine that for openwrt anyway Oct 15 22:20:11 mtd0: 01000000 00010000 "ALL" Oct 15 22:20:11 mtd1: 00030000 00010000 "Bootloader" Oct 15 22:20:11 mtd2: 00010000 00010000 "Config" Oct 15 22:20:11 mtd3: 00010000 00010000 "Factory" Oct 15 22:20:12 mtd4: 00fa0000 00010000 "Kernel" Oct 15 22:20:13 mtd5: 00010000 00010000 "Second_Config" Oct 15 22:20:18 whats Factory? Oct 15 22:20:28 wifi calibration Oct 15 22:20:29 ah Oct 15 22:20:52 Config and Second_Config, the wifi propietary config Oct 15 22:23:23 "Kernel" can be named "firmware" in your dts Oct 15 22:23:56 Yes, already did Oct 15 22:24:01 ah knickrs Oct 15 22:24:03 knickers Oct 15 22:24:05 [2018-10-15 22:23:19.874]loader: failed to load 'ipoe': Error relocating /usr/lib/accel-ppp/libipoe.so: barrier: symbol not found Oct 15 22:24:08 so so close Oct 15 22:24:13 * jwh figures it out Oct 15 22:24:19 https://github.com/vk496/openwrt/blob/strong1200/target/linux/ramips/dts/STRONG-1201.dts#L100 Oct 15 22:26:49 aaahhh missed a #define (ugh) Oct 15 22:38:26 alright, can anyone tell me what this magic does? Oct 15 22:38:28 #define barrier() asm volatile ("" ::: "memory") Oct 15 22:38:55 is that some gcc-ism or actual standard syntax? Oct 15 22:46:49 uhh Oct 15 22:46:55 a memory barrier? Oct 15 22:47:04 yeah I figured it out now Oct 15 22:47:10 the triple colon threw me Oct 15 22:47:12 https://www.khronos.org/registry/OpenCL/sdk/1.0/docs/man/xhtml/barrier.html Oct 15 22:47:13 is insline asm Oct 15 22:47:16 inline Oct 15 22:47:41 I don't understand why they're doing it in the middle of constructing a dhcp packet, but I'm not coder Oct 15 22:47:46 no* Oct 15 22:48:04 maybe compiler bugs Oct 15 22:48:10 hm possibly Oct 15 22:48:17 that's the reason for it in OpenCL Oct 15 22:48:18 is that gonna work on all platforms? Oct 15 22:48:42 no clue. where is that from? Oct 15 22:49:08 https://github.com/xebd/accel-ppp/blob/master/accel-pppd/ctrl/ipoe/dhcpv4.c#L616 Oct 15 22:49:56 yeah that looks like it Oct 15 22:50:06 compiler bugs Oct 15 22:50:17 oh, old gcc or? Oct 15 22:50:29 most likely Oct 15 22:51:01 probably best to leave it since I don't understand the implications of removing it Oct 15 22:51:09 as long as it works on mips et al Oct 15 22:52:10 so what happens in OpenCL land is without barrier(), the compiler ends up wrecking the code and causes bad output. On the other hand, having it causes a speed drop Oct 15 22:52:12 still gotta fix this cmake horribleness, looks for libraries in all the wrong places Oct 15 22:52:19 oh hm Oct 15 22:52:31 guess I could just stick to only using it on x86 Oct 15 22:52:43 and its only dhcp anyway, soooo Oct 15 22:53:11 isn't called the dhcpv6 code, legacy perhaps (lots of that, it has compat as far back as 2.6.11 or something) Oct 15 23:02:20 patches are getting pretty silly, may have to just fork it instead Oct 15 23:17:14 alright so, I see.... Oct 15 23:17:29 -- Installing: /home/jwh/nspv2_build/build_dir/target-x86_64_musl/accel-ppp-15a3f694/ipkg-install/usr/lib/libshaper.so Oct 15 23:17:39 but then theres no usr/lib in .pkgdir Oct 15 23:17:44 how do the two related? Oct 15 23:17:46 relate* Oct 15 23:26:12 oh I see, as long as I create the dir in the Install portion of the makefile its ok Oct 15 23:31:30 oh hm Oct 15 23:31:30 Mon Oct 15 23:29:42 2018 daemon.err bird[14662]: bird: I found another BIRD running. Oct 15 23:31:33 anyone using bird2 yet? Oct 15 23:31:34 Mon Oct 15 23:29:42 2018 daemon.info procd: Instance bird::instance1 s in a crash loop 6 crashes, 0 seconds since last crash Oct 15 23:31:49 theres something up with the procd script, it doesn't terminate it either on stop Oct 15 23:37:24 http://ix.io/1pfK Oct 15 23:37:25 o/ **** ENDING LOGGING AT Tue Oct 16 02:59:59 2018