**** BEGIN LOGGING AT Sat Apr 04 03:00:20 2020
Apr 04 04:09:05 <owrt-snap-builds> build #265 of rb532/generic is complete: Failure [failed kmods]  Build details are at http://buildbot.openwrt.org/master/images/builders/rb532%2Fgeneric/builds/265  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Tim Harvey <tharvey@gateworks.com>, Paul Spooren <mail@aparcar.org>, Tan Zien <nabsdh9@gmail.com>
Apr 04 05:13:10 <owrt-snap-builds> build #276 of ramips/mt76x8 is complete: Failure [failed kmods]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt76x8/builds/276  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Tim Harvey <tharvey@gateworks.com>, Paul Spooren <mail@aparcar.org>, Tan Zien <nabsdh9@gmail.com>
Apr 04 06:21:44 <Tapper> umdns still fails to build under gcc 8
Apr 04 06:22:08 <Tapper> home/tapper/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/umdns-2018-01-02-78974417/dns.c:261:2: error: converting a packed 'struct dns_question' pointer (alignment 1) to a 'uint16_t' {aka 'short unsigned int'} pointer (alignment 2) may result in an unaligned pointer value [-Werror=address-of-packed-member]
Apr 04 06:22:08 <Tapper>   261 |  uint16_t *swap = (uint16_t *) q;
Apr 04 06:22:08 <Tapper> /home/tapper/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/umdns-2018-01-02-78974417/dns.c:261:2: error: converting a packed 'struct dns_question' pointer (alignment 1) to a 'uint16_t' {aka 'short unsigned int'} pointer (alignment 2) may result in an unaligned pointer value [-Werror=address-of-packed-member]
Apr 04 06:22:08 <Tapper>   261 |  uint16_t *swap = (uint16_t *) q;
Apr 04 06:37:42 <acalvo> how can I provide a partition list for an eMMC-based device?
Apr 04 06:42:56 <owrt-snap-builds> build #255 of layerscape/armv7 is complete: Failure [failed kmods]  Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv7/builds/255  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Tim Harvey <tharvey@gateworks.com>, Paul Spooren <mail@aparcar.org>, Tan Zien <nabsdh9@gmail.com>
Apr 04 07:01:12 <mangix> Tapper: i believe that's a GCC9 error
Apr 04 07:01:52 <Tapper> https://bugs.openwrt.org/index.php?do=details&task_id=2960https://bugs.openwrt.org/index.php?do=details&task_id=2960
Apr 04 07:02:12 <Tapper> It is when building with gcc8
Apr 04 07:02:20 <Tapper> I have tryed both
Apr 04 07:07:20 <Tapper> mangix should I try gcc 7?
Apr 04 07:30:14 <ldir> Tapper: can you run  grep 'CONFIG_GCC_USE_VERSION.*=y' .config  in your openwrt build top directory please
Apr 04 07:30:35 <Tapper> OK stand by
Apr 04 07:31:35 <Tapper> It's going to show gcc 9 now because I removed umdns from my config and built a new build with no luci-app-dawn dawn or umdns
Apr 04 07:31:48 <Tapper> and switched back to gcc 9
Apr 04 07:32:21 <Tapper> Would you like me to switch back to gcc 8 and then do a make dirclean than run that cammand?
Apr 04 07:33:14 <ldir> try switching to gcc 8, then run that command - don't do anything else...yet
Apr 04 07:33:24 <Tapper> OK hang on
Apr 04 07:33:55 <Tapper> So run make menuconfig make the switch close and save then run that camande
Apr 04 07:34:02 <ldir> yes please
Apr 04 07:34:11 <Tapper> k
Apr 04 07:36:30 <Tapper> config gcc version =y
Apr 04 07:36:39 <Tapper> gcc8*
Apr 04 07:37:48 <ldir> ok, so it does actually switch.  Hmmmm.  Go back to 9 and I'll have a think
Apr 04 07:38:44 <Tapper> CONFIG_GCC_USE_VERSION_8=Y
Apr 04 07:38:56 <Tapper> k
Apr 04 07:39:18 <ldir> if any consolation, it fails for me on x86_64 as well :-)
Apr 04 07:40:20 <Tapper> ldir ok thanks for letting me know I am not mad! lol Well....
Apr 04 07:40:31 <Tapper> Just a bit mad!
Apr 04 07:40:33 <Tapper> lol
Apr 04 07:41:31 <ldir> like the rest of us
Apr 04 07:41:52 <Tapper> ldir I posted the bug to FS
Apr 04 07:42:01 <Tapper> did you see the link?
Apr 04 07:42:33 <Tapper> Should I add what we just did?
Apr 04 07:43:11 <ldir> no, it's not really relevant.  I just wanted to check that switching to gcc8 actually did switch :-)
Apr 04 07:43:19 * Tapper nods
Apr 04 07:43:37 <ldir> not that I don't trust you, or you in particular, I don't trust anyone... even myself :-)
Apr 04 07:47:04 <Tapper> lol I did not take it that way any way mate.
Apr 04 07:51:44 <Tapper> TrenchBoot - Open Source DRTM for AMD processors.
Apr 04 07:51:49 <Tapper> https://blog.3mdeb.com/2020/2020-03-31-trenchboot-nlnet-lz/
Apr 04 07:52:16 <Tapper> there test box is a  PC Engines apu2
Apr 04 08:14:08 <ldir> Tapper: I updated the flyspray with a workaround
Apr 04 08:14:30 <Tapper> OK cool I will look now thanks
Apr 04 08:18:52 <Tapper> I am not sure how to make that work around so I will wait for it to be fixt. At lest we know what's rong now.
Apr 04 08:29:24 <ldir> edit package/network/services/umdns/Makefile  and add -Wno-address-of-packed-member  to the end of the TARGET_CFLAGS line
Apr 04 08:36:20 <aparcar[m]> Anyone an idea how I can add a file per profile rootfs? I can't find the right place in the build root
Apr 04 08:52:36 <ldir> aparcar[m]: not me - clueless :-)
Apr 04 08:53:15 <aparcar[m]> :'(
Apr 04 08:54:01 <aparcar[m]> blogic: ping
Apr 04 09:06:51 <ldir> PaulFertser: any suggestion of how to fix properly?
Apr 04 09:09:20 <ldir> I had a horrible idea of using memcpy to copy the pointer value to our swap pointer but that just seemed hideous :-)
Apr 04 09:21:22 <PaulFertser> ldir: I think be16_to_cpu should be getting a uint8_t* pointer and do its job in-place.
Apr 04 09:22:09 <PaulFertser> (probably not in general case but in this specific place)
Apr 04 09:23:19 <PaulFertser> ldir: hm, in this specific case all the struct members are indeed uint16_t and larger so probably the warning is bugos.
Apr 04 09:25:25 <PaulFertser> ldir: it's strange endianness is hardcoded to 2. Something's weird about that code. And why the other similar places get no complaints.
Apr 04 09:26:27 <ldir> ha, yes, it took me a little while to work that out too.  It's the number of endian swap we want to do... it moves the pointer by 2 bytes every iteration.
Apr 04 09:26:44 <ldir> I think it's a bizarrely named variable
Apr 04 09:27:07 <PaulFertser> Yes, but why not taking into account the size of the struct? Or why not make it field-by-field?..
Apr 04 09:28:55 <ldir> don't know - am not a C god
Apr 04 09:29:38 <PaulFertser> And dns_header is not packed
Apr 04 09:30:03 <PaulFertser> consume_answer does it in a saner way I'd say
Apr 04 09:30:47 <PaulFertser> Both consume_question and consume_header should probably look more like consume_answer.
Apr 04 09:34:56 <acalvo> does anyone know how to get binary data to create a ipq-wifi-$DEVICE for ath10k from original firmware?
Apr 04 09:35:01 <PaulFertser> I guess I'd try adding attribute packed to dns_header too for consistency even though it should be naturally packed, but to be explicit.
Apr 04 10:08:56 <owrt-snap-builds> build #54 of bcm63xx/smp is complete: Failure [failed kmods]  Build details are at http://buildbot.openwrt.org/master/images/builders/bcm63xx%2Fsmp/builds/54  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Tan Zien <nabsdh9@gmail.com>
Apr 04 10:11:25 <owrt-snap-builds> build #51 of bcm63xx/generic is complete: Failure [failed kmods]  Build details are at http://buildbot.openwrt.org/master/images/builders/bcm63xx%2Fgeneric/builds/51  blamelist: Tan Zien <nabsdh9@gmail.com>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Chuanhong Guo <gch981213@gmail.com>, Rafa? Mi?ecki <rafal@milecki.pl>, INAGAKI Hiroshi
Apr 04 10:11:25 <owrt-snap-builds> <musashino.open@gmail.com>, Ren? van Dorst <opensource@vdorst.com>
Apr 04 10:11:40 <ldir> PaulFertser: patches welcome
Apr 04 10:30:16 <PaulFertser> ldir: please test: http://paste.debian.net/1138373/
Apr 04 10:33:56 <ldir> PaulFertser: thanks - probably look at that tomorrow now :-)
Apr 04 10:34:25 <PaulFertser> ldir: thank you!
Apr 04 10:43:36 <owrt-snap-builds> build #357 of ath25/generic is complete: Failure [failed kmods]  Build details are at http://buildbot.openwrt.org/master/images/builders/ath25%2Fgeneric/builds/357  blamelist: Tan Zien <nabsdh9@gmail.com>, DENG Qingfang <dengqf6@mail2.sysu.edu.cn>, Chuanhong Guo <gch981213@gmail.com>, Thibaut VAR?NE <hacks@slashdirt.org>, Rafa? Mi?ecki
Apr 04 10:43:36 <owrt-snap-builds> <rafal@milecki.pl>, INAGAKI Hiroshi <musashino.open@gmail.com>, Ren? van Dorst <opensource@vdorst.com>
Apr 04 10:47:18 <Tapper> ldir thanks for pushing that change mate
Apr 04 10:47:27 <Tapper> Just kicked off a build.
Apr 04 10:58:10 <gch981213> acalvo: It's under /lib/firmware/{chipname}/hw.X/ in the original fw. There are some files whose name starts with boardData (not boarddata). You need to extract the file and pack it with: https://github.com/qca/qca-swiss-army-knife/blob/master/tools/scripts/ath10k/ath10k-bdencoder
Apr 04 11:17:14 <mangix> gch981213: I have a crazy feeling sysupgrade will be broken with this mt7621 update for some devices
Apr 04 11:17:41 <mangix> I remember having to add broken-flash-reset or similar in the DTS to fix it.
Apr 04 11:28:05 <gch981213> mangix: MX25L25635F and W25Q256 both have proper 4B_OPCODE support in 5.4, which should fix reboot on devices with these flash.
Apr 04 11:30:26 * gch981213 is digging out some routers for testing from his closet
Apr 04 11:41:28 * gch981213 got a brick :(
Apr 04 11:42:43 <gch981213> Not really a brick. I can't write anything to W25Q256
Apr 04 11:50:48 <gch981213> Turns out W25Q256FV doesn't have a 4B page program opcode available.
Apr 04 12:14:31 <blocktrron> gch981213: Aruba has integrated the boardData into their WiFi kmod, so no boarddata in filesystem.
Apr 04 12:15:00 <blocktrron> I'm not sure if others opt to take the same approach
Apr 04 12:25:52 <gch981213> blocktrron: Oh. That's annoying... QCA loads boarddata from file in their QSDK. I thought no vendor would bother modifying this.
Apr 04 12:34:13 <acalvo> @gch981213 you're a livesaver... I was trying to pack it myself and didn't work at all
Apr 04 12:37:08 <acalvo> also trying to get a eMMC-based device to load a partition scheme (/proc/mtd is empty), and so far the only solution I've found is to use block2mtd, but it does not build either built-in or as a module. Any hint to build it?
Apr 04 12:45:39 <f00b4r0> gch981213: why did you disable RBM 11G? It's a single port device, I guess that's why no switch was defined in DTS.
Apr 04 12:46:59 <gch981213> f00b4r0: The problem is that we don't know exactly which switch port is wired to that single port available because previous config just disables switch vlan.
Apr 04 12:47:26 <gch981213> f00b4r0: Do you have that device available?
Apr 04 12:47:28 <f00b4r0> I guess that's the case for a lot of these single-port devices
Apr 04 12:47:54 <f00b4r0> unfortunately I don't and I tried pinging the original submitter a couple weeks ago: no reply
Apr 04 12:48:13 <gch981213> f00b4r0: There are only 2 of them in mt7621 and we managed to figure out port assignment on the other one.
Apr 04 12:48:25 <f00b4r0> gch981213: just for my understanding, this is a side effect of DSA?
Apr 04 12:48:34 <gch981213> f00b4r0: Correct.
Apr 04 12:48:41 <f00b4r0> yum ;P
Apr 04 12:49:24 <gch981213> There can be an ugly solution: Just bridge all 5 switch ports as lan. I don't like this one.
Apr 04 12:49:40 <f00b4r0> what's the drawback?
Apr 04 12:49:56 <f00b4r0> (besides it being "unpure" ;))
Apr 04 12:50:46 <gch981213> f00b4r0: nothing else.
Apr 04 12:51:30 <gch981213> I hope by disabling this image some users with this router can paste me a kernel log.
Apr 04 12:51:49 <f00b4r0> well I think it should be seriously considered then. Because disabling isn't helping. Especially since bridging will be required to get to a shell prompt anyway
Apr 04 12:53:29 <gch981213> f00b4r0: Oh. The other drawback is that failsafe won't be available if the port isn't on port 0. failsafe only take the first lan interface instead of bridging them all together.
Apr 04 12:54:02 <f00b4r0> ha.
Apr 04 12:55:27 <f00b4r0> well imho a note in the commit message explaining how to bridge and what is required of the users would have helped. Bear in mind that not all end users are power users and even fewer know what's going on
Apr 04 12:56:19 <f00b4r0> gch981213: I'm assuming pre-DSA dmesg is useless? (I have that in my mail archive)
Apr 04 12:56:54 <gch981213> f00b4r0: ! It's useful as long as you got the eth port plugged in.
Apr 04 12:57:00 <f00b4r0> lemme check
Apr 04 13:04:50 <f00b4r0> I can't seem to find it :(
Apr 04 13:04:59 <f00b4r0> gch981213: I don't know if that helps, the original commit says:
Apr 04 13:05:00 <f00b4r0> The single onboard Ethernet port is connected the CPU directly.
Apr 04 13:05:00 <f00b4r0> The internal switch of the mt7621 SoC is disabled.
Apr 04 13:07:04 <gch981213> f00b4r0: It's not directly connected. 5 built-in PHY connects to the built-in mt7530 switch.
Apr 04 13:07:50 <gch981213> In old swconfig driver, disabling a switch means isolating all ports and forwarding packets only to CPU.
Apr 04 13:08:07 <f00b4r0> i see
Apr 04 13:08:27 <f00b4r0> one last thing I can try: looking at mikrotik's kernel patch see if I can extract the info from there
Apr 04 13:21:03 <f00b4r0> gch981213: it appears to be port 0.
Apr 04 13:22:23 <f00b4r0> which is the port that for the other 2 devices openwrt define as "wan", which makes sense
Apr 04 13:58:52 <gch981213> f00b4r0: I just saw a blog post about using RBM33G image on RBM11G: https://www.ttl.one/2018/08/installing-openwrtrooter-on-rbm33grbm11g.html
Apr 04 13:59:43 <gch981213> f00b4r0: which suggests that wan is not the port or users won't be able to access luci.
Apr 04 14:00:03 <gch981213> *port0 which is wan on RBM33G
Apr 04 14:11:17 <f00b4r0> gch981213: from mikrotik's sources:
Apr 04 14:11:17 <f00b4r0> +static struct platform_device *m11_devices[] = {
Apr 04 14:11:17 <f00b4r0> +       &(struct platform_device){
Apr 04 14:11:17 <f00b4r0> +           .name = "mt7621-eth",
Apr 04 14:11:17 <f00b4r0> +           .id = -1,
Apr 04 14:11:17 <f00b4r0> +           .dev = {
Apr 04 14:11:19 <f00b4r0> +               .platform_data = (int[]){0, -1},
Apr 04 14:11:21 <f00b4r0> +           },
Apr 04 14:11:23 <f00b4r0> +       },
Apr 04 14:11:27 <f00b4r0> +static struct platform_device *m33_devices[] = {
Apr 04 14:11:29 <f00b4r0> +       &(struct platform_device){
Apr 04 14:11:31 <f00b4r0> +           .name = "mt7621-eth",
Apr 04 14:11:33 <f00b4r0> +           .id = -1,
Apr 04 14:11:35 <f00b4r0> +           .dev = {
Apr 04 14:11:37 <f00b4r0> +               .platform_data = (int[]){0, 1, 2, -1},
Apr 04 14:13:12 <f00b4r0> gch981213: the post you link shows all steps performed on a 33G, nowhere does it show a successful procedure with 11G booting the 33G image
Apr 04 14:14:24 <f00b4r0> gch981213: nor does it say you can use the same image on both, unless I'm blind
Apr 04 15:15:18 <gch981213> f00b4r0: That's my wild guessing: the blog post has an RBM11G picture on top but all other pictures says RBM33G.
Apr 04 15:17:04 <gch981213> I don't feel quite comfortable to take the risk of a potentially broken image unless it's easy enough for end users to unbrick it.
Apr 04 15:29:35 <f00b4r0> gch981213: you'd rather trust a random blog post than the actual upstream code? And entirely disable the image instead of implementing a harmless fix? The routerboards can _always_ tftp boot, as long as the bootloader hasn't been wiped
Apr 04 15:29:44 <f00b4r0> odd. but your call.
Apr 04 15:49:37 <mrkiko> gch981213: out of curiosity, seems ramips porting to 5.4 is approaching the end!
Apr 04 15:50:02 <mrkiko> gch981213: congrats for your work guys... @paraka also worked a lot on the pci side
Apr 04 15:50:35 <gch981213> f00b4r0: Oh. I'll revert that commit later if tftp recovery without serial console is available.
Apr 04 15:51:22 <gch981213> I was thinking about some tp-link routers where one needs to take it apart and solder some serial console wires to unbrick it.
Apr 04 15:51:38 <gch981213> Now I noticed that this is just a board without enclosure.
Apr 04 15:57:02 <gch981213> mrkiko: Not quite finished yet. Still several subtargets to work on :P
Apr 04 15:58:53 <mrkiko> gch981213: thank you for taking care about ease of recovery - itn's not widespread enough attitude in my opinion. Oh, I was thinking youwould port MT7621 only
Apr 04 16:01:20 <mrkiko> happy to know that's not the case
Apr 04 16:36:35 <Toomoch> where is the mtd-utils package in the menuconfig? I can't find it
Apr 04 16:37:57 <mrkiko> Toomoch: base?
Apr 04 16:41:08 <Toomoch> mrkiko: sorry but I don't know what do you mean, kind of a noob here
Apr 04 16:43:52 <Toomoch> in base system there is mtd, but not mtd-tools
Apr 04 16:47:54 <PaulFertser> Toomoch: you can try pressing / then search
Apr 04 16:48:37 <PaulFertser> Toomoch: mtd-utils
Apr 04 16:49:46 <Toomoch> PaulFertser: nothing came up
Apr 04 16:50:07 <PaulFertser> Toomoch: it's in Utilities
Apr 04 16:50:20 <PaulFertser> Toomoch: depends on NAND support enabled
Apr 04 16:51:17 <Toomoch> PaulFertser: I think I got it, maybe it's called nand-utils?
Apr 04 16:51:46 <Toomoch> nand support should be enabled as the device detects the nand chip
Apr 04 16:51:47 <f00b4r0> gch981213: routerboards are the easiest thing to unbrick. You really have to try hard to wreck them :)
Apr 04 16:51:56 <PaulFertser> Toomoch: hm right
Apr 04 16:54:36 <f00b4r0> (to the point I don't even bother soldering serial when I port a new one ;)
Apr 04 17:05:52 <f00b4r0>      Mellanox Technologies MLX5 SRIOV E-Switch support (MLX5_ESWITCH) [Y/n/?] (NEW) aborted!
Apr 04 17:06:13 <f00b4r0> seems there's a missing config in generic 4.14 config
Apr 04 18:38:21 <owrt-snap-builds> build #323 of ramips/rt3883 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt3883/builds/323
Apr 04 22:55:18 <owrt-snap-builds> build #322 of ramips/rt288x is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt288x/builds/322
Apr 04 23:07:58 <acalvo> is there any device that uses eMMC only to take a look at how they define partitions with MTD?
Apr 05 00:45:09 <pkgadd> acalvo: they don't, at all. GPT partition tables (or DOS partition tables)
Apr 05 00:46:37 <pkgadd> acalvo: e.g. https://github.com/pkgadd/nbg6817
Apr 05 01:26:05 <russell--> has anybody figured out the gpio-button-hotplug problem yet? it seems toolchain related.
Apr 05 01:29:29 <russell--> FATAL: parse error in symbol dump file
Apr 05 01:41:11 <owrt-snap-builds> build #255 of ramips/mt7620 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt7620/builds/255
Apr 05 02:40:59 <dengqf6> russell--: clean build
Apr 05 02:42:02 <russell--> i found something slightly short of dirclean that worked, but it would be nicer to find the actual thing that needs rebuilding and just do that
**** ENDING LOGGING AT Sun Apr 05 02:59:58 2020