**** BEGIN LOGGING AT Mon May 24 03:00:16 2021
May 24 08:21:51 <rmilecki> we have 13 new commits in netfid since 21.02 branching: https://git.openwrt.org/project/netifd.git/shortlog/c00c8335d618..master
May 24 08:22:05 <rmilecki> do we wany some/any/all of them for 21.02?
May 24 08:22:11 <rmilecki> nbd Hauke
May 24 09:20:16 <Grommish> It's not OpenWrt, but given the audience, I figure I'd ask.  I'm looking for someone to work with me on a python Discord bot.  Anyone interested?
May 24 09:30:10 <rmilecki> jow: could you update openwrt-21.02 branch of LuCI?
May 24 09:30:30 <rmilecki> we surely need faad7464a8 luci-mod-network: add support for network.device sections
May 24 09:30:34 <rmilecki> and all friends
May 24 09:30:41 <rmilecki> Hauke: this is must have for the rc2 ^^
May 24 11:42:47 <Hauke> jow: do you plan to merge faad7464a8 into the 21.02 branch or do you want to wait till the bugs are fixed?
May 24 11:50:37 <rmilecki> Hauke: if needed be, we should wait with rc2 for LuCI update, network setup with LuCI is something that really should get a chance for getting tested before the last rc or so
May 24 13:01:03 <barhom> PaulFertser, lynxis: Apparently I missed that you replied to my question about squashfs errors 10 days ago. Found it in the logs. I use 32mb devices, and yes I did try to reboot a few thousand times. The culprit is happening at random on reboot. About 1-2% of my reboots result in squashfs errors and I have no idea on where to further investigate.
May 24 13:01:28 <barhom> For now I'm doing workaround and just rebooting the device one extra time if there are any errors
May 24 13:01:34 <PaulFertser> barhom: but then the next reboot just solves it magically?
May 24 13:01:40 <barhom> PaulFertser, yes exactly
May 24 13:01:57 <barhom> I've put 1 router into a sysupgrade loop and one into a reboot loop
May 24 13:02:03 <PaulFertser> barhom: and have you tried the same test but without doing sysupgrade?
May 24 13:02:18 <PaulFertser> I mean just rebooting thousand of times, without doing anything to squashfs.
May 24 13:02:37 <barhom> Yes, they behave the same. So by now Im stopping the sysupgrade loop and putting into into a reboot loop
May 24 13:03:10 <PaulFertser> The same means that a fully functional device that used to work fine might occassionally boot with those errors?
May 24 13:03:59 <barhom> Actions: Install software, boot router. Router does its first-time boot things like copy over the squashfs. Once it is done I reboot it endlessly
May 24 13:04:07 <barhom> 1-2% of the reboots boots in a bad state
May 24 13:04:54 <PaulFertser> That's plenty. Might be memory corruption. I'd also try to lower the SPI frequency to see if it changes anything.
May 24 13:05:24 <Pepe> While you are speaking guys about 21.02. When there will be a new releases of 19.07 with FragAttacks fixes?
May 24 13:06:42 <barhom> PaulFertser, the router is only doing the first-time-boot tasks the very first time. All subsequent reboots does not have this task as part of its boot process.
May 24 13:07:20 <PaulFertser> barhom: yes, I understand.
May 24 13:07:43 <barhom> Where would I need to downclock the SPI?
May 24 13:07:56 <PaulFertser> Board DTS
May 24 13:09:06 <barhom> is this effectively downclocking the whole cpu so that tasks like wireguard will run slower?
May 24 13:10:45 <PaulFertser> No, I mean downclocking just the communication with flash IC for testing if it might be the problem.
May 24 13:17:57 <barhom> I'll try that now thanks
May 24 13:25:21 <barhom> PaulFertser, you mean this field right? https://github.com/openwrt/openwrt/blob/7131f5a2fb5df0235657285596eaee7453bd36e4/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts#L158
May 24 13:30:42 <PaulFertser> barhom: yes, that's it. 24 MHz is already looking slow.
May 24 13:30:48 <barhom> isnt 24mhz quite slow already?
May 24 13:30:58 <barhom> ok you beat me to that
May 24 13:31:08 <PaulFertser> That's surprising I have to admit.
May 24 13:31:20 <barhom> you think going too slow can also cause errors?
May 24 13:31:30 <PaulFertser> I doubt that.
May 24 13:32:06 <PaulFertser> That's their reference dev board?
May 24 13:32:39 <barhom> tbh I'm not sure. This is what we use, https://deviwiki.com/wiki/GL.iNet_GL-B1300
May 24 13:32:56 <barhom> The ones we have is IPQ4028 and IPQ4018 both uses the same flash
May 24 13:33:47 <barhom> with flash, I mean we use the same sysupgrade files that we make. Both show the same issue
May 24 13:33:51 <PaulFertser> I see. No real idea about it. Have you probably tried running some userspace memtest implementation for a while?
May 24 13:34:03 <barhom> I did not
May 24 13:34:08 <PaulFertser> I would
May 24 13:37:23 <barhom> alright, I will do that. For now I've added a workaround that simply reboots if the issue happens. But the way I detect a "bad state" is not so good
May 24 17:10:38 <pmelange> Hey, are you around?
May 24 17:11:11 <pmelange> oops, I meant to send that as a pm :)
May 24 19:27:09 <barhom> Can you build for multiple target system (not target profile) at the same time?
May 24 19:46:29 <por> bye
May 24 19:47:24 <aparcar[m]> barhom: no, you can only build for one at the same time
May 24 23:13:30 <Pepe> Guys, can anyone take a look at my patch - https://patchwork.ozlabs.org/project/openwrt/patch/20210501065112.99433-1-pepe.schlehofer@gmail.com/ ? It should be merged as it could be related to security vulnerability - KrØØk.
May 24 23:23:30 <slh> Pepe: at least brcmfmac-firmware-43455-sdio seems to be still used by device in the sunxi target (maybe also RPi), brcmfmac-firmware-43455-sdio apparently as well
May 25 01:11:28 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 98.1% packages reproducible in our current test framework.)
**** ENDING LOGGING AT Tue May 25 03:01:36 2021