**** BEGIN LOGGING AT Sat Dec 08 03:00:01 2018
Dec 08 03:24:20 <owrt-snap-builds> build #1142 of x86/geode is complete: Success [build successful]  Build details are at http://phase1.builds.lede-project.org/builders/x86%2Fgeode/builds/1142
Dec 08 03:32:42 <owrt-snap-builds> build #1133 of archs38/generic is complete: Success [build successful]  Build details are at http://phase1.builds.lede-project.org/builders/archs38%2Fgeneric/builds/1133
Dec 08 06:31:36 <owrt-snap-builds> build #237 of at91/sama5d4 is complete: Failure [failed targetupload]  Build details are at http://phase1.builds.lede-project.org/builders/at91%2Fsama5d4/builds/237  blamelist: Romain MARIADASSOU <roms2000@free.fr>
Dec 08 08:53:50 <owrt-snap-builds> build #1120 of ipq806x/generic is complete: Success [build successful]  Build details are at http://phase1.builds.lede-project.org/builders/ipq806x%2Fgeneric/builds/1120
Dec 08 10:30:09 <Borromini> xback: ping
Dec 08 11:20:03 <Borromini> ldir: ping
Dec 08 11:30:03 <russell--> hmm. i'm getting boot failures on (mt7621) dir860l-b1 and (apm821xx) meraki mr24, both look pretty close to the same:
Dec 08 11:30:06 <russell--> [    4.775662] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
Dec 08 11:30:09 <russell--> [    4.790565] Please append a correct "root=" boot option; here are the available partitions:
Dec 08 11:30:30 <russell--> both are nand/ubi
Dec 08 11:35:18 <russell--> sometime since Nov 15, when i built last
Dec 08 11:35:26 <Borromini> russell--: master i presume?
Dec 08 11:47:51 <russell--> Borromini: yes
Dec 08 11:49:05 <Borromini> ok
Dec 08 11:49:20 <russell--> oh, wait. dir860l isn't nand
Dec 08 11:49:25 <Borromini> i've kept an eye on the master commits but since it's not mt7621 specific...
Dec 08 11:49:28 <Borromini> no it's not
Dec 08 11:49:28 <Borromini> i have one myself
Dec 08 11:49:36 <Borromini> but on 18.06 head
Dec 08 11:49:56 <russell--> was booting a few weeks ago
Dec 08 11:52:44 <russell--> ath79 devices don't seem to be affected, fwiw
Dec 08 11:54:17 <russell--> ah, it looks like the firmware splitting isn't happening
Dec 08 11:55:49 <Borromini> lots of that being committed lately
Dec 08 11:56:58 <russell--> https://pastebin.com/C1hfRUC7
Dec 08 11:59:42 <owrt-snap-builds> build #302 of mediatek/mt7623 is complete: Success [build successful]  Build details are at http://phase1.builds.lede-project.org/builders/mediatek%2Fmt7623/builds/302
Dec 08 12:17:28 <russell--> trying dirclean/rebuild
Dec 08 12:20:08 <russell--> aha
Dec 08 12:20:40 <russell--> commit d70ec3008d4cd0540a9f6c88fb7e786107f1679a added a compatibility string, but looks like the wrong one
Dec 08 12:23:39 <russell--> on dir860l-b1 from nov 15: [    3.224404] 2 seama-fw partitions found on MTD device firmware
Dec 08 12:29:35 <Borromini> seama was stripped i read in some of the commits...
Dec 08 12:31:08 <russell--> there are some ramips dts with compatible = "seama"
Dec 08 12:31:15 * russell-- is trying that
Dec 08 12:32:41 <russell--> CONFIG_MTD_SPLIT_SEAMA_FW=y in the build_dir
Dec 08 12:39:06 <russell--> mkresin: not that i would have caught it, but looking now I don't see that commit went through the mailing list
Dec 08 12:47:07 <Borromini> russell--: does that fix it?
Dec 08 12:47:22 <russell--> found the github pull request
Dec 08 12:47:42 <russell--> just finished building, flashing nowis
Dec 08 12:47:43 <russell--> h
Dec 08 12:49:59 <russell--> yes, that fixes it
Dec 08 12:50:24 <Borromini> :)
Dec 08 12:51:39 * russell-- wonders how many more from that commit are broken
Dec 08 12:56:21 <Borromini> only one way to find out i reckon...
Dec 08 12:57:29 * russell-- sends patch to mailing list
Dec 08 13:04:38 <owrt-snap-builds> build #1150 of brcm2708/bcm2710 is complete: Success [build successful]  Build details are at http://phase1.builds.lede-project.org/builders/brcm2708%2Fbcm2710/builds/1150
Dec 08 13:08:49 <russell--> not sure about the meraki mr24 though... not the same problem.
Dec 08 13:10:05 <Borromini> not printing the partition types?
Dec 08 13:17:30 * russell-- is going to guess it is this commit f6968952df36bb21addabe183def2368919b66ab
Dec 08 13:20:15 <nbd> russell--: thanks for the dir-860l b1 fix. people were already complaining on mt76 github about current builds bricking their devices
Dec 08 13:20:26 <nbd> and i couldn't find the power supply for my router ;)
Dec 08 13:24:08 <owrt-snap-builds> build #1139 of omap/generic is complete: Success [build successful]  Build details are at http://phase1.builds.lede-project.org/builders/omap%2Fgeneric/builds/1139
Dec 08 13:25:45 * russell-- recalls it is a funny size
Dec 08 13:28:07 <russell--> getting to the serial console on the dir860l-b1 is kind of a pain-in-the-ass due to the annoying case construction
Dec 08 13:31:30 <Borromini> russell--: that commit didn't break the bootloader as well did it?
Dec 08 13:31:37 * Borromini likes the http recovery
Dec 08 13:33:05 <russell--> Borromini: i have a serial console on mine
Dec 08 13:33:16 <russell--> bootloader is fine
Dec 08 13:50:30 <russell--> meraki mr24 is a false alarm, newly build image flashed fine
Dec 08 13:51:43 <russell--> unfortunately my console log was not active at the time for clues to what happened, fortunately my memory is short so i'll just happily wait until it happens again
Dec 08 14:07:56 <russell--> bash: $TOPDIR/staging_dir/host/bin/mksquashfs-lzma: No such file or directory
Dec 08 14:09:16 <Borromini> :)
Dec 08 14:10:29 <russell--> make tools/squashfs/{clean,compile}
Dec 08 14:30:35 <Borromini> master needs that once in a while
Dec 08 14:41:24 * russell-- senses a missing dependency
Dec 08 14:48:15 <russell--> btw, what's the best way of finding the tty name for a particular uart?
Dec 08 14:48:31 <russell--> e.g. i want the tty associated with uart2
Dec 08 14:49:15 <russell--> at the moment uart1 is disabled, so uart2 ends up at /dev/ttyS1, but it would be nice to be robust against changes in uart1
Dec 08 15:01:03 <Borromini> no idea sorry.
Dec 08 15:35:45 <Monkeh> russell--: Somewhere in /sys should contain the information you seek
Dec 08 15:38:44 <Monkeh> russell--: You could look at /sys/class/tty/ttySx/device, for example
Dec 08 16:30:33 <owrt-snap-builds> build #333 of ipq40xx/generic is complete: Failure [failed pkgbuild]  Build details are at http://phase1.builds.lede-project.org/builders/ipq40xx%2Fgeneric/builds/333  blamelist: Russell Senior <russell@personaltelco.net>, Ansuel Smith <ansuelsmth@gmail.com>
Dec 08 17:05:29 <Hauke> nbd: I am currently looking at this patch: target/linux/generic/pending-4.14/341-MIPS-mm-remove-no-op-dma_map_ops-where-possible.patch
Dec 08 17:06:18 <Hauke> in kernel 4.19 mips uses the generic dma code and it looks like CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU and CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU_ALL are doing the same as your DMA_UNMAP_POST_FLUSH
Dec 08 17:06:23 <Hauke> here https://elixir.bootlin.com/linux/v4.19.8/source/kernel/dma/noncoherent.c#L95
Dec 08 17:07:00 <Hauke> but CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU is only set for one MIPS SoC line  and not for all the others in mips
Dec 08 17:27:33 <nbd> Hauke: ARCH_HAS_SYNC_DMA_FOR_CPU is selected by DMA_NONCOHERENT
Dec 08 17:28:11 <nbd> Hauke: so some changes to the kconfig selection are needed to get back the results of my patch
Dec 08 17:31:10 <Hauke> nbd: ok thanks
Dec 08 17:31:23 <nbd> Hauke: the symbol should be selected by CPU_R10000 and BMIPS_GENERIC
Dec 08 17:31:49 <nbd> or rather: SYS_HAS_CPU_R10000
Dec 08 17:32:07 <nbd> and SYS_HAS_CPU_BMIPS
Dec 08 17:32:18 <Hauke> ok I will restore your dehavior
Dec 08 17:32:25 <Hauke> your seletions
Dec 08 17:46:44 <owrt-snap-builds> build #238 of at91/sama5d4 is complete: Success [build successful]  Build details are at http://phase1.builds.lede-project.org/builders/at91%2Fsama5d4/builds/238
Dec 08 18:00:16 <zorun> uh
Dec 08 18:00:32 <zorun> I'm running tests with OpenWrt as a LXC container (on a Debian host, so it's Debian's kernel)
Dec 08 18:01:14 <zorun> and in a forwarding performance test, OpenWrt is almost twice as fast as the Debian host itself
Dec 08 18:01:37 <zorun> strange but interesting :)
Dec 08 18:08:36 <zorun> hmm, it's a 4 cores system (PCEngines APU2), maybe it's just a matter of configuring which CPU receives the IRQ
Dec 08 20:26:11 <Hauke> nbd: is this needed for all bmpis CPUs, or only for the BMIPS5000 listed in cpu_needs_post_dma_flush() ?
Dec 08 20:38:46 <nbd> Hauke: i guess BMIPS5000 is enough
Dec 08 20:39:31 <Hauke> nbd: ok
Dec 08 21:27:09 <rmilecki> russell--: thanks for the .dts fix
Dec 08 22:26:06 <owrt-snap-builds> build #1038 of pistachio/generic is complete: Failure [failed updatefeeds]  Build details are at http://phase1.builds.lede-project.org/builders/pistachio%2Fgeneric/builds/1038  blamelist: Russell Senior <russell@personaltelco.net>, Ansuel Smith <ansuelsmth@gmail.com>
Dec 09 00:36:25 <russell--> not my fault! ;-)
Dec 09 00:37:26 <russell--> also, that report link (http://phase1.builds.lede-project.org/builders/pistachio%2Fgeneric/builds/1038) really ought to have clickable links
Dec 09 00:38:27 <russell--> and i mean to the blamed commits
Dec 09 00:40:26 <russell--> fatal: unable to access 'https://git.openwrt.org/feed/telephony.git/': Couldn't connect to server
Dec 09 00:41:23 <russell--> rmilecki: no prob
**** ENDING LOGGING AT Sun Dec 09 03:00:01 2018