**** BEGIN LOGGING AT Mon Jan 04 02:59:57 2021
Jan 04 08:22:46 <zorun> several people reported a memory leak on 19.07
Jan 04 08:22:49 <zorun> https://bugs.openwrt.org/index.php?do=details&task_id=3366
Jan 04 08:23:11 <zorun> it points to https://github.com/openwrt/openwrt/commit/08a42ef057b0c1c31d66358f29376b939487c732 as a fix
Jan 04 08:23:17 <zorun> does that make sense?
Jan 04 08:50:20 <aparcar[m]> jow: ping?
Jan 04 08:54:07 <nitroshift> hey guys
Jan 04 08:54:23 <nitroshift> trying to build, getting the following error:
Jan 04 08:54:28 <nitroshift> grep: /home/nitroshift/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/linux-mvebu_cortexa9/linux-5.10.4/modules.builtin: No such file or directory
Jan 04 08:54:34 <nitroshift> any ideas?
Jan 04 08:55:37 <mangix> dedeckeh: ping
Jan 04 09:01:43 <Borromini> mangix: hey. seems breed reset my MAC addresses (I saved them before flashing though). can I just add them back in /etc/config/{network,wireless} etc. with option macaddr?
Jan 04 09:01:47 <Borromini> or is there a better way?
Jan 04 09:02:09 <mangix> yeah, go to the bootloader settings
Jan 04 09:03:22 <mangix> https://forum.openwrt.org/t/solved-archer-c7-v2-0-overclock/9757/48?u=neheb
Jan 04 09:03:25 <mangix> second picture
Jan 04 09:07:06 <Borromini> alright, thanks :)
Jan 04 09:11:04 <mangix> in other news, kernel 5.10.4 is huge
Jan 04 09:11:26 <mangix> probably not quite stable yet
Jan 04 09:17:39 <Borromini> i've been running it on mt7621 for a week already
Jan 04 09:17:57 <nitroshift> mangix, i've been running it since rc days on mvebu
Jan 04 09:18:12 <Borromini> :P
Jan 04 09:18:36 <Borromini> nitroshift: production? mine is just a spare testing device, so barely any load.
Jan 04 09:19:02 <nitroshift> Borromini, production
Jan 04 09:20:04 <rsalvaterra> mangix: How huge, compared to 5.4? :/
Jan 04 09:20:44 <stintel> it's not *that* bad
Jan 04 09:23:20 <stintel> 27|20:48:15< stintel> heh, 759 patches in queue-5.9 already
Jan 04 09:23:31 <stintel> this was in october. pretty sure it was worse than 5.10.4 ?
Jan 04 09:24:44 <stintel> I think https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.9.2
Jan 04 09:25:52 <rsalvaterra> stintel: I prefer these changelogs… https://kernelnewbies.org/Linux_5.9 :)
Jan 04 09:26:02 <Borromini> kernelnewbies is nice
Jan 04 09:26:35 <stintel> for newbies? :P
Jan 04 09:26:37 * stintel hides
Jan 04 09:27:02 <stintel> rsalvaterra: they don't handle patch version though, or do they ?
Jan 04 09:27:24 <Borromini> can't pretend i'm anything else :P
Jan 04 09:27:27 <stintel> 5.9.2: 756 patches - 5.10.4: 717 patches
Jan 04 09:27:28 <stintel> close
Jan 04 09:27:51 <stintel> both -1, I forgot the series file
Jan 04 09:27:55 <rsalvaterra> Patch versions add no features, only fix bugs.
Jan 04 09:28:02 <stintel> yeah, right :)
Jan 04 09:28:20 <stintel> remember meltdown spectre shitshow?
Jan 04 09:28:41 <rsalvaterra> Ah, the gift that keeps on giving… that's a whole other story.
Jan 04 09:29:01 <stintel> ok, unusual, but it happens. I remember being seriously pissed off because they managed to hard break some of my systems with a stable bump
Jan 04 09:29:02 <rsalvaterra> And technically, no new features were added… :P
Jan 04 09:31:08 <rsalvaterra> I remember watching Thomas Gleixner's presentation about the whole debacle, he was angry as hell, and rightly so.
Jan 04 09:31:10 <mangix> rsalvaterra: by huge I meant changes in one version
Jan 04 09:31:29 <stintel> rsalvaterra: link ?
Jan 04 09:31:59 <rsalvaterra> mangix: Noted. By "huge" I always think about the final binary size differences, for the same config. ;)
Jan 04 09:32:15 <mangix> linux-btrfs also is pointing out a huge regression with 5.10
Jan 04 09:32:15 <rsalvaterra> stintel: Let me look it up, gimme a sec…
Jan 04 09:33:15 <Borromini> stintel: was that with spectre/meltdown? the breakage with a stable bump?
Jan 04 09:34:01 <stintel> yes
Jan 04 09:34:26 <stintel> but it happened with something elfutils/libelf related too at some point, iirc
Jan 04 09:35:11 <mangix> I believe this spectre/meltdown stuff will cause a rise in YOLO computing
Jan 04 09:37:02 <mangix> this is absolutely ridiculous https://www.phoronix.com/scan.php?page=news_item&px=Retpolines-Cryptsetup-Perf
Jan 04 09:37:15 <rsalvaterra> stintel: https://www.youtube.com/watch?v=SHsQZPp2-bM
Jan 04 09:38:49 <stintel> rsalvaterra: thanks
Jan 04 09:41:59 <Borromini> mangix: what's YOLO computing?
Jan 04 09:42:42 <mangix> Borromini: you only live once
Jan 04 09:42:49 <stintel> disable mitigations, don't care, get hacked/pwnd/double-ransomware-attacked/insert-event-here
Jan 04 09:43:06 <mangix> yeah that
Jan 04 09:43:08 <Borromini> ok. i know what yolo is. just not how it translated to computing :P
Jan 04 09:43:21 <rsalvaterra> Basically, people will just disable the mitigations because they're not putting up with the performance penalty.
Jan 04 09:43:31 <stintel> I added moar cores :P
Jan 04 09:43:53 <mangix> i actually don't understand the mitigations for the newest hardware
Jan 04 09:44:05 <mangix> i thought they fixed the issues in silicon
Jan 04 09:44:09 <rsalvaterra> stintel: *Gene Amdahl entered the chat*
Jan 04 09:44:10 <stintel> hardware vendors also don't care as long as we keep putting up with there junk
Jan 04 09:44:14 <mangix> except for the very very new ones
Jan 04 09:44:21 <stintel> and paying for it
Jan 04 09:44:26 <plntyk> some kernel devs/trees take time to "fix" issues ... low power hw video decoding is broken for some since 5.7-up to latest kernel (https://gitlab.freedesktop.org/drm/intel/-/issues/2024)
Jan 04 09:44:33 <Borromini> we can all just buy AMD of course :^)
Jan 04 09:44:49 <plntyk> basically "months" of YOLO - old kernel usage
Jan 04 09:45:11 <stintel> plntyk: in this case the sane thing to do is go back to last known good LTS
Jan 04 09:45:35 <stintel> unless you can because you need newer for new hardware :(
Jan 04 09:47:06 <plntyk> or you have a distribution like Fedora on that machine and they dont provide LTS afaik
Jan 04 09:47:31 <Borromini> there's a certain irony to running bleeding edge like Arch Linux and using an LTS kernel :P
Jan 04 09:47:46 <mangix> not really
Jan 04 09:48:01 <mangix> arch is supposed to be linux as you make it
Jan 04 09:48:36 <Borromini> are you running the lts kernel?
Jan 04 09:48:55 <mangix> I'm on 5.9.16 right now
Jan 04 09:49:07 <mangix> I am not upgrading to 5.10 yet
Jan 04 09:49:11 <stintel> plntyk: well you chose to use that distro ;)
Jan 04 09:49:15 <plntyk> arch with lts probably always has some bugs that can be reported - especially "old" AUR linux lts kernels
Jan 04 09:49:20 <plntyk> like linux-lts44
Jan 04 09:49:39 <stintel> 5.10.3 here on my main workstation
Jan 04 09:55:45 <mangix> hmmm
Jan 04 09:56:00 <mangix> wonder if I should look into cake as a replacement for fq_codel
Jan 04 09:56:57 <stintel> I need to rethink my entire sqm config. it's completely fucking up my uplink
Jan 04 09:57:28 <stintel> as in I don't even get 200Mbps on my gigabit connection
Jan 04 09:57:53 <stintel> and before anyone tells me you don't need sqm on gigabit: you're wrong
Jan 04 09:57:56 <mangix> I don't even have QoS on mine. YOLO networking
Jan 04 09:59:49 <rsalvaterra> Well, flow control is a problem… it interferes badly with SQM.
Jan 04 10:00:05 <mangix> ethernet flow control?
Jan 04 10:00:19 <rsalvaterra> Yes. Pause frames.
Jan 04 10:00:30 <rsalvaterra> It would be *really nice* if we had a way to disable that in /etc/config/network.
Jan 04 10:00:37 <mangix> ha
Jan 04 10:00:48 <mangix> pause frames are a problem for mt7621 in general
Jan 04 10:00:59 <stintel> if working from home taught me anything, it is you *always* need sqm/qos
Jan 04 10:01:15 <rsalvaterra> There's no life without SQM.
Jan 04 10:01:47 <mangix> huh
Jan 04 10:01:55 <rsalvaterra> But yeah, I know, we have ethtool… but if netifd(?) were smart enough to do it…
Jan 04 10:01:58 <stintel> I should spend some time again on trying to get network on that Firebox M300 I have
Jan 04 10:02:00 <mangix> so if I set net.core.default_qdisc to cake, I wonder what settings get applied
Jan 04 10:02:02 <stintel> rsalvaterra: send patches ;)
Jan 04 10:02:26 <rsalvaterra> stintel: I knew you'd say that. :P
Jan 04 10:02:35 <stintel> I wonder if the Firebox M300 will be able to route/nat/sqm/firewall faster than the APU2
Jan 04 10:02:41 <stintel> I suspect it will
Jan 04 10:02:50 <stintel> but I never managed to get network up and running
Jan 04 10:02:59 <mangix> rsalvaterra: turning off hardware offloads improves QoS and latency. Don't ask me how I know
Jan 04 10:03:39 <rsalvaterra> mangix: You can't have hardware/software offload with SQM! O_o
Jan 04 10:04:48 <mangix> no I mean the ethool settings with ethtool -K/-k
Jan 04 10:05:15 <rsalvaterra> Ah, you mean tso/gso?
Jan 04 10:05:29 <mangix> funny enough, turning some of them off with broken ethernet drivers actually improves speed
Jan 04 10:05:45 * mangix *cough* rockchip *cough*
Jan 04 10:06:17 <Borromini> :P
Jan 04 10:06:46 <mangix> rsalvaterra: actually I know cake does GRO peeling. Undoing GRO basically.
Jan 04 10:07:24 <mangix> so turning them off when using cake might improve performance...
Jan 04 10:07:41 <rsalvaterra> Speaking of broken Ethernet drivers, I wonder if rtl8169 will ever get byte queue limits…
Jan 04 10:08:01 <mangix> IIRC those are easy to add
Jan 04 10:08:25 <rsalvaterra> mangix: Not when the hardware hangs randomly. It's been tried. :P
Jan 04 10:08:27 <mangix> I would guess something's weird with that one
Jan 04 10:08:52 <mangix> ah that's no good
Jan 04 10:09:14 <mangix> was rtl8169 the USB one?
Jan 04 10:09:21 <rsalvaterra> Nope. PCIe.
Jan 04 10:09:56 <mangix> oh this is a gigabit interface...
Jan 04 10:10:10 <rsalvaterra> It's been used almost everywhere, it's extremely common.
Jan 04 10:13:01 <mangix> net.core.default_qdisc = pfifo_fast ... why debian why...
Jan 04 10:14:31 <stintel> yikes, it's even worse
Jan 04 10:14:49 <stintel> when I enable sqm with 300/300 -> 125Mbit down, 200 up
Jan 04 10:15:20 <Borromini> stintel: on an APU2?
Jan 04 10:15:24 <stintel> yes
Jan 04 10:15:29 <stintel> it's downright horrible
Jan 04 10:15:30 <Borromini> :-/
Jan 04 10:15:34 <Borromini> really showing its age
Jan 04 10:15:43 <stintel> 1GHz is useless
Jan 04 10:15:47 <mangix> what ethernet interface does it have?
Jan 04 10:15:50 <stintel> even if you have 4 cores
Jan 04 10:15:51 <Borromini> i have only 100 Mbps down so far, and sqm isn't really taxing my octeon :P
Jan 04 10:15:57 <stintel> I210
Jan 04 10:16:44 <mangix> Borromini: you have octeon?
Jan 04 10:16:50 <Borromini> mangix: yeah. edgerouter 4
Jan 04 10:16:55 <Borromini> and a lite on the way as a testing device
Jan 04 10:17:02 * Borromini has been on a second-hand shopping spree
Jan 04 10:17:10 <stintel> :p
Jan 04 10:17:14 <Borromini> well the 4 was new :P
Jan 04 10:17:16 <stintel> ERL is my backup router here
Jan 04 10:17:19 <Borromini> missus said okay :P
Jan 04 10:17:24 <rsalvaterra> stintel: Something's not right, there… I have an APU2 managing two WAN connections and have no problems with SQM (250/50 and 130/10 Mb/s).
Jan 04 10:17:41 <stintel> and have a 2nd one for testing before I update the production one
Jan 04 10:18:09 <Borromini> stintel: yeah that's why i have been shopping around.
Jan 04 10:18:23 <stintel> Borromini: but you really should have gotten a 2nd er4 :P
Jan 04 10:19:15 <mangix> er4
Jan 04 10:19:22 <mangix> is that a serial connection i see?
Jan 04 10:19:46 <mangix> nvm, SFP
Jan 04 10:19:57 <Borromini> mangix: it has serial as well, rj45
Jan 04 10:20:01 <mangix> oh it's on the other side
Jan 04 10:20:06 <Borromini> yeah.
Jan 04 10:20:16 <Borromini> stintel: it's expensive enough :-/
Jan 04 10:20:48 <Borromini> got an erl for 40 € :)
Jan 04 10:21:26 <mangix> 1ghz mips. interesting
Jan 04 10:21:52 <mangix> wait, this is a new router?
Jan 04 10:21:52 <Borromini> mips64
Jan 04 10:22:10 <stintel> ERL is ancient
Jan 04 10:22:12 <Borromini> mangix: 40 € second hand if that's what you mean
Jan 04 10:22:15 <stintel> but also mips64
Jan 04 10:22:48 <stintel> but at 1GHz I doubt it's going to be much faster than the apu2
Jan 04 10:23:20 <mangix> hmm if memory server me correct, some octeon driver is in staging at kernel.org
Jan 04 10:23:30 <mangix> or did it get removed
Jan 04 10:23:46 <Borromini> stintel: i think damex ran some tests after he added support but not sure what kind of pipe he has
Jan 04 10:24:08 <stintel> mangix: it was removed and later that removal was reverted
Jan 04 10:24:09 <Borromini> but yes, erl is old. point was to have another octeon for testing though
Jan 04 10:24:25 <rsalvaterra> stintel: Are you doing your own builds for the APU?
Jan 04 10:24:38 <stintel> rsalvaterra: I do my own builds for all my devices
Jan 04 10:24:50 * mangix is reading tc-cake man page
Jan 04 10:24:51 <rsalvaterra> Yeah, I thought so. :)
Jan 04 10:24:54 <mangix> seems over engineered
Jan 04 10:25:00 <damex> Borromini: i have 0.5GbE at home.  gpon.
Jan 04 10:25:24 <Borromini> damex: cool :)
Jan 04 10:25:26 <damex> actually 500Mbit that bursts to 550~600 from time to time
Jan 04 10:25:30 <stintel> I have 1000/600 but there's a bottleneck somewhere on ISP side that limits me at ~350/350
Jan 04 10:25:38 <rsalvaterra> stintel: you might want to try this… https://gitlab.com/rsalvaterra/openwrt/-/commit/dca20eb1c94a8eb8b3429cd34c323658b6bfa17e
Jan 04 10:25:42 <stintel> but with sqm/cake -> 120/200
Jan 04 10:25:49 <damex> oh, forgot to mention 500/500 it is
Jan 04 10:26:23 <stintel> I still have to give them a call about it but it's usually not easy to get someone competent on the phone, nor someone who speaks/understands English properly
Jan 04 10:26:37 <stintel> and as long as I don't have this sqm issue sorted ...
Jan 04 10:27:24 <mangix> australian internet is known as oceanic
Jan 04 10:27:27 <mangix> didn't know that
Jan 04 10:27:51 <damex> stintel: it could be.  what saves apu2 is intel nic's that can offload some queues
Jan 04 10:28:08 <damex> octeon does not have that (yet)
Jan 04 10:28:19 <mangix> cake supports interplanetary traffic
Jan 04 10:28:21 <mangix> amazing
Jan 04 10:28:28 <Borromini> stintel: from PC Engines or from your ISP?
Jan 04 10:28:52 <stintel> Borromini: the 350/350 bottleneck? pretty sure it's on the ISP side
Jan 04 10:29:03 <stintel> Borromini: inter-VLAN does > 900Mbps
Jan 04 10:29:16 <stintel> although there is no NAT involved there
Jan 04 10:31:24 <stintel> but I doubt that alone will divide speed by 3
Jan 04 10:38:35 <ldir> rsalvaterra: Doesn't adding '-march=btver2' to 'CONFIG_TARGET_OPTIMIZATION' in .config do the same thing?
Jan 04 10:39:50 <stintel> that makes your {build,staging}_dir incompatible with intel CPUs
Jan 04 10:40:09 <rsalvaterra> ldir: I *think* the kernel is a separate thing, I'm not entirely sure.
Jan 04 10:40:22 <rsalvaterra> stintel: Sounds like a feature, then. :P
Jan 04 10:40:40 <stintel> so you'd have to completely wipe them every time you do a build for a btver2 device vs any intel device
Jan 04 10:40:54 <stintel> I've been thinking of a nice way to solve that
Jan 04 10:41:10 <ldir> as I'm only building for the apu I don't mind.
Jan 04 10:41:13 <mangix> ldir: given you worked on cake, what happens with sysctl -w net.core.default_qdisc = fq_codel
Jan 04 10:41:18 <mangix> sorry, = cake
Jan 04 10:41:22 <rsalvaterra> I'm only building for the APU2C4, so I don't have that problem yet…
Jan 04 10:41:47 <stintel> that we can have more optimized variants with proper suffixed dirs in {build,staging}_dir to make people happy, but buildbots/official images just keep doing _generic_
Jan 04 10:42:08 <stintel> but so many things to do, such little time
Jan 04 10:42:45 <lemmi> one cause of poor performance on ingress shaping is that all traffic as to pass through a loopback device. there is quite some performance to be had to just mark incomping wan traffic and then shape the marked packets on the lan interface
Jan 04 10:42:56 <xback> nbd: Are the minstrel changes also valid for 19.07? I would backport them otherwise
Jan 04 10:43:01 <ldir> mangix: I'd expect it to work, however it would be in 'unlimited' mode and so rely on interface back pressure to do the pacing... ie BQL.
Jan 04 10:43:11 <rsalvaterra> ldir: According to this patch, https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/pending-5.4/201-extra_optimization.patch;h=c60648799277c84b59089531ee68823f041d4156;hb=HEAD…
Jan 04 10:43:41 <lemmi> if the router doesn't pass any lan traffic, all outgoing traffic on the lan port can be shaped
Jan 04 10:43:55 <lemmi> makes it quite a bit easier to setup
Jan 04 10:43:56 <rsalvaterra> … I guess you could add -mtune=btver2 to the CONFIG_EXTRA_OPTIMIZATION, yes.
Jan 04 10:47:14 <nbd> xback: i'd prefer to let them sit in master for a bit of time before the backport
Jan 04 10:47:21 <nbd> since the changes are quite intrusive
Jan 04 10:47:26 <nbd> just to make sure there are no critical regressions
Jan 04 10:47:35 <nbd> but afterwards, a backport would be a good idea
Jan 04 10:48:35 <xback> nbd: thanks for the fast rerply.  I'll backport it to my staging 19.07 and give it a thorough spin on a few dozen devices
Jan 04 10:49:26 <xback> it can be cherrypicked to main 19.07 later on then at a convenient time
Jan 04 10:59:09 * ldir dammit - have typed make dirclean instead of make clean - guess I'll be rebuilding the toolchain first then
Jan 04 10:59:34 * stintel lends ldir some cores
Jan 04 10:59:39 <Borromini> :P
Jan 04 11:00:00 <ldir> they won't fit in my macbook :-(
Jan 04 11:00:04 <stintel> :D
Jan 04 11:05:02 <zorun> nbd: speaking of mac80211, would https://git.openwrt.org/08a42ef057b0c1c3 apply to 19.07? there have been reports of kernel memleaks on 19.07
Jan 04 11:05:20 <rsalvaterra> stintel: Speaking of the APU, I'm getting a GPIO error when I build the pcengines-apu2 driver monolithically. If it's built as a module, the error goes away. Have you noticed this?
Jan 04 11:06:38 <nbd> zorun: no, that patch fixes a regression in changes that have not been backported to 19.07
Jan 04 11:07:20 <zorun> ah, thanks
Jan 04 11:08:03 <stintel> rsalvaterra: I haven't, I just enabled the kmod in my .config but I'm don't even think I am using it
Jan 04 11:09:08 <rsalvaterra> stintel: You need it for LED support.
Jan 04 11:11:39 <stintel> rsalvaterra: I never really cared about that
Jan 04 11:12:18 <rsalvaterra> stintel: But, but… them blinkenlights…!
Jan 04 11:12:38 <stintel> I have enough of those on my switch and fileserver :P
Jan 04 11:12:45 <stintel> it's my permanent christmas tree
Jan 04 11:12:50 <stintel> (my rack)
Jan 04 11:13:02 <rsalvaterra> XD
Jan 04 11:19:23 <Borromini> demblinkenlights <3
Jan 04 11:20:34 <rsalvaterra> Yeah, they're nice during the day… no so much at night, when you have networking equipment in your bedroom. :P
Jan 04 11:23:26 <stintel> I believe I had a switch that supported scheduled disabling of all LEDs
Jan 04 11:27:34 <rsalvaterra> The problem is my sleep schedule is… flexible. :P
Jan 04 11:28:27 <stintel> sounds familiar
Jan 04 11:28:50 <stintel> only "network" hardware in my bedroom are some z-wave and zigbee devices
Jan 04 11:28:52 <rsalvaterra> Goes with the territory, I guess. :P
Jan 04 12:11:20 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_sunxi.html has been updated. (0% images and 98.2% packages reproducible in our current test framework.)
Jan 04 14:41:32 <ldir> rsalvaterra: as an FYI your apu kernel arch patch is required... or when I looked through my build log the kernel didn't get built with march=btver2 unless I had your patch.  So I was building all the packages with btver2 but not the kernel.  I wonder how much difference it really makes.
Jan 04 15:00:30 <rsalvaterra> ldir: Actually you don't need the kernel patch, I just tested. But what you need is no less hacky, in my opinion. :P
Jan 04 15:01:09 <rsalvaterra> You need to add -mtune=btver2 to CONFIG_EXTRA_OPTIMIZATION.
Jan 04 15:11:20 <ldir> Oh, does it also get applied to the packages ?
Jan 04 15:11:38 <ldir> if so, then to be honest, it's perfect for me :-)
Jan 04 15:17:05 <rsalvaterra> ldir: For packages, it's CONFIG_TARGET_OPTIMIZATION. :)
Jan 04 15:17:48 <rsalvaterra> This is what I have…
Jan 04 15:17:53 <rsalvaterra> CONFIG_EXTRA_OPTIMIZATION="-mtune=btver2"
Jan 04 15:17:53 <rsalvaterra> CONFIG_TARGET_OPTIMIZATION="-O2 -pipe -march=btver2"
Jan 04 15:18:08 <ldir> So if I do both then great, and it's stored in the .config so changeable via envs
Jan 04 15:35:25 <reiffert> Hello - I'm trying to get openwrt onto mikrotik hex aka rb750gr3, the openwrt-19.07.5-ramips-mt7621-mikrotik_rb750gr3-initramfs-kernel.bin is booted via tftp, the booted OS requests an IP via dhcp, it gets one.
Jan 04 15:35:51 <reiffert> I can ping the new IP, but telnet, ssh, http, https are closed. I can see the device make ntp queries with the world.
Jan 04 15:38:30 <reiffert> I'm following https://openwrt.org/toh/mikrotik/mikrotik_rb750gr3 the instructions and I noticed that the port 1 used for dhcp/tftp/pxe is the WAN port of the router.
Jan 04 15:38:54 <reiffert> it would explain that the mgmt ports are closed.
Jan 04 15:40:13 <reiffert> yep - that's it. Thanks for solving my problem :)
Jan 04 17:02:36 <enyc> Hrrm ...  particular dev version note!   on Lantiq HHv5a --  console to 'failsafe' and then doing  "firstboot" to reset config (then "reboot"), does not work -- same config still there after 'reboot'.
Jan 04 17:02:58 <enyc> [   25.342753] jffs2reset: /dev/ubi0_2 is not mounted
Jan 04 17:02:58 <enyc> [   25.346379] jffs2reset: /dev/ubi0_2 will be erased on next mount
Jan 04 17:02:58 <enyc> [   25.352609] jffs2reset: writing /dev/ubi0_2 failed: Operation not permitted
Jan 04 17:31:17 <dangole> enyc: yeah, that can't work in the way it is done now... jffs2_mark is called in jffs2reset.c and doesn't check anywhere if we are dealing with a UBI volume. shouldn't be hard to fix though
Jan 04 17:32:35 <dangole> enyc: ie. the way to go for now would be to call 'mount_root' before calling 'firstboot'
Jan 04 17:45:44 <enyc> dangole: ok, should I or you report a bug somewhere [where is best in this devel stage???]
Jan 04 17:51:22 <dangole> enyc: i'm looking into it and will fix it, i have UBI hardware to try at hand. what we want is doing `int b=0; ioctl(fd, UBI_IOCVOLUP, &b);` or something like that in case of ubi overlay
Jan 04 17:57:18 <enyc> dangole: thankyou! plesaed my feedback helpful.
Jan 04 17:57:54 <enyc> I was just literally solderig up some ttl-serial 3-wire-header extenders... will have console on my next HHv5a so can have logging if any crashing persists .......
Jan 04 18:13:38 <enyc> dangole: any $clue if i can/should set  debug-level-4  automatically on serial console, rather than manually typing '4' on boot...
Jan 04 18:45:35 <aparcar[m]> jow: are you okay with the findrev Patch? It would affect luci package names
Jan 04 19:57:59 <xdarklight> Hauke: can you please do me another favor? https://github.com/torvalds/linux/blob/58c9e24721c4a84eb5a6db3c1d54dba97e97b3f7/arch/mips/lantiq/xway/sysctrl.c#L540 this AHB clock gate, is the only usage the PCIe RC or is there another user of the "AHBS" (S = slave?)?
Jan 04 20:16:47 <dangole> enyc: fstools patch for firstboot on UBI is ready for testing. in case you were running your own build, it'd be great if you can test with the patch.
Jan 04 20:53:35 <Hauke> xdarklight: as far as I remomber the AHB bus is only used to conenct the PCIe controller to the central corssbar
Jan 04 20:54:24 <xdarklight> Hauke: thanks, that will make updating the alias in sysctrl.c easier (needed for getting the mainline PCIe driver to work)
Jan 04 20:54:44 <Hauke> and USB
Jan 04 21:01:04 <shibboleth> PaulFertser, so far, so good
Jan 04 21:02:00 <xdarklight> Hauke: is USB connected to "AHBM" or "AHBS"? so far we only describe the USB connection to AHBM, but not AHBM
Jan 04 21:02:20 <xdarklight> sorry, we for USB we describe the connection to the AHBM clock but not the ABH*S* clock
Jan 04 21:03:05 <Hauke> bit 13 in PMU_PWDCR and PMU_SR is reserved in the VR9
Jan 04 21:04:38 <Hauke> AHBS gibt es nur als bit 3 im CGU_CLKGCR0
Jan 04 21:09:22 <dangole> enyc: i've pushed a fix for the problem with firstboot on UBI you reported. tested on oxnas and did the trick. thanks for reporting!
Jan 04 21:12:44 <Hauke> dangole: the commit message does not match the code any more: https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=commitdiff;h=b7f0e92203e7d01dd11cb61426f615bf5c67abab
Jan 04 21:13:59 <aparcar[m]> jow: this rsync docker container in buildbot.git drives me nuts. It prints "can't set permisison: file not found" while it still creates the file. This error message seems unknown to the internet
Jan 04 21:17:36 <dangole> Hauke: true, I'll remove the no longer relevant parts
Jan 04 21:25:52 <PaulFertser> shibboleth: you got lucky, thanks to dangole ! See, every individual package needed its own commit, plus REV bump (sorry for missing that).
Jan 04 21:26:19 <shibboleth> hey, the more the merrier :P
Jan 04 21:27:00 <shibboleth> seems robimarko also is also pushing for it
Jan 04 21:27:04 <PaulFertser> shibboleth: it really makes sense for the maintainers, it's not an arbitrary out-of-the-blue thing.
Jan 04 21:27:07 <shibboleth> is also...
Jan 04 21:28:45 <dangole> Hauke: was wondering if we should add logic to netifd's netifd-wireless.sh to default to GCMP on 802.11ad. But I'm not even sure if that's a sensible thing to do, maybe other (?) 802.11ad hardware does support CCMP (?) or it's written in the standard that it should be GCMP for 11ad and that's it?
Jan 04 21:30:04 <dangole> shibboleth, PaulFertser: I was merely collecting the already split-out patches from lynxis staging tree. robimarko published them long ago on github in a series to support mikrotik 60ghz dish
Jan 04 21:31:06 <shibboleth> yeah, robi was told to go refactor
Jan 04 21:33:01 <shibboleth> the v2 reuses the mac80211.sh logic for ac as opposed to his v1
Jan 04 21:33:02 <shibboleth> well, a/an/ac
Jan 04 21:38:24 <lynxis> adrianschmutzler: merged the edma. so now it's possible to take a look onto the 60ghz
Jan 04 21:38:33 <shibboleth> adrianschmutzler, the proposes ad7200 dts is, by choice, as similar as the long-since-approved dts for c2600 to make maintenance less of a hassle
Jan 04 21:39:59 <shibboleth> since the devices are in essence identical
Jan 04 21:42:18 <shibboleth> the thinking is that if the c2600/ad7200 dts veer of in different directions maintenance is no longer a matter of maintaining one, updating the other
Jan 04 21:43:58 <shibboleth> veer off even. do you disagree?
Jan 04 21:45:34 <Hauke> dangole: I do not know much about ad
Jan 04 21:46:30 <Hauke> If the QCA device sdo not supprot CCMP is assume this is not so common
Jan 04 21:46:54 <Hauke> I would make GCMP the default on 802.11ad
Jan 04 21:47:00 <dangole> Hauke: i'm not even aware any other 11ad hardware being available...
Jan 04 21:47:06 <shibboleth> i'm happy to change the patch, but then we suddenly have two identical devices with different "formatting"
Jan 04 21:47:20 <Hauke> I think there is some Intel hardware
Jan 04 21:47:22 <Hauke> but I am not sure
Jan 04 21:48:04 <shibboleth> the mikrotok wap60g(x3), lhgg-60ad, ad7200, etc
Jan 04 21:48:17 <pkgadd> https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/tri-band-wireless-ac17265-brief.pdf
Jan 04 21:50:09 <Hauke> pkgadd: have you ever seen a laptop with it?
Jan 04 21:50:22 <shibboleth> i believe gcmp is used to facilitate the (much) higher bw of 11ad
Jan 04 21:50:23 <pkgadd> Hauke: nope
Jan 04 21:50:46 <shibboleth> both dell and lenovos have shipped with ad radios
Jan 04 21:50:49 <lynxis> Hauke: i've seen those in some thinkpads. but i think they integrated some stuff into it.
Jan 04 21:51:13 <shibboleth> afaik gcmp *can* be used for ac as well
Jan 04 21:51:55 <pkgadd> shibboleth: that's just a matter of client support
Jan 04 21:54:09 <rsalvaterra> What cards do GCMP in hardware, does anyone have any idea?
Jan 04 21:54:17 <shibboleth> qca9500?
Jan 04 21:55:10 <rsalvaterra> Ok, and n/ac/ax? ;)
Jan 04 21:56:02 <pkgadd> at least ath9k (on ar9285)
Jan 04 21:56:31 <pkgadd> GCMP-128 (00-0f-ac:8), GCMP-256 (00-0f-ac:9)
Jan 04 21:57:33 <rsalvaterra> pkgadd: Are you sure it's in hardware? Because iw list doesn't always make a distinction… :/
Jan 04 21:57:49 <pkgadd> rsalvaterra: sorry, I'm not ;)
Jan 04 21:58:26 <rsalvaterra> :)
Jan 04 21:58:36 <shibboleth> the lhgg60ad and wap60g are especially interesting devices (long-distance links) but have som hw/fw-kinks, whereas the ad7200 is essentially a c2600. if the 11ad stuff could finally be merged those devs will only have to focus on the mikrotik kinks
Jan 04 21:58:53 <rsalvaterra> For example, it says my RT2790 supports GCMP-256… :P
Jan 04 21:59:27 <shibboleth> owrt 11ad-support has been "caught up in committee" for years at this point and that's pretty much it
Jan 04 22:00:22 <rsalvaterra> dangole: ping
Jan 04 22:00:28 <dangole> rsalvaterra: pong
Jan 04 22:00:53 <rsalvaterra> dangole: No opinion on the x86 gc-sections patch? :)
Jan 04 22:01:37 <dangole> rsalvaterra: imho it should go to target/linux/x86/... 'x86' is our only 'x86' target, so no need to carry it in generic
Jan 04 22:02:18 <rsalvaterra> Right, but we already have a similar patch for ARM in generic/hack-5.4, that's why I asked… :P
Jan 04 22:02:29 <adrianschmutzler> shibboleth: I'm quite sick of this "we cannot do obvious improvements because the new device has to be like the ancient support of some other device" thing
Jan 04 22:03:28 <adrianschmutzler> particularly since you prove that this is not working, as you keep stuff that makes no sense for a new device like BOARD_NAME and SUPPORTED_DEVICES
Jan 04 22:04:04 <shibboleth> that's not what i said :). i simply stated that the current formatting/thinking was to stay as true to c2600 as possible to avoid maintenance overhead.
Jan 04 22:04:28 <shibboleth> and the c2600 has a much larger userbase. any change to the c2600 dts should be safe-to-clone to the ad7200
Jan 04 22:04:51 <adrianschmutzler> well, if you are convinced by that, please create a shared DTSI because that is actually reducing maintenance overhead
Jan 04 22:05:18 <dangole> rsalvaterra: yes, but that one is actually also used by more than one target
Jan 04 22:05:19 <adrianschmutzler> and by that, you have a chance to improve the support for both devices
Jan 04 22:05:27 <xdarklight> Hauke: haha, thanks. seems like an old bug in sysctrl.c then. then only AHBM is relevant, but that's important for us :)
Jan 04 22:05:43 <aparcar[m]> adrianschmutzler: for base-files, would you prefer versioning with just a number (204, 205, etc) or the luci style (year.day.second-revision)
Jan 04 22:05:48 <shibboleth> not working? i'm... perturbed?
Jan 04 22:06:38 <adrianschmutzler> aparcar[m]: I don't really know the luci style, but if nobody objects and you think it's a good idea, go for it
Jan 04 22:06:56 <rsalvaterra> dangole: I see. So in x86, it means the patch is only applied for x86(-64) kernel builds, right?
Jan 04 22:06:56 <adrianschmutzler> essentially, the PKG_RELEASE bumping is a pain
Jan 04 22:07:28 <aparcar[m]> luci style is longer but better to put into context, it's e.g. 21.2 which means the wesion is 2 days old. a number is shorter which may look better :p
Jan 04 22:07:31 <adrianschmutzler> aparcar[m]: and if that proves to be a good idea, please also apply it to uboot-envtools
Jan 04 22:07:39 <Hauke> xdarklight: I checked multiple versions of the document and all say it is reserved
Jan 04 22:07:40 <shibboleth> adrianschmutzler, they're not identical. three leds have diff pins, spi4/spi5
Jan 04 22:08:22 <xdarklight> Hauke: I'm not questioning it - I just find it interesting to stumble across such an old bug in sysctrl.c :)
Jan 04 22:08:23 <adrianschmutzler> shibboleth: that's the idea of a DTSI: have the shared stuff in the DTSI, and the specific stuff in the DTS
Jan 04 22:08:51 <Hauke> xdarklight: changing this bit probably does nothing
Jan 04 22:09:17 <Hauke> but I am suprised where this is comming from
Jan 04 22:09:17 <xdarklight> Hauke: yep. at least we have tested for years that it doesn't make devices explode :)
Jan 04 22:09:38 <adrianschmutzler> but I still don't see the reason for not improving the DTS ...
Jan 04 22:13:27 <dangole> rsalvaterra: exactly. I understood right that it only affects x86?
Jan 04 22:13:52 <adrianschmutzler> shibboleth: just see it from the opposite side: every new similar device added is a chance to improve the existing codebase
Jan 04 22:15:30 <rsalvaterra> dangole: Yes, only x86 and x86-64.
Jan 04 22:16:08 <rsalvaterra> I'd like to cook something for arm64, but I don't have the hardware to test… :/
Jan 04 22:16:20 <rsalvaterra> It's the only missing "big" platform, I guess.
Jan 04 22:17:34 <shibboleth> i have. the thinking was that since the c2600 has a much larger userbase any changes to the conventions/formatting is easier to test
Jan 04 22:17:45 <shibboleth> for/with that device
Jan 04 22:19:23 <adrianschmutzler> hmm, I just looked at my e-mail again and did not find any changes that require specific testing
Jan 04 22:20:02 <adrianschmutzler> just stuff like labels etc. where pain only comes from changing them once they are established
Jan 04 22:20:17 <adrianschmutzler> i.e. it pays off to have them right from the beginning
Jan 04 22:26:14 <shibboleth> afaik there is a v2-variant (only supported by the updated/second stock fw) wlan0/phy0tpt was due to cfg/nl80211 and not mac80211
Jan 04 22:26:23 <shibboleth> but i'll try it out
Jan 04 22:38:38 <adrianschmutzler> well, phy0tpt instead of wlan0 would be the biggest gain to get there
Jan 04 23:07:43 <enyc> dangole: I'm best to test next master build when I reflash another new HHv5a soon!
Jan 04 23:08:47 <enyc> dangole: was just asying ... thankyou,  when I get another HHv5a soon/shortly i'll install next master build, test the config resetting then .............
Jan 04 23:09:43 <enyc> more heisenbugs ;p
Jan 04 23:10:19 <enyc> now I've set config with ipv6-only explicitly (rather than ipv4 addr and no route, or so)  openwrt *is* updating NTP over ipv6 without separate ntp build install!
Jan 04 23:11:55 <enyc> got serial log and syslog being saved, so if I get any more rebooting-itself   I'll have (some) log to show for it
**** ENDING LOGGING AT Tue Jan 05 03:01:24 2021