**** BEGIN LOGGING AT Sat Mar 13 03:01:36 2021
Mar 13 03:08:12 <guidosarducci> ldir: can you tell me about your "act_ipt" issue? Legacy sqm-scripts doesn't really use it, but I do very much. And it's been very handy for regression testing iproute2.
Mar 13 05:28:06 <mangix> lipnitsk: rsalvaterra: opinion on https://github.com/neheb/openwrt/commit/f70e914b973d15c823c256e0d7046b36df787033 ?
Mar 13 05:28:29 <mangix> sorry, https://github.com/neheb/openwrt/tree/exfat
Mar 13 05:30:08 <lipnitsk> just use @ge5.10 @lt5.10
Mar 13 05:30:44 <lipnitsk> $(LINUX_DIR)/drivers/staging/exfat/exfat.ko@lt5.10
Mar 13 05:30:52 <lipnitsk> $(LINUX_DIR)/drivers/fs/exfat/exfat.ko@ge5.10
Mar 13 05:30:58 <lipnitsk> add both files to FILES
Mar 13 05:31:23 <lipnitsk> so it's already in tree in 5.4, just in staging?
Mar 13 05:31:36 <lipnitsk> mangix: ^
Mar 13 05:32:19 <lipnitsk> and that's not really a hack - it is the accepted way of declaring different module locations in different kernel versions
Mar 13 05:35:12 <lipnitsk> mangix: see package KernelPackage/mdio-gpio in netdevices.mk for an example
Mar 13 05:36:45 <mangix> lipnitsk: 5.4 has the staging version.
Mar 13 05:37:02 <lipnitsk> yeah so not really out of tree
Mar 13 05:37:17 <mangix> promoted out of staging in 5.7
Mar 13 05:37:25 <lipnitsk> I see
Mar 13 05:38:20 <mangix> i find it acceptable since I assume 5.4 will be gone soon.
Mar 13 05:53:13 <Grommish> Anyone want to try and help me figure out this dts issue? :D  Just as a reminder/warning, I've got no real experience with the device trees but I'm working on learning :p
Mar 13 05:55:46 <Grommish> this rtl8367rb driver is actually present, but I'm not sure how to enable it in the dts.  Rene__ did their best, but since I didn't understand the context .. eh
Mar 13 06:06:16 <owrt-snap-builds> Build [#1](https://buildbot.openwrt.org/master/images/#builders/65/builds/1) of `archs38/generic` stopped with exception.
Mar 13 06:07:06 <owrt-snap-builds> Build [#1](https://buildbot.openwrt.org/master/images/#builders/7/builds/1) of `armvirt/32` stopped with exception.
Mar 13 06:08:07 <owrt-snap-builds> Build [#1](https://buildbot.openwrt.org/master/images/#builders/15/builds/1) of `armvirt/64` stopped with exception.
Mar 13 06:19:44 <aparcar[m]> a new buildbot! exciting
Mar 13 06:23:22 <aparcar[m]> mangix: how do I test your test?
Mar 13 06:27:06 <mangix> aparcar[m]: the patch descriptions mentions either json-glib or transmission with full NLS
Mar 13 06:34:46 <plntyk> there is a ticket with diffconfig for json-glib
Mar 13 06:37:02 <plntyk> libintl/libiconv with musl and multi-lang support will probably remain difficult - most software is "implicitly" glibc
Mar 13 06:41:37 <plntyk> btw - whats the policy on 18.06.x tickets on packages - I looked at some older ticket - like https://github.com/openwrt/packages/issues/8930
Mar 13 06:42:36 <plntyk> adding a wiki entry under known issues and closing them probably before 21.x release
Mar 13 06:51:36 <Grommish> blogic: ping
Mar 13 07:51:21 <mangix> plntyk: sounds like cherry picking is the solution
Mar 13 08:54:15 <ldir> guidosarducci: I think it's a non-issue - act_ipt isn't in the default owrt sched package so isn't on my system. HEAD sqm-scripts has a fix for choosing modprobe v insmod, and by default act_ipt is in the list of modules attempted to load - since not there it throws a warning that it never used to.
Mar 13 08:56:18 <guidosarducci> ldir: act_ipt is in kmod-sched right now, how is it not on some systems?
Mar 13 08:59:55 <ldir> err, that's odd.  Maybe my build went wonky.  but I see act_ipt in kmod-sched-extra
Mar 13 09:03:57 * ldir leaves for work
Mar 13 09:04:04 <guidosarducci> ldir: erm, there's no kmod-sched-extra that I know of, so perhaps a build problem? Or are you testing a big refactor of kmod-sched (I was planning the same)?
Mar 13 09:24:10 <rsalvaterra> mangix: pong
Mar 13 09:27:55 <rsalvaterra> mangix: Why anyone would want to use exFAT in OpenWrt is beyond me, but otherwise LGTM. :)
Mar 13 09:31:36 <plntyk> rsalvaterra, well if its "test" or "exchange" stick thats moved between systems (win, android, linux) and not having to deal with FAT32 limits
Mar 13 09:40:07 <mangix> rsalvaterra: it’s the port portable FS
Mar 13 09:40:20 <mangix> *most
Mar 13 09:41:57 <rsalvaterra> mangix: Yeah, it is, unfortunately…
Mar 13 09:52:07 <rsalvaterra> This is neat…! https://lore.kernel.org/linux-mm/20210313075747.3781593-1-yuzhao@google.com/
Mar 13 09:54:10 <plntyk> lol
Mar 13 09:54:12 <plntyk> "For servers equipped with hundreds of gigabytes of memory"
Mar 13 09:54:17 <plntyk> sure ^^
Mar 13 09:54:38 <rsalvaterra> plntyk: You stopped reading there?
Mar 13 09:55:00 <plntyk> for a short while laughing - then crying -.-
Mar 13 09:56:13 <plntyk> memcg = memory cgroup ?
Mar 13 09:56:30 <rsalvaterra> plntyk: Yes.
Mar 13 09:56:31 <plntyk> ah no
Mar 13 09:56:44 <plntyk> ah ok
Mar 13 10:04:07 <plntyk> should be interesting if this and/or other changes "fixes" unresponsive systems when oom-killer is invoked on low memory desktops / devices
Mar 13 10:04:08 <Grommish> WinServer2019 supports I think up to 2TB of RAM on the DataCenter version
Mar 13 10:05:20 <Grommish> Not cheap, but not vaporware either
Mar 13 10:05:48 <plntyk> hopefully one day i'll try tmpfs compile with all packages on a home setup
Mar 13 10:06:38 <Grommish> I used to do CONFIG_ALL builds, took like 3 hours :(  aand you'd need IGNORE_ERRORS="m n" on the make call
Mar 13 10:06:52 <Grommish> or it'll dump on the incompatible package
Mar 13 10:08:02 <Grommish> then I stopped trying to build for Octeon3 annd just finally gave in to stayibg on octeonplus arch
Mar 13 10:08:10 <Grommish> Was't worth the cycles or time
Mar 13 10:10:35 <plntyk> its somewhat useful when doing regression / basic tests after adding new arch or testing on a "new" build-os if its still mostly working
Mar 13 10:11:19 <plntyk> i remember it testing it w. FreeBSD, Alpine Linux and for malta VM / qemu targets
Mar 13 10:11:27 <plntyk> *long* ago
Mar 13 10:11:58 <Grommish> *nod*  I was supportig a usergroup for my device before it was accepted into the upstream, so I was also maintaining the package repos..
Mar 13 10:12:10 <Grommish> Luckily that isn't the case anymore
Mar 13 10:13:03 <rsalvaterra> lipnitsk: The lpj calibration patch you mentioned is the 321-mt7621-timer.patch, right? The lpj calibration does seem bogus, but we mustn't drop the GENERIC_CLOCKEVENTS_BROADCAST selection.
Mar 13 10:13:56 <Borromini> Grommish: does going octeon3 bring tangible performance improvements? i suppose it does but did you 'quantify' it?
Mar 13 10:14:41 <Grommish> Borromini: No, I never quantified it because I was told in no uncertain terms (at the time) an Octeon3 target wasn't an option
Mar 13 10:16:03 <Borromini> oh yeah :(
Mar 13 10:16:38 <Grommish> In fairness, at the time, the SHield was the ONLY O3 device though
Mar 13 10:16:43 <Grommish> so it was understandable
Mar 13 10:17:59 <Borromini> er4 is one as well no
Mar 13 10:18:55 <Grommish> Yeah, there are a few other ones in the line now I think
Mar 13 10:20:27 <Grommish> I wouldn't know how to quantify performance for user-space packages though
Mar 13 10:21:05 <plntyk> we barely have "useful" cpu performance
Mar 13 10:21:43 <plntyk> openssl hash compare etc. is nice but sth like USB file copy / iperf WAN-LAN, with/-out SQM is more interesting for ppl probably
Mar 13 10:22:04 <Grommish> I know there are Octeon3 specific kernel ifdef's, but eh.. I don't know what practical purpose they do since I don't really code
Mar 13 10:23:06 <Borromini> :)
Mar 13 10:26:24 <Grommish> I was wondering if I could put a -mtune for octeon3 and still have it be able to use the octeonplus package repos
Mar 13 10:26:50 <Grommish> since -march is set to octeonplus
Mar 13 10:31:00 <Borromini> adrianschmutzler: ping
Mar 13 10:31:10 <Grommish> plntyk: Even more, the Octeon3 chips have hardware crypto functions that probably aren't being used because of it, but again, I'm not sure how useful it would actually be
Mar 13 10:31:34 <Grommish> or how to test it against a known baseline
Mar 13 10:32:13 <adrianschmutzler> Borromini: pong
Mar 13 10:36:39 <Borromini> adrianschmutzler: hi. about the R6850 patch: just overriding the eeprom property is sufficient? as in 4716c843d6 e.g.?
Mar 13 10:37:25 <adrianschmutzler> Borromini: I actually have not looked closely yesterday. Maybe I will have time today. My main point was the inconsistency between what you tell and what you do
Mar 13 10:40:26 <Borromini> ok. other than the eeprom property everything else is the same as in the dtsi it overrides.
Mar 13 10:40:58 <adrianschmutzler> so you just copied the node from dtsi with only the property changed?
Mar 13 10:43:04 <Borromini> yes
Mar 13 10:43:29 <adrianschmutzler> hmm, then I would have chosen one of the two following solutions:
Mar 13 10:43:44 <adrianschmutzler> *three:
Mar 13 10:43:53 <Grommish> Nite all :) It's almost 6am here and I'm messaging the wrong folks :)  Enjoy the day!
Mar 13 10:44:01 <Borromini> night Grommish
Mar 13 10:44:06 <adrianschmutzler> 1. only overwrite the flash location property in the DTS
Mar 13 10:44:22 <adrianschmutzler> 2. move the whole blocks to the devices, and then _remove_ them from the DTSI
Mar 13 10:44:45 <adrianschmutzler> 3. move the flash location to the devices, and then _remove_ the property from the DTSI
Mar 13 10:45:07 <adrianschmutzler> still, without having looked at it, just from your description
Mar 13 10:45:12 <Borromini> ok
Mar 13 10:45:37 <adrianschmutzler> maybe just wait whether I will have time to look in the afternoon. If that's not the case, you could still adjust as you think.
Mar 13 10:46:14 <adrianschmutzler> i.e. it's probably better if I've really looked at the thing before giving recommendations
Mar 13 10:46:41 <adrianschmutzler> so I could probably merge it right away then as well
Mar 13 10:47:57 <Borromini> adrianschmutzler: i'll wait till you find the time to look. there's no rush
Mar 13 10:48:58 <Borromini> the dtsi is for three similar devices and one of them at least seems to have the factory partition at different locations sometimes, as per 0cf889db00
Mar 13 10:49:46 <rsalvaterra> blogic: ping. What were the symptoms of not selecting WEAK_REORDERING_BEYOND_LLSC for the MT7621? How often did the system hang? I'm asking because I believe the root cause has already been fixed in the kernels we support (5.4, 5.10), and I'm running my system without that patch for over 10 hours already.
Mar 13 10:52:35 <adrianschmutzler> Borromini: I will be off again now and try to look later ...
Mar 13 11:37:56 <blogic> rsalvaterra: it was a 1004kec issue in the kernel related to high mem i think
Mar 13 12:10:27 <ldir> guidosarducci: package/kernel/linux/modules/netsupport.mk define KernelPackage/sched-core does NOT list act_ipt in it.
Mar 13 12:12:38 <ldir> hence it is not in my build.  I see act_ipt in define KernelPackage/sched under 'Extra traffic schedulers'
Mar 13 12:15:10 <ldir> I think the error is fallout from https://github.com/tohojo/sqm-scripts/commit/5d7e7977e14e147d5bcfa8a5f01636c7ab230fa4
Mar 13 12:21:34 <rsalvaterra> blogic: I believe the correct fix is this, but I don't have HIGHMEM hardware for testing: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/mips/include/asm?h=linux-5.4.y&id=42344113ba7a1ed7b5654cd5270af0d5698d8521
Mar 13 16:17:07 <adrianschmutzler> Borromini: ping
Mar 13 16:37:25 <iskander> hi all, i'm implementing sysupgrade for netgear r9000 (factory flashing already works), where should i look for a good example how to implement sysupgrade for NAND and UBIFS ?
Mar 13 16:37:43 <Borromini> adrianschmutzler: hi
Mar 13 16:38:00 <Borromini> iskander: i think the netgear r6800 uses both
Mar 13 16:38:58 <adrianschmutzler> Borromini: I had a look and personally I'd just have moved the mtd-eeprom to the DTS files.
Mar 13 16:39:17 <Borromini> adrianschmutzler: i'll do that then, thanks
Mar 13 16:39:50 <adrianschmutzler> and then remove it from the dtsi; add a DT label to the wifi@0,0 directly, so you don't have to nest ...
Mar 13 16:42:12 <Borromini> ok, i'll have look into that, thanks
Mar 13 16:46:20 <Borromini> iskander: did you check package/base-files/files/lib/upgrade/ in the openwrt tree?
Mar 13 16:46:26 <Borromini> that has a nand.sh script
Mar 13 16:47:06 <iskander> there right now, strange is that almost all other boards define PART_NAME=firmware but many of them don't have such a partition, copy-paste ?
Mar 13 16:47:22 <Borromini> does yours have it in the dts?
Mar 13 16:47:31 <iskander> nope, i have "ubi"
Mar 13 16:47:32 <Borromini> firmware is what openwrt calls the partition it installs to
Mar 13 16:47:36 <Borromini> hmm sec
Mar 13 16:47:57 <iskander> r6800 has ubi too but no firmware partition
Mar 13 16:47:58 <Borromini> my /proc/mtd as well on the R6800
Mar 13 16:48:24 <iskander> and firmware partition present ?
Mar 13 16:48:41 <Borromini> no
Mar 13 16:49:09 <iskander> hmm, wehat sense does then PART_NAME=firmware make, that's what i was confused about, i was looking for this thing but it was never used
Mar 13 16:49:29 <Borromini> https://paste.debian.net/1189229/
Mar 13 16:49:33 <iskander> it's almost in every platform.sh :)
Mar 13 16:49:43 <Borromini> my uneducated guess is firmware maps to the space openwrt uses
Mar 13 16:49:59 <Borromini> maybe it's translated differently on nand targets (i think most nand targets if not all use ubifs)
Mar 13 16:50:19 <iskander> thanks, my partition table is similar to yours
Mar 13 16:51:12 <iskander> maybe it's mapped to ubi partition somehow
Mar 13 16:51:23 <iskander> need to trace all function calls :)
Mar 13 16:53:09 <iskander> in nand_do_upgrade: [ ! "$(find_mtd_index "$CI_UBIPART")" ] && CI_UBIPART="rootfs"
Mar 13 16:53:25 <iskander> aha, it's using CI_UBIPART instead
Mar 13 16:55:50 <iskander> CI_KERNPART="${CI_KERNPART:-kernel}"
Mar 13 16:56:01 <iskander> CI_UBIPART="${CI_UBIPART:-ubi}"
Mar 13 16:56:10 <iskander> CI_ROOTPART="${CI_ROOTPART:-rootfs}"
Mar 13 16:56:21 <iskander> so defaults are already OK for r9000 :)
Mar 13 16:56:25 <Borromini> looks like you're set :)
Mar 13 16:57:09 <iskander> my guess PART_NAME is some hack or copy-paste :/
Mar 13 16:58:42 <lipnitsk> rsalvaterra: yes, that's the lpj patch. So is GENERIC_CLOCKEVENTS_BROADCAST an unrelated change then? I was thinking about keeping it, but my system seems to work fine without it. Do you know what requires it just for my understanding?
Mar 13 18:26:07 <miu5> hi.  anyone here manages apcupsd package?  having an issue with apcupsd not calling "/etc/apcupsd/apccontrol doshutdown"... I tried calling the cmd manually and the router indeed shutdown/halted. Here is what i get in logs when the router is actually supposed to halt/shutdown, but never does.  https://bpa.st/raw/67FQ
Mar 13 18:53:19 <miu5> am having this exact problem: https://sourceforge.net/p/apcupsd/mailman/apcupsd-users/thread/DM6PR11MB4233DCD05612AED4A4864590BDBA0%40DM6PR11MB4233.namprd11.prod.outlook.com/#msg36757652    is the dev Othmar Truniger here?
Mar 13 19:16:52 <plntyk> email maintainer and/or write a github issue
Mar 13 19:22:05 <guidosarducci> ldir: hi Kevin, I had the idea you installed kmod-sched and couldn't find act_ipt, hence a build/packaging problem. With just kmod-sched-core installed nothing strange about your error. If I can get through a queue of PRs I'd like to refactor and clean up the kmod-sched* configs for post 21.02.
Mar 13 19:22:54 <guidosarducci> ldir: but I thought that last release too... :-)
Mar 13 20:49:44 <guidosarducci> Wondering which devs are active and interested in kernel 5.10 on x86 and malta? I use these platforms (w/QEMU) extensively for testing, and there are PRs/branches ready to add 5.10 support.
Mar 13 22:50:45 <ill> Hi all, I'm trying to restore my tp-link tl-wr841nd via serial port but I only get the router output, I am using "screen" program, when I try to send any command I can't writte it in the terminal. any one have an advise ?
Mar 13 22:54:23 <mangix> ill: grounding issue probably
Mar 13 23:01:26 <ill> thanks, I'll check
Mar 13 23:14:53 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_omap.html has been updated. (0% images and 98.1% packages reproducible in our current test framework.)
Mar 13 23:50:48 <owrt-snap-builds> Build [#2](https://buildbot.openwrt.org/master/images/#builders/26/builds/2) of `apm821xx/sata` completed successfully.
Mar 13 23:58:21 <owrt-snap-builds> Build [#2](https://buildbot.openwrt.org/master/images/#builders/66/builds/2) of `apm821xx/nand` completed successfully.
Mar 14 00:24:44 <owrt-snap-builds> Build [#2](https://buildbot.openwrt.org/master/images/#builders/61/builds/2) of `arc770/generic` completed successfully.
Mar 14 00:54:03 <owrt-snap-builds> Build [#2](https://buildbot.openwrt.org/master/images/#builders/65/builds/2) of `archs38/generic` completed successfully.
Mar 14 01:19:59 <owrt-snap-builds> Build [#2](https://buildbot.openwrt.org/master/images/#builders/3/builds/2) of `at91/sam9x` completed successfully.
Mar 14 01:42:42 <owrt-snap-builds> Build [#2](https://buildbot.openwrt.org/master/images/#builders/7/builds/2) of `armvirt/32` completed successfully.
Mar 14 01:59:54 <owrt-snap-builds> Build [#2](https://buildbot.openwrt.org/master/images/#builders/15/builds/2) of `armvirt/64` completed successfully.
Mar 14 02:07:14 <owrt-2102-builds> Build [#2](https://buildbot.openwrt.org/openwrt-21.02/images/#builders/25/builds/2) of `archs38/generic` completed successfully.
Mar 14 02:18:13 <owrt-snap-builds> Build [#2](https://buildbot.openwrt.org/master/images/#builders/1/builds/2) of `ath79/generic` completed successfully.
Mar 14 02:20:42 <owrt-snap-builds> Build [#2](https://buildbot.openwrt.org/master/images/#builders/46/builds/2) of `ath25/generic` completed successfully.
Mar 14 02:34:09 <mangix> rsalvaterra: you fix your mt76 issue?
Mar 14 02:35:27 <Grommish> mangix: You any good with dts by chance?
Mar 14 02:40:59 <owrt-2102-builds> Build [#2](https://buildbot.openwrt.org/openwrt-21.02/images/#builders/60/builds/2) of `armvirt/64` completed successfully.
Mar 14 02:45:17 <Festivenari> hi, so are there any OpenWRT devices that use the BCM63138 SoC? I'm trying to port a device that uses that particular SoC to no avail; /usr/include/netinet/tcp.h:104:17: error: redeclaration of 'uint8_t tcphdr::<unnamed union>::<unnamed struct>::th_off'
Mar 14 02:45:56 <Festivenari> I've found one device that has a port, but it's not in the OpenWRT repo and it's extremely outdated; https://github.com/smx-smx/bcm63138
Mar 14 02:48:47 <Festivenari> interesting... this device is a rebadged Netgear D7000
Mar 14 02:49:54 <mangix> Grommish: nope. what problem do you have?
Mar 14 02:51:08 <Grommish> mangix: I'm working thru this er10x rtl8367rb.  I've managed to get it to sort of try and recognie things at least, but it fails out because it can't find certain things..  https://gist.github.com/Grommish/79f4b81327ca5ef46534ee4cf518e3b4
Mar 14 02:52:49 <Grommish> mangix: I'm guessing it dies here https://github.com/Lochnair/kernel_e50/blob/v2.0.9/master/drivers/net/ethernet/realtek/rtl8367c/smi.c#L38
Mar 14 02:54:37 <Grommish> meh, wrong file.  in drivers/net/phy/rtl8367b.c
Mar 14 02:58:48 <owrt-2102-builds> Build [#2](https://buildbot.openwrt.org/openwrt-21.02/images/#builders/52/builds/2) of `at91/sam9x` completed successfully.
**** ENDING LOGGING AT Sun Mar 14 02:59:56 2021