**** BEGIN LOGGING AT Mon Jul 22 03:02:02 2019 Jul 22 03:24:18 and again 19.07 no latest mt76 Jul 22 04:15:30 DonkeyHotei: some log please/ Jul 22 04:15:43 DonkeyHotei: DT + log ideally Jul 22 04:16:56 i don't think i still have a log, but you can see what i was trying to do here: https://github.com/danielg4/openwrt/blob/bsap1920-testing/target/linux/ath79/dts/ar9344_adtran_bsap192x.dtsi#L38 Jul 22 04:18:04 all devices currently supported for "advanced reboot" have either nand or emmc Jul 22 04:18:28 this one is spi-nor/jffs2 Jul 22 04:22:31 DonkeyHotei: well, if you claim both partiitons should be parsed, don't be surprised if that's what happens ;) Jul 22 04:22:40 DonkeyHotei: i see nothing wrong in kernel behavior there Jul 22 04:23:12 DonkeyHotei: i see two solutions for this Jul 22 04:23:27 1) extra code picking the right rootfs & rootfs_data pair Jul 22 04:23:46 2) maybe a custom binding like, adtran,uimage Jul 22 04:24:02 which will use driver that checks which "firmware" partition is the one to use Jul 22 04:24:36 i have trouble imagining solution #1 without spaghetti Jul 22 04:25:58 #2 sounds a lot better, but there shouldn't be a hardcoded method for determining which partition to use Jul 22 04:26:31 wait a sec Jul 22 04:27:12 i'm not sure if #2 is correct as it seems to be implemented at wrong level Jul 22 04:27:14 it would work Jul 22 04:27:24 but could not be a correct logic Jul 22 04:27:44 maybe you should rather use adtran,fixed-partitions instead of fixed-partitions Jul 22 04:28:24 and have partitioned that doesn't respect "compatible" for the /wrong/ "firmware1" or "firmware2" partition Jul 22 04:28:43 i think it could be a better design Jul 22 04:29:09 hmm Jul 22 04:29:21 aparcar[m]: jow: I've a problem with "make V=s" in my 18.06 branch, it's after I did "rm -fR build_dir staging_dir tmp bin" Jul 22 04:29:31 where is the fixed-partitions binding coded? Jul 22 04:29:32 aparcar[m]: jow: "opkg_install_pkg: Package size mismatch" Jul 22 04:30:03 it complains about iw, kmod-nls-base, kmod-usb-ohci, kmod-usb-bcma, libiwinfo, wpad-mini Jul 22 04:30:06 and few more Jul 22 04:31:05 aparcar[m]: i see you got such a problem https://chef.libremesh.org/download/faillogs/faillog-9e251fa74e79.txt Jul 22 04:35:59 hm, could that be regression caused by e6af9c017b0c ("opkg: bump to version 2019-06-14") Jul 22 04:37:22 seems like it Jul 22 04:45:35 that's weird, it seems that both: 18.06 and master use the same opkg version, but I get that problem with 18.06 only Jul 22 06:59:49 rmilecki: how about if i define a new dt property to select which partition gets parsed/split? Jul 22 07:05:49 DonkeyHotei: can you determine that at DT level? Jul 22 07:05:56 DonkeyHotei: i think it depends on some env variable Jul 22 07:06:00 bootloader flag or sth Jul 22 07:14:09 rmilecki: if opkg wouldn't complain about the size mismatch, it would complain about checksum mismatches Jul 22 07:14:29 rmilecki: root cause is the same; somehow package list and cahces got out of sync Jul 22 07:14:30 rmilecki: i reverted that commit and everything compiled fine Jul 22 07:14:33 jow: i reverted that commit and everything compiled fine Jul 22 07:14:37 which commit? Jul 22 07:14:47 git revert e6af9c017b0c Jul 22 07:14:51 e6af9c017b0c ("opkg: bump to version 2019-06-14") Jul 22 07:15:11 i also did rm -fR build_dir/ staging_dir/ tmp/ bin/ Jul 22 07:15:17 and got the same problem after recompilation Jul 22 07:15:34 I don't think how this commit could be related Jul 22 07:15:38 *don't see Jul 22 07:15:51 it adds the check, so it obviously is Jul 22 07:16:07 it adds cb66403 libopkg: check for file size mismatches Jul 22 07:16:11 but it is impossible for files to have a different size but the same checksum Jul 22 07:16:16 ah Jul 22 07:16:22 what can I say? ;) Jul 22 07:16:37 the size check adds an *additional* check before the checksum compare Jul 22 07:16:48 in order to improve the integrity checking Jul 22 07:17:02 without that checvk, under the very same conditions, it should see a checksum mismatch instead Jul 22 07:17:37 let me verify that again Jul 22 07:25:15 jow: can you take a look at http://files.zajec.net/openwrt/opkg.txt ? maybe a full log will ring some bell Jul 22 07:27:20 rmilecki: whats in /home/rmilecki/openwrt/openwrt-18.06-bcm53xx/build_dir/target-arm_cortex-a9_musl_eabi/linux-bcm53xx/target-dir-4dfe17c5.conf ? Jul 22 07:27:44 rmilecki: bootloader commandline, actually Jul 22 07:28:16 jow: that doesn't exist anymore (because of git revert + make?) Jul 22 07:28:58 let me try again without revert Jul 22 07:29:17 rmilecki: (FYI I've bumped mac80211 to 5.2-rc7 accidentally) and I'm kind of neutral with the bump mac80211 to 5.2 in 19.07, but 4.14 + 4.19 mac80211 and 4.19 + 5.2 mac80211 looks more reasonable to me Jul 22 07:30:08 ynezz: your ARGV edit is confirmed working Jul 22 07:30:25 DonkeyHotei: good, thanks Jul 22 07:31:14 rmilecki: can you pastebin me "ls -lh /home/rmilecki/openwrt/openwrt-18.06-bcm53xx/staging_dir/packages/bcm53xx/" ? Jul 22 07:31:20 sure Jul 22 07:31:48 "opkg_install_pkg: Package size mismatch: iw is 35628 bytes, expecting 104 bytes" Jul 22 07:31:58 this looks as if the package was empty when the index was generated Jul 22 07:32:36 jow: https://pastebin.com/U2vkbxkN Jul 22 07:32:52 ldir: from my POV it's about firmware headers/images, so the destination struct should be 0 filled first and then the source copied over, the problem with strncpy is this 0 termination, where you would like to copy all X source bytes over to destination, but would cripple it with strncpy to X-1, likely producing broken image Jul 22 07:34:13 rmilecki: note how the size of the "iw_4.14-1_arm_cortex-a9.ipk" symlink is exactly 104 bytes? Seems there's a bug in ipkg-make-index.sh Jul 22 07:34:17 jow: packages in "bin/ seem to have nomral size Jul 22 07:34:31 rmilecki: it does not take the size of the file but of the symlink object itself Jul 22 07:34:50 > ls -lh bin/packages/arm_cortex-a9/base/iw_4.14-1_arm_cortex-a9.ipk Jul 22 07:34:51 -rw-r--r-- 1 rmilecki users 35K lip 21 23:46 bin/packages/arm_cortex-a9/base/iw_4.14-1_arm_cortex-a9.ipk Jul 22 07:34:55 jow: i see Jul 22 07:35:26 rmilecki: check commit ece5cab743f9df6c9655d6117e92fda110292173 Jul 22 07:35:34 maybe we forgot to backport it to 18.06 Jul 22 07:35:43 (or your stat -L is broken, but that appears way less likely) Jul 22 07:35:47 trying Jul 22 07:36:27 yeah, ece5cab743f9df6c9655d6117e92fda110292173 seems to be missing in the 18.06 Jul 22 07:36:38 that must be it... compiling Jul 22 07:36:40 ldir: like some bootloaders check for some patterns/versions in the firmware image headers "x.y.z UBNT" and we would just write "x.y.z UBN", it's simply binary data, bunch of u8 bytes, not a NULL terminated string Jul 22 07:37:20 jow: bingo: git cherry-pick ece5cab743f9df6c9655d6117e92fda110292173 Jul 22 07:37:27 jow: thanks for looking at that! Jul 22 07:37:40 can you "git cherry-pick -x" and push it? Jul 22 07:37:42 sure Jul 22 07:37:48 thanks! Jul 22 07:37:53 no, thank you :) Jul 22 07:38:30 DonkeyHotei: so it seems a proper partitioning depends on bootloader args, which to me, sounds like not 100% fixed partitioning Jul 22 07:38:43 DonkeyHotei: i think you should write alternative to "fixed-partitions" then Jul 22 07:38:54 DonkeyHotei: a simple one, that will take bootloader args into account Jul 22 07:39:23 or better, discuss this with upstream first :) Jul 22 07:39:44 ynezz: does mtdsplit even have an upstream? Jul 22 07:40:27 DonkeyHotei: of course! Jul 22 07:41:26 Documentation/devicetree/bindings/mtd/partition.txt Jul 22 07:45:32 jow: not that I need it explicitly, but could you give me your Acked-by for that urngd backport to 19.07 ? :) Jul 22 07:45:45 Acked-by Jul 22 07:45:51 thanks Jul 22 09:32:13 FYI, I was just informed, that this layerscape/armv8_64b image breakage is caused by the http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv8_64b/builds/8/steps/pkgbuild/logs/stdio Jul 22 09:32:46 `fiptool_platform.h:18:27: fatal error: openssl/sha.h: No such file or directory` and asking us to add missing openssl-dev package Jul 22 09:33:26 I've instead told them to fix the tfa-layerscape properly, using hostbuild for that fiptool host utility Jul 22 09:37:18 makes me wonder if it's possible to host depend on some package Jul 22 09:39:29 also can't find the step where is staging_dir/host/include/openssl populated Jul 22 09:51:45 ynezz: FYI I'm going to be busy doing $paidjob for the week, so where I've got to with the firmware-utils fixes/issues as exposed on macOS you can see in https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=shortlog;h=refs/heads/tools Jul 22 09:54:37 maybe it's useful Jul 22 10:09:35 ldir: nice, thanks! Jul 22 10:11:57 yes you can depend on a package host build Jul 22 10:47:20 jow: I'm now the proud owner of an R6220. I've seen there are issues with shifted reads/writes on bad blocks with a fix you proposed. Is there any way i can provide help in testing to get this forward? Jul 22 11:11:10 * ldir can never remember off the top of its head how to delete a remote branch - always a web search involved Jul 22 11:14:18 do I smell some git UI/UX rant?! :p Jul 22 11:15:42 no, it's just shocking how bad my memory is! Jul 22 11:46:32 why? `push origin :$brachname` is a perfectly intuitive UX /s Jul 22 11:47:15 I find `push $remote --delete $branchname` better Jul 22 11:51:34 bookworm: yeah they missed a trick there, should've chosen a character you needed to escape from the shell. Jul 22 12:09:50 * ldir hits himself in the head - paradigm shift - libressl is libre-ssl not lib-ressl Jul 22 12:14:01 Modern me clicks "delete branch" on Sublime Merge =D Jul 22 12:22:22 nobody likes a show off ok ;-) Jul 22 12:26:58 Exept the show offer? (: Jul 22 12:29:33 anyone else got build failures on libressl after latest bump? Jul 22 12:39:02 blocktrron: basically test if all works as epxected with the fix Jul 22 12:39:09 blocktrron: then push it with your tested-by Jul 22 12:39:23 Okay thanks. Jul 22 12:39:57 Another question - what are your feelings about the kernel written on NAND without an UBIFS layer. Jul 22 12:39:58 blocktrron: I had that vague wish to clena up the driver a bit while being at it but real life got in the way Jul 22 12:40:38 My knowledge about this is pretty sparse (especially in regards to the rate how fast bad blocks develop). Jul 22 12:42:43 A bad block might effectively kill the entire device if the kernel grows into this block / a block within the kernel goes bad on update. This is not the case if the kernel is wrapped inside Ubifs, right? Jul 22 12:43:06 I would assume so too but am no expert there Jul 22 12:43:24 also kernel in ubi(fs) would likely require vendor bootloader support (or a custom 2nd stage loader) Jul 22 12:44:14 yes, it's not implemented in ramips sadly. I've used it on some mpc85xx and ipq40xx boards. Jul 22 12:44:30 I just wanted to assure if this is a problem or just me being paranoid Jul 22 12:51:19 ldir:There's a compile issue with libressl on MAC OS with latest version Jul 22 12:51:46 ldir:could you check if https://github.com/openwrt/openwrt/pull/2261 fixes it ? Jul 22 12:56:50 blocktrron: it's a UBI layer; UBIFS is a filesystem that works on top of that, but a kernel would usually be directly a partition in UBI and not additionally within a UBIFS Jul 22 12:57:42 ubi alone is enough to have a consistent, bad-block-managed continuous (block?) device on top of nand? Jul 22 12:58:10 and ubifs just happens to be an fs that is optimized for ubi? Jul 22 12:58:46 seems so according to wikipedia Jul 22 12:59:35 yupp Jul 22 13:00:35 note that this only applies to SLC nand, MLC isn't supported by UBI yet, since requires additional special handling Jul 22 13:01:37 dedeckeh: -ENOFIX :-( Jul 22 13:02:09 blocktrron: bad blocks don't develop that fast, but NAND is plagued by various disturb side effects, where just reading a block can eventually flip a bit and require re-programming of the block Jul 22 13:05:00 dedeckeh: I found this https://gitlab.com/ymorin/buildroot/commit/e783d60473944f8b39f1def45d8d6b483a062158 patching out build of tests works, but I'm wondering if there's anything less invasive. Mind you I'm wondering if we *really* need to build the man pages! Jul 22 13:06:39 I'm pretty sure we already have patches for some host tools that disable building of man pages and tests Jul 22 13:08:00 this is autotools and I have literally no idea which file to patch! Jul 22 13:08:41 I wondered about using cmake, but cmake appears to have a dependency on libressl Jul 22 13:13:48 KanjiMonster: okay, thanks for the clarification Jul 22 13:15:06 dedeckeh: https://paste.ubuntu.com/p/FH36m3THqF/ Jul 22 13:15:48 KanjiMonster: is this re-programming done by U-Boot normally or am i "out of luck" in that case? Jul 22 13:17:45 blocktrron: it isn't. maybe you could change the bootcmd to check for correctable bitflips and rewrite the kernel if it happens, but normally that's the job of the FTL, or UBI Jul 22 13:17:59 non ancient u-boots should support ubi though Jul 22 13:18:46 Well, ubi support seems to be optional if i'm not mistaken Jul 22 13:19:18 it rubs the lotion on its skin Jul 22 13:46:29 dedeckeh: https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=7209ab9888e66ac2b5b0aafe0a31ae01e5ff83b6 Jul 22 13:46:43 * ldir waits for the screams Jul 22 13:46:56 blocktrron: MTK's ancient u-boot 1.1.3 doesn't support that at all. Their new u-boot 2018.08 for mt7621 should support it but I haven't seen any manufacturer using it yet. Jul 22 14:01:35 ldir: lgtm Jul 22 14:02:34 jow: great - just like to know it doesn't b0rk those on that strange linux OS ;) Jul 22 14:16:33 jow: ping Jul 22 14:21:48 Is there a way to use this docker thing (that I don't understand) as a means of compiling a local tree on local disc ? Jul 22 14:22:20 jow: seems the aarch64 buildbot is totally broken. note that this version is not in any of thr branches: https://downloads.openwrt.org/snapshots/faillogs/aarch64_cortex-a53_neon-vfpv4/packages/libwebsockets/cyassl/compile.txt Jul 22 14:24:10 WRT "formal" Linux Backports -- is the process at https://backports.wiki.kernel.org/index.php/Documentation/integration what is used for the OpenWrt build system? (trying to resolve recent backport bump that broke batman-adv) Jul 22 14:29:41 jow: https://github.com/openwrt/openwrt/pull/2250 please check this out Jul 22 14:31:29 jeffsf: isn't it fixed already? Jul 22 14:31:52 jeffsf: https://git.openwrt.org/?p=feed/routing.git;a=commit;h=9e7dbf9ba998c56e3fc0084aa95a5522f230a846 Jul 22 14:32:06 Awesome, thanks! Jul 22 14:32:15 Just waking up here in the US Jul 22 14:32:43 The surprise mac80211 bump has had a bit of fallout Jul 22 14:33:33 it was announced on the mailing list 11 days before, it's not enough? :) Jul 22 14:34:04 Apparently not, mt76 is still waiting on fixing :P Jul 22 14:34:19 I'm not aware about that problem Jul 22 14:35:01 mt762xx is all green on http://buildbot.openwrt.org/master/images/grid Jul 22 14:35:08 You patched it upstream about two months ago. Jul 22 14:35:13 It builds, but panics. Jul 22 14:35:59 ok, which FS bug it's that, probably missed it, sorry Jul 22 14:36:25 I have no idea if it's been filed there - I haven't done anything because a PR is waiting on mt76 itself Jul 22 14:37:01 ok, gotta go now, will look at, please provide me with some link to that PR Jul 22 14:37:18 s/look at/look at it later/ Jul 22 14:38:08 IIRC I've tested this bump on mt7620 device and it was working fine here (tm) Jul 22 14:39:01 The PR I'm hopeful nbd will notice: https://github.com/openwrt/mt76/pull/298 Jul 22 14:39:04 ynezz: it works fine as long as you have a mtd-mac-address aka no err_ptr is returned Jul 22 14:39:13 Yes, that Jul 22 14:39:45 What, did everyone know about this except me? :P Jul 22 14:40:00 Took a few too many hours to figure out what was going on Jul 22 14:40:04 I'm not aware, really Jul 22 14:40:09 Monkeh: hit the same issues a few days ago, while testing k5.2 on lantiq Jul 22 14:40:19 ynezz: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/mediatek/mt76/eeprom.c?h=v5.2&id=d31a36b5f407d796d121af745730712337cd32a1 Jul 22 14:40:57 mkresin: Did it take you too many hours to puzzle out? :P Jul 22 14:42:36 Monkeh: not that much, sicne i touched the owrt mtd-mac-address patch a few hours earlier Jul 22 14:45:06 Makin' me feel bad. :) Jul 22 14:46:31 mkresin: The worst bit is I already broke the board up in the loft with it because I was too lazy to test first. Jul 22 14:52:47 Monkeh: wasted hours with a not working swconfig. TL;DR; netlink changes, strict validation of nested attributes Jul 22 14:56:12 ah, got bitten by the nested attribute thing myself on act_ctinfo. Jul 22 15:04:59 ldir: if required, you find a - sort of - fix in my staging tree Jul 22 15:06:33 The bit that got me should be fixed properly in upstream iproute2 - I've done the kernel bit properly :-) Jul 22 15:25:26 mangix: there is no aarch64_cortex-a53_neon-vfpv4 anymore, you're looking at a stale log Jul 22 15:35:38 ynezz: batman-adv confirmed to build after refreshing package feeds -- thanks! Jul 22 15:54:06 GitHub 500 errors on viewing PRs -- just me? Jul 22 15:56:53 no, no. I have it too Jul 22 15:58:46 https://www.githubstatus.com/ - "Degraded Performance" they call it Jul 22 16:00:46 Sounds microsoft (not thst i know hpw they call it before ms :p ) Jul 22 16:13:11 ynezz: oh hello self hosted gitlab ;) Jul 22 16:33:55 jow: you're right. this isn't though: https://downloads.openwrt.org/snapshots/faillogs/aarch64_cortex-a53 Jul 22 17:44:58 I also had access problems with github today Jul 22 17:47:11 jow: could we delete these old toolchains? Jul 22 17:47:19 should I send you a list? Jul 22 17:54:33 Monkeh: I also ran into this of_get_mac_address() API change ;-= Jul 22 17:54:36 ;-) Jul 22 17:57:16 At least it's not just me :) Jul 22 18:08:23 I am already working on backports on kernel 5.3, but there are not so many changes Jul 22 18:11:22 Is the NAT hardware flow offloading now in the mainline kernel? Jul 22 18:12:46 Hauke: netfilter: nf_tables: add hardware offload support this one? Jul 22 18:13:04 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.3-rc1&id=c9626a2cbdb20e26587b3fad99960520a023432b Jul 22 18:14:13 Rene__: nice Jul 22 18:14:29 haven't noticed Jul 22 18:14:33 which hardwrae is supported? Jul 22 18:14:37 mediatek? Jul 22 18:15:55 hw offload Mediatek is not supported in the mainline kernel. Jul 22 18:16:17 In this patch I see some cards that are supported Jul 22 18:16:19 https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=14bfb13f0ed525ed117b5d1f3e77e7c0a6be15de Jul 22 18:20:13 Rene__: thanks Jul 22 18:20:57 there are many drivers implementing ndo_setup_tc() but this is mostly used for L2 offloading Jul 22 18:21:13 I shoudl subscribe to netdev mailling list Jul 22 18:38:24 aparcar[m]: even the self hosted gitlab can has issues. Gitlab is not almighty. Jul 22 18:38:33 have* Jul 22 18:54:39 Rene__: mtk qos wont be offloadable as its not a real qdisc afair Jul 22 18:56:43 blogic: is there a detailed description what they do? Jul 22 18:59:54 blogic: thanks for that information. Jul 22 20:09:15 ldir: thx for the libressl fix Jul 22 20:12:21 dedeckeh: no problem. has it helped you or someone you know out? Jul 22 20:14:28 ldir:yesterday the issue was brought to my attention https://github.com/openwrt/openwrt/commit/3f1e8c01316a5ea0162197cd8eb6dbbabe396176#commitcomment-34384945 Jul 22 20:16:44 I'm not totally convinced that simply not compiling the tests (and man pages) is the 'correct' solution. It works. Jul 22 20:20:57 ldir: test be damned Jul 22 20:34:36 nbd: BTW do you've some mt76 changes queued? Could you please add as well https://github.com/ynezz/openwrt-mt76/commit/f3c0f530a127b82ebcb17b9c07ea2c376f7108ac ? I could push it myself and bump the package as well also, but I'm not comfortable of doing so without your consent :) Jul 22 20:35:32 bunch of reports already, that mt76 is crashing badly for some users with 5.2-rc7 backports Jul 22 21:29:24 The update to iptables 1.8.3 broke the build for me; Error: no suitable libnftnl found. **** ENDING LOGGING AT Tue Jul 23 02:59:57 2019