dangole has quit [Remote host closed the connection]
feriman has quit [Ping timeout: 246 seconds]
dangole has joined #openwrt-devel
<rsalvaterra> lipnitsk: I haven't tested the RM2100 yet, I was sleeping and/or out for a good part of the day. I have built an image, though. :)
<mangix> it appears I will join in the mt7621 fun soon
<mangix> I purchased the only OpenWrt supported ax device
<mangix> I doubt it'll even work
<mangix> LMFAO
<mangix> libbpf version 0.3.0 is too low, please update it to at least 0.1.0
<rsalvaterra> mangix: That's guidosarducci's department. :P
<rsalvaterra> He has a patch to fix that.
<pkgadd> mangix: the linksys e8450/ belkin rt3200 or totolink x5000r or UniFi 6 LR?
<mangix> pkgadd: totolink x5000r
<guidosarducci> mangix: there's a pkgconfig fix waiting to be merged that could be related: https://github.com/openwrt/openwrt/pull/3956
<guidosarducci> mangix: the problem isn't consistently reproducible however.
<mangix> meh just marked both as BROKEN
<pkgadd> hmm, I kind of doubt mt7621 is fast enough for 802.11ax, routing and the other stuff one might want to run on a fast WAN connection (sqm, vpn, ...) - the e8450/ rt3200 however...
<mangix> pkgadd: I don't have fast WAN
<pkgadd> it's a bit of a pity that ipq807x seems to be so difficult to get ethernet and wireless right
<mangix> yeah. that's why I don't bother with them
<mangix> there's a reason blogic calls QCA Qualcomm Crack Addicts
<pkgadd> yeah... still nice hardware
<mangix> anyway, core developer has the totolink. Should be in good shape.
<pkgadd> if it wouldn't be post-Brexit importing from the UK (and associated customs duties + other complications), I might have gone for the rt3200 nevertheless
<mangix> it was an impulse buy on my end
<pkgadd> yep, I'm close to it - but not for 20-25 EUR shipping and customs on top (which seems to be the rough range I'd have to consider)
<mangix> interesting that the other devices use mt7615e for 2.4ghz
<mangix> is that esata on the linksys device i see?
<pkgadd> afaik only USB3
<pkgadd> err, just USB2
<mangix> it says kmod-ata-ahci-mtk under device packages
<mangix> also that USB port looks weird.
<mangix> I think it's a combo port like the previous WRT series
<dangole> no ahci in that device
<dangole> it's just USB 2.0
<mangix> why is kmod-ata-ahci-mtk included?
<dangole> (ahci is built-in on MT7622 kernel because SoC has AHCI controller)
<dangole> otherwise the recent kmod-ahci-renesas catastrophy would have affected mediatek target as well
<mangix> unfortunate
<dangole> it didn't because it's built-in... (imho shouldn't be)
<pkgadd> dangole: do you have a rough feeling where the routing limits are with mt7622b and this device? can it achieve routing at 1 GBit/s wirespeed (soe margin left for e.g. SQM, etc.)?
<dangole> pkgadd: i haven't tried with SQM
<pkgadd> o.k.
<dangole> pkgadd: but generally feels super fast, SCP file upload to /tmp with 40 megabyte / second
<pkgadd> nice
<dangole> pkgadd: tell me what to test, i got the device wired up next to me
<mangix> danitool: iperf router to pc get 930mbps?
<mangix> dangole: ^^
<dangole> mangix: yes, of course. i'll post pastebin to iperf3 in a moment
<pkgadd> dangole: no need to test anything special, but a rough feeling if it can route at those ~930 MBit/s and how much CPU cycles are left (htop) would be very interesting to know
<mangix> i ask because of mt7621 does not
<pkgadd> I'm asking because of my 400/200 MBit/s line, my current ipq8065 can do that (rather comfortably) - but dabbling into SQM wouldn't be possible on that hardware
shibboleth has joined #openwrt-devel
<dangole> mangix: https://asciinema.org/a/397173 (iperf3) and https://asciinema.org/a/397172 (htop) running in parallel
<dangole> pkgadd: ^^^^
<pkgadd> dangole: thanks a lot, so around 40% CPU usage on one of the two cores for ~900 MBit/s
<pkgadd> that's pretty promising
<dangole> the gmac has two interrupts, i set affinity for both to core 2 to have core 1 deal with wifi a bit faster (+20 Mbit/s)
<guidosarducci> dangole: nice performance. Can TX/RX use both CPUs?
<dangole> guidosarducci: in which sense?
<guidosarducci> dangole: e.g. is RX processing limited to 1 CPU.
<dangole> it got two interrupts which both fire during RX, you can set irq affinity to two different cores, if that is what you mean
<mangix> very nice
<guidosarducci> dangole: thanks, that's what I meant.
<dangole> guidosarducci: https://termbin.com/et5p
<dangole> (the few interrupts on the first core are traffic before i manually set them to core 2, default is affinity 0x3 for both irqs)
<guidosarducci> dangole: understood, I was wondering about the 3X skew. BTW, what's "mtk-ecc"?
<pkgadd> guidosarducci: should be the NAND driver
<dangole> exactly, that's the ECC engine used for both, SPI-NAND and parallel NAND
<lipnitsk> blogic: ping
<guidosarducci> dangole: neat, I haven't played with MTK before so that's new. I'm also surprised the tweaking the affinity made such a big difference in wifi speed.
<dangole> guidosarducci: it's trading ~40 MBit/s +/- Ethernet performance for ~20 MBit/s +/- Wifi
<dangole> i guess because Ethernet performance is better with less context switching while wifi works better with more parallelization (?)
<dangole> with all the offloading wifi anyway easily bottleknecks gigE. haven't tried bonding yet to see if we can get 2Gbit/s in that way...
<dangole> that ubiquiti unifi 6 lr device got 2.5Base-T, so i wonder how mt7622+mt7915e perform on that as AP...
<guidosarducci> dangole: I think that's a good trade off. Wifi performance always seems less predictable than ethernet. I think you're right re: switching: for forwarding use case on ethernet, CPU/memory locality is a preferred thing.
<dangole> but more than double the price...
<lipnitsk> @dangole any idea why we have mtk-eth patches under mediatek and ramips? Can we just consolidate them under generic? I'm talking about ./mediatek/patches-5.10/700-net-ethernet-mtk_eth_soc-add-support-for-coherent-DM.patch and ./ramips/patches-5.10/700-net-ethernet-mediatek-support-net-labels.patch. Should those just move to generic/pending-5.10?
<guidosarducci> dangole: I guess you pick your crack: QCA or MTK...:)
<dangole> guidosarducci: at least with mtk it gets very useful even with "only" 512MB of ram. ath11k wouldn
<dangole> 't work in a meaningful way i've heard
<pkgadd> dangole: afaik (unless anything changed rather recently), blocktrron hasn't been able to make 2.5BASE-T work yet (and it's not officially marketed to exist)
<pkgadd> on the unifi
<dangole> pkgadd: oh, that's sad.
<dangole> lipnitsk: i agree, and i can test on MT7622 :)
<lipnitsk> the labels thingy is pretty generic - a way to set MAC label from dts.. not sure why that needs to be ramips-specific. The coherent DM thing may not apply to ramips, or it might :) I can test on mt7621
<lipnitsk> dangole: okay, I'll put something together.
<dangole> lipnitsk: label mac from dts works on mt7622 as well, i didn't even know that needs an extra patch
<lipnitsk> works with dsa and everything?
<lipnitsk> maybe it's the devicetree structure, let me see.
<dangole> it set's the ifname under linux actually
<lipnitsk> yeah but from which node
<lipnitsk> ports?
<lipnitsk> or you mean, that the ifname is already set somewhere, no need to set it inside the driver?
<lipnitsk> maybe we can just drop that patch then.
<dangole> it get's a 'label' property in mtk_eth_soc.c and uses that as ifname if set
<lipnitsk> 'label' from which node though? switch0-ports-port@X?
<lipnitsk> it's the gmac node the eth driver looks at I think. switch nodes are handled in the switch driver
shibboleth has quit [Quit: shibboleth]
<guidosarducci> jow: I finally managed to get the DSCP/MARK chains all working in fw3, based on your samples. Still need to clean up then I'll post for you to see. One problem I ran into is with fw3_zone->devices having duplicate entries, creating duplicate rules.
<mangix> lipnitsk: putting patches in generic sounds great
<lipnitsk> yeah I'll move some generic patches out of platform, at least for ramips for now
<mangix> speaking of ramips, some patches need upstreaming :P
<lipnitsk> yes they do
<lipnitsk> It's kind of a mess to unravel..
hbug__ has joined #openwrt-devel
<mangix> i have no idea what this is
hbug_ has quit [Ping timeout: 268 seconds]
<pkgadd> that should be a webcam, but why that's part of rampis specific patches...
<pkgadd> D-Link DIR-930 IP cameras
<mangix> wonder why it was not merged.
<pkgadd> seems to be this thing, https://wikidevi.wi-cat.ru/D-Link_DCS-930L_rev_A1 (yes, DIR vs DCS, but I think so)
<lipnitsk> mangix: probably because blogic didn't have time to pursue it?
<mangix> lipnitsk: I mean, there are no messages on there
<mangix> ah ok
<lipnitsk> this one kind of bothers me too: https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/patches-5.10/316-arch-mips-do-not-select-illegal-access-driver-by-def.patch seems to be an informational driver that's just disabled in openwrt for whatever reason. Why is it enabled on mainline by default.. probably should change that default to n and make it visible in menuconfig
<lipnitsk> ie upstream the patch.
dansan has quit [Ping timeout: 256 seconds]
<mangix> wonder if some of russell king's patches should be added
<lipnitsk> mangix: what are those?
victhor has quit [Ping timeout: 256 seconds]
<lipnitsk> mangix: backports from latest mainline?
<mangix> seems he's adding some feature
<mangix> lipnitsk: I have no idea
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
Tost has quit [Ping timeout: 256 seconds]
goliath has quit [Quit: SIGSEGV]
<lipnitsk> is there a good place to host a datasheet so I can link it in the upstream patch?
<lipnitsk> http://www.anz.ru/files/mediatek/MT7620_ProgrammingGuide.pdf is dead, but the guide is out there, just on non-direct-link sites
<Grommish> damex: ping
dannyAAM has quit [Remote host closed the connection]
dangole has quit [Remote host closed the connection]
dannyAAM has joined #openwrt-devel
_whitelogger has joined #openwrt-devel
dannyAAM has quit [Remote host closed the connection]
dannyAAM has joined #openwrt-devel
dannyAAM has quit [Remote host closed the connection]
dannyAAM has joined #openwrt-devel
Fishman has joined #openwrt-devel
Fishman has quit [Changing host]
Fishman has joined #openwrt-devel
<guidosarducci> jow: I've a draft of cleaned up and tested code for the fw3 dscp/mark fixes we discussed. I'd appreciate your comments or review: https://github.com/guidosarducci/firewall3/commits/master-fix-dscp-mark
danitool has quit [Ping timeout: 245 seconds]
<damex> Grommish: pong. and still, no matter how bad it is - i don't see anyone from openwrt reverting that patch at this point considering how badly it was pushed down.
nyt has quit [Ping timeout: 256 seconds]
Guest87637 has joined #openwrt-devel
Fishman has quit [Quit: biab (i hope...)]
<Grommish> damex: I don't want a revert, I want a discussion on how to fix the issue
<Grommish> damex: Be it by splitting the targets or removing the offending device
<Grommish> damex: Or something else :)
<damex> Grommish: it had to be discussed before creating an issue in the first place
<damex> oh well
<Grommish> damex: eh, we are beyond that.. but now I've got numbers saying that patch reduces RAM throughput by 1/5th
<Grommish> damex: the question is how to fix
Grommish__ has joined #openwrt-devel
<damex> revert -> start discussion -> implement properly
<Grommish> Whie I'd agree,, the argument will be that it was supposed to be working the entire time :/, so I have to go with that angle
<Grommish> You have to admit, it isn't often a broken bug increases perf ;p
Grommish_ has quit [Ping timeout: 246 seconds]
<Grommish> Anyway, the only thing that can be done is report the findings.. I posted the script I used so others can do an A/B test if they desire
<damex> Grommish: you need to test 'network' performance if you want to benchmark something decide intends to do
<Grommish> I can do that easy enough
<damex> run iperf with tiny mss and see how well it performs,. with qos, without qos.
<Grommish> I don't run QoS
<damex> it has to be an automated test
<damex> so let's say in generatl you need to see how many pps device can handle and atleast a general/generic forwarding situation.
<Grommish> But, I've got the 1 slot filled with the patched version, 1 without, and the third is my standard load.. Help me do the tests and I'll run them
<damex> in*
<Grommish> but, given the RAM throughput loss, I really don't care about the rest of it because even if Netperf was fine, the system will be slower by rote
<Grommish> Disc IOps were the same for example to the emmc
<Grommish> RAM showed the marked difference. I'd have to rearrange my network setup again to test throughput, but I've go a speedtest server internal to the ISP i know what I SHOULD and DO get and can test against that
<damex> <we do not care about ram performance if network throughput does not degrade>
<damex> i guess that would be your answer
<damex> you better collect the rest of the details
<Grommish> I get 920/245 down/up to the speedtest server upstream, which is 5 hops, where the first two are the laptop and the edge router
<Grommish> So I can test that
<damex> Grommish: no, wrong. too many factors. it has to be a testing without external factors
Grommish_ has joined #openwrt-devel
<Grommish> cn01plv-spdtst01.zoomtown.com ( 3.149 ms !X 3.134 ms !X 3.169 ms !X
<Grommish> That is over WiFi
<Grommish> I can't bring it down much more than that
<Grommish> Unless I setup another server internally
<Grommish> I supposed I can setup iperf on the network edge
Grommish__ has quit [Ping timeout: 265 seconds]
<Grommish> Meh, but I don't like changing that device if I don't have to
Grommish_ has quit [Client Quit]
<Grommish> Anyway, I'm willing to run the tests, but I need to know what to run.. It's why I approached you about quantifying the issue before :) I'm just in a position now to actually run the tests
<damex> iperf3 -P 64 -p 5201 -R --set-mss 100 -b 2G -t 300 -c ip
<damex> decent starting point
<Grommish> damex: Ok.. We will start there
<damex> so low mss, 2G/s bw and 5min timeout running in 64 threads
<Grommish> I've got a dual core CPU ;p
<Grommish> So that'll be fun
<Grommish> RUnning and logging internal to the LAN
dedeckeh has joined #openwrt-devel
rmilecki has joined #openwrt-devel
_whitelogger has joined #openwrt-devel
<Grommish> damex: I'm heading to bed.. If you think of something else to run, let me know. I've also updated the comment in the closed PR regarding the test results and the fact my edge device also is limited due to running a snapshot build from master on it..
Fishman has joined #openwrt-devel
Fishman has quit [Changing host]
Fishman has joined #openwrt-devel
dedeckeh has quit [Quit: Connection closed]
<damex> Grommish: what is 89761 and 150727 ?
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
Borromini has joined #openwrt-devel
danitool has joined #openwrt-devel
feriman has joined #openwrt-devel
rsalvaterra has quit [Ping timeout: 256 seconds]
rsalvaterra has joined #openwrt-devel
rsalvaterra has quit [Client Quit]
victhor has joined #openwrt-devel
victhor has quit [Remote host closed the connection]
victhor has joined #openwrt-devel
rsalvaterra has joined #openwrt-devel
rsalvaterra1 has joined #openwrt-devel
rsalvaterra has quit [Ping timeout: 264 seconds]
rsalvaterra1 has quit [Client Quit]
rsalvaterra has joined #openwrt-devel
<rsalvaterra> lipnitsk: RM2100 up and running. Nice work! :)
<rsalvaterra> Still 4-bit ECC, but not complaining anymore about low strength… Don't know if it's expected or not.
<rsalvaterra> lipnitsk: We have some problems, though…
<rsalvaterra> lipnitsk: [ 14.983914] mt7603e 0000:02:00.0: Invalid MAC address, using random address ee:ed:2b:0c:5e:0e
<rsalvaterra> lipnitsk: [ 17.422018] mt7615e 0000:01:00.0: Invalid MAC address, using random address a2:ee:37:e2:4d:61
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
urjaman has quit [Read error: Connection reset by peer]
urjaman has joined #openwrt-devel
adrianschmutzler has joined #openwrt-devel
<Borromini> lipnitsk: you got an RM2100 as well?
csrf has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
csrf has joined #openwrt-devel
donald_knooth has joined #openwrt-devel
<donald_knooth> Hello Gentlemen. Simple question about OpenWRT packaging/feeds: How are transitive dependencies handled? (If package C depends on package B, and package B depends on package A, do I need to specify package A in the DEPENDS:= block of the makefile for package C?
DonkeyHotei has joined #openwrt-devel
<olmari> donald_knooth: While I can't really tell you real answer, anything other than immediate dependancy would be high mess
<olmari> C depends on B, B depends on A today, and D today...
<donald_knooth> olmari: I'd imagine so, but... the entire build system is super jank, so don't assume the obvious..
<olmari> I don't think buildroot would stay working even an day if such depency-explanation would be an thing
<donald_knooth> Thanks
<olmari> I do know openwrt buildroot is.. well.. jank is not term I'd use... for developer standpoint it isn't the most basic way... but I think it allows this megalomaniac (program)listing to work and be somewhat maintainable like this... for user side who "just" wanna mostly compile own openwrt the buildroot is super awesome
<olmari> "go select platform and desired programs and compile"
<PaulFertser> donald_knooth: afaict, you only need to select what you really depend on. Everything else goes automatically.
muhaha has joined #openwrt-devel
<donald_knooth> Thanks PaulFertser
rsalvaterra1 has joined #openwrt-devel
goliath has joined #openwrt-devel
rsalvaterra has quit [Ping timeout: 246 seconds]
DonkeyHotei has quit [Ping timeout: 245 seconds]
<olmari> Should my figurative software rely on something small as "nano" (the text editor), I still couldn't keep up and be assumed that I would know on what library version nano needs at what time... and god knows what else the library then depends on.. you see? :)
rsalvaterra1 has quit [Quit: Leaving.]
rsalvaterra has joined #openwrt-devel
<Grommish> adrianschmutzler: ping
opal has quit [Ping timeout: 268 seconds]
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
feriman has quit [Quit: WeeChat 3.0.1]
<Grommish> olmari: If your package requires nano, you'd put DEPENDS:=+nano.. the build system, when seeing that Dep in menuconfig, will see that PACKAGE_NANO requires: Selects: PACKAGE_libncurses [=n] && PACKAGE_libc [=y] && PACKAGE_libpthread [=y] && PACKAGE_librt [=y] and follow the rabbit hole
<olmari> Grommish: exactly
<Grommish> PKG_BUILD_DEPENDS and HOST_BUILD_DEPENDS can be defined for those that need to be in-place prior to compiling vs "just available on the sytem"
<olmari> (I wasn't the claimer for otherwise 😉 )
<Grommish> The only limitation I've found is that the build system (which is based on the kernel build system I believe jow said at one point) is that it can't DESELECT a package conditional on another :(
<Grommish> which is very inconvient at times :D
<olmari> yeah... menuconfig doesn't have permanent storage of what was actually chosen by human and what by depency
<Grommish> *nod* it expects me to know what i'm doing and I'm not comfortable with that
opal has joined #openwrt-devel
<olmari> Well... it would be awesome to have such data recorded and by extension automated
<olmari> I kinda do realise menuconfig isn't package manager, but openwrt case it acts very much of such =)
<Grommish> Yeah. I honestly don't find it too bad except for the one issue mentioned, but I was very confused at the start
Tost has joined #openwrt-devel
<Grommish> and the Wikis tend to be all over the place and I have a tendancy to.. not read fully? :p
Borromini has quit [Ping timeout: 260 seconds]
<olmari> Not first time when I start fresh because I've tried stuff that keeps filling end image... :D
<olmari> ..because of shitton of depencies (human perspective)
<Grommish> hehe
Tost has quit [Ping timeout: 265 seconds]
Guest85397 has quit [Quit: WeeChat 3.0]
voxadam has joined #openwrt-devel
voxadam is now known as Guest43926
danitool has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 260 seconds]
Acinonyx has joined #openwrt-devel
Borromini has joined #openwrt-devel
nucleo has joined #openwrt-devel
nucleo has quit [Client Quit]
black_ant has quit [Ping timeout: 260 seconds]
Borromini has quit [Ping timeout: 265 seconds]
dedeckeh has joined #openwrt-devel
muhaha has quit [Quit: Connection closed]
Night-Shade has joined #openwrt-devel
rsalvaterra1 has joined #openwrt-devel
rsalvaterra has quit [Ping timeout: 245 seconds]
Night-Shade has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dangole has joined #openwrt-devel
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 245 seconds]
valku has joined #openwrt-devel
Tost has joined #openwrt-devel
donald_knooth has quit [Quit: Connection closed]
Red_M has joined #openwrt-devel
Red_M has quit [Changing host]
Red_M has joined #openwrt-devel
Guest79506 has quit [Ping timeout: 276 seconds]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
shibboleth has joined #openwrt-devel
finsternis has joined #openwrt-devel
Borromini has joined #openwrt-devel
<KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_omap.html has been updated. (0% images and 98.2% packages reproducible in our current test framework.)
jlsalvador has quit [Quit: jlsalvador]
pkgadd has quit [*.net *.split]
johnf|znc has quit [*.net *.split]
svanheule has quit [*.net *.split]
pulec has quit [*.net *.split]
xdarklight_ has quit [*.net *.split]
matteosilex has quit [*.net *.split]
Dagger has quit [*.net *.split]
SwedeMike has quit [*.net *.split]
arnd has quit [*.net *.split]
zx2c4 has quit [*.net *.split]
norris has quit [*.net *.split]
MentalPower has quit [*.net *.split]
blocktrron has quit [*.net *.split]
funman has quit [*.net *.split]
johnf has joined #openwrt-devel
xdarklight has joined #openwrt-devel
svanheule_ has joined #openwrt-devel
pkgadd has joined #openwrt-devel
zx2c4 has joined #openwrt-devel
<Borromini> Grommish: you still around?
arnd has joined #openwrt-devel
MentalPower has joined #openwrt-devel
norris has joined #openwrt-devel
funman has joined #openwrt-devel
blocktrron has joined #openwrt-devel
matteosilex has joined #openwrt-devel
pulec has joined #openwrt-devel
Tost has quit [Ping timeout: 246 seconds]
SwedeMike has joined #openwrt-devel
pulec has quit [Max SendQ exceeded]
Tost has joined #openwrt-devel
Dagger has joined #openwrt-devel
pulec has joined #openwrt-devel
nick[m] has quit [Ping timeout: 265 seconds]
pavlix has quit [Ping timeout: 268 seconds]
JuniorJPDJ has quit [Ping timeout: 240 seconds]
lipnitsk has quit [Ping timeout: 246 seconds]
agb[m] has quit [Ping timeout: 246 seconds]
MatMaul has quit [Ping timeout: 246 seconds]
decke[m] has quit [Ping timeout: 268 seconds]
aparcar[m]1 has quit [Ping timeout: 265 seconds]
Jonny[m]1 has quit [Ping timeout: 240 seconds]
fblaese has quit [Ping timeout: 240 seconds]
olmari has quit [Ping timeout: 246 seconds]
Q_ has quit [Ping timeout: 268 seconds]
pgwipeout[m] has quit [Ping timeout: 258 seconds]
shalzz has quit [Ping timeout: 268 seconds]
magnusk has quit [Ping timeout: 268 seconds]
jlsalvador has joined #openwrt-devel
voltagex has quit [Ping timeout: 268 seconds]
nick[m] has joined #openwrt-devel
pavlix has joined #openwrt-devel
JuniorJPDJ has joined #openwrt-devel
rsalvaterra1 has quit [Quit: Leaving.]
rsalvaterra has joined #openwrt-devel
decke[m] has joined #openwrt-devel
aparcar[m]1 has joined #openwrt-devel
agb[m] has joined #openwrt-devel
<rsalvaterra> lipnitsk: Wi-Fi is extremely unstable. Keeps disconnecting all the time.
lipnitsk has joined #openwrt-devel
MatMaul has joined #openwrt-devel
<rsalvaterra> lipnitsk: ping
damex has quit [Quit: damex]
olmari has joined #openwrt-devel
Jonny[m]1 has joined #openwrt-devel
damex has joined #openwrt-devel
fblaese has joined #openwrt-devel
dangole has quit [Ping timeout: 260 seconds]
blb4393 has joined #openwrt-devel
pgwipeout[m] has joined #openwrt-devel
Q_ has joined #openwrt-devel
shalzz has joined #openwrt-devel
magnusk has joined #openwrt-devel
dangole has joined #openwrt-devel
ephemer0l has quit [Ping timeout: 240 seconds]
linzst has joined #openwrt-devel
damex has quit [Quit: damex]
Huntereb has quit [Quit: See ya!]
damex has joined #openwrt-devel
<guidosarducci> dangole: ping
blb4393 has quit [Quit: ChatZilla 0.9.93 [Waterfox 56.3/MOZ_BUILDID]]
damex has quit [Client Quit]
Huntereb has joined #openwrt-devel
damex has joined #openwrt-devel
<lipnitsk> rsalvaterra: pong
<lipnitsk> rsalvaterra: yeah I haven't tested wi-fi at all - don't have a wi-fi ramips device, sorry..
<lipnitsk> rsalvaterra: is it using mt76 driver?
damex has quit [Client Quit]
damex has joined #openwrt-devel
jmv09 has joined #openwrt-devel
<dangole> guidosarducci: pong
<jmv09> #19.07.7 appears to a) stop issuing ipv4 addresses (dhcp) and b) disrupts igmp iptv traffic upon other load. E.g. x86 master is much better.
<guidosarducci> dangole: howdy! Can I ask you to look at two simple updates in bpftools, since you've review that before? A macOS fix already upstreamed: https://github.com/openwrt/openwrt/pull/3959, and a pkgconfig fix: https://github.com/openwrt/openwrt/pull/3956.
damex has quit [Quit: damex]
luke-jr has quit [Quit: ZNC - http://znc.sourceforge.net]
damex has joined #openwrt-devel
voltagex has joined #openwrt-devel
luke-jr has joined #openwrt-devel
muhaha has joined #openwrt-devel
empanisset has joined #openwrt-devel
<rsalvaterra> lipnitsk: Yes, mt76.
<lipnitsk> probably needs some love for 5.10..
<empanisset> Hi I am new in openwrt development. I got a crash in netifd daemon (attempt to access NULL pointer) and I'd like to know where to report the issue
<rsalvaterra> lipnitsk: IIRC, mt76 is using OpenWrt's mac80211 from 5.10, already.
<lipnitsk> anything in dmesg?
<lipnitsk> or cat /proc/interrupts?
<guidosarducci> empanisset: for core issues like that: https://bugs.openwrt.org/ would be best
<jmv09> empanisset: Can you reproduce? In which versions does it occur?
<rsalvaterra> lipnitsk: In dmesg, the only obvious info is what I sent this morning…
<rsalvaterra> lipnitsk: There's also this: [ 3.935333] mt7621-pci 1e140000.pcie: Parsing DT failed
<empanisset> I have a commit number on which that happens (checked out this commit) but not sure apparently it's not a crash that happens frequently
<lipnitsk> that's not a problem, pcie reinitializes fine after that message
<rsalvaterra> lipnitsk: Sure, but there's either a problem in the device tree or the parser, which should be fixed (by someone who knows the system better than us). :P
Huntereb has quit [Ping timeout: 260 seconds]
<empanisset> I  happens when network reload event is processed, and further in the call stack attempt is made by proto layer to access l3_dev.dev pointer which is NULL
<lipnitsk> rsalvaterra: please read that thread - that's the author/maintainer of the PCIe driver
<lipnitsk> rsalvaterra: not saying there is no issue at all, but it's not a high priority one and is on his radar for sure
<rsalvaterra> lipnitsk: Just downgraded to 5.4.103.
<empanisset> guidosarducci thanks I'll try to report there
dangole has quit [Remote host closed the connection]
svanheule_ is now known as svanheule
dangole has joined #openwrt-devel
<rsalvaterra> Yikes. I'm now seeing invalid MAC addresses on 5.4 too…? o_O
<rsalvaterra> Not cool.
<Borromini> rsalvaterra: that 'parsing dt'error is endemic
<Borromini> paraka already said in dengqf6's 5.10 ramips PR that it's basically harmless
<rsalvaterra> Borromini: Yeah, I noticed, it's just more "quiet" on 5.4. But the invalid MAC addresses on the Wi-Fi devices are a new issue.
empanisset has quit [Quit: Connection closed]
<rsalvaterra> If I'm not mistaken, the firmware stores the MAC address for the Ethernet MAC, and the Wi-Fi addresses are calculated from it.
ephemer0l has joined #openwrt-devel
Huntereb has joined #openwrt-devel
damex has quit [Quit: damex]
Huntereb has quit [Ping timeout: 258 seconds]
samantaz has quit [Quit: Bye]
<ynezz> rsalvaterra: FYI just got mail from GKH, that he has backported that usbip gcc-10 fix into https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git 4.9+
<rsalvaterra> ynezz: Great, thanks!
<dangole> guidosarducci: will take a look once i finish reviewing other things
Huntereb has joined #openwrt-devel
<guidosarducci> dangole: thanks, I appreciate that, since not many bpf-interested committers around. Let me know of any questions.
m4t has quit [Quit: m4t]
m4t has joined #openwrt-devel
<rsalvaterra> Ok, I hexdumped a copy of the mtd3 (factory partition)…
<rsalvaterra> Relevant offsets:
<rsalvaterra> 0008000 7615 00a0 d128 bf27 a60d 0000 0000 0000
<rsalvaterra> 0000000 7603 0201 d128 bf27 a50d 7603 14c3 ffff
<rsalvaterra> These look sane enough…
<rsalvaterra> So, the MAC addresses are there.
<Borromini> even prefixed with the radio types :)
<Borromini> so is the ML still having issues? sent in patches. not showing up on the ML or patchwork.
<rsalvaterra> Borromini: Yeah. But for some unfathomable reason, they aren't being read correctly by the driver.
<Borromini> not even with 5.4 anymore it seems, right?
linzst has quit [Quit: Leaving]
<rsalvaterra> Borromini: Righto.
dedeckeh has quit [Quit: Connection closed]
muhaha has quit [Quit: Connection closed]
<lipnitsk> rsalvaterra: so 5.4 also doesn't work right? Means something broke on master before my 5.10 changes went in
<lipnitsk> rsalvaterra: by doesn't work I mean the MAC thing
<rsalvaterra> lipnitsk: Either master or the kernel itself…
<lipnitsk> hmm yeah might have been the big stable bump
<lipnitsk> rsalvaterra: do you want to bisect it?
<lipnitsk> do you know when it last worked?
<dangole> lipnitsk, rsalvaterra: i've tested 5.10 and 5.4 on RBM11G which I got patched to load MT7615 EEPROM from additional MTD partition at the end of the flash. that works on both 5.4 and 5.10
<rsalvaterra> lipnitsk: I have done kernel bisections before… but never in OpenWrt. :/
<lipnitsk> not kernel, just bisect the openwrt SHAs, if it's the kernel bump then we look there
<rsalvaterra> dangole: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ramips/dts/mt7621_xiaomi_router-ac2100.dtsi;h=7e6b3afcdf008dc6506bd09b207ec64770a59bbf;hb=HEAD
<rsalvaterra> This is the relevant device tree.
<dangole> it's weird to match on the driver, i do compatible = "pci14c3,7615" for the PCIe device
<rsalvaterra> lipnitsk: I'll probably just checkout at each kernel bump.
<dangole> rsalvaterra, lipnitsk: ie. this is what I use and works: https://termbin.com/sqby
<dangole> (obviously the EEPROM needs to be written there before, of course...)
<rsalvaterra> dangole: Thanks, I'll give it a try here.
<dangole> rsalvaterra: you have to adapt the compatible string to match the pci vendor/product id, of course
<rsalvaterra> dangole: What do you mean, written there before?
<rsalvaterra> In this case, it's a factory partition, much like ART on ath79.
<dangole> rsalvaterra: in the compatible string, you encode the PCI vendor ID and product ID
<dangole> rsalvaterra: regarding my rbm11g hack (which is a board without any wifi when it comes from the factory), i added mt7615e module without eeprom and load it from flash in that way.
<rsalvaterra> dangole: Why does MikroTik have to be different from everybody else? :)
<dangole> rsalvaterra: it's just their weird bootloader and that's related to their licensing model, i guess
<dangole> replace with stock u-boot and the hardware is straight forward
<dangole> (apart from rbm4xx boards which got NAND wired up in the weirdest way ever)
<dangole> (they make a parallel SLC NAND into an SPI device by adding shifters on the busses)
<rsalvaterra> dangole: Correct me if I'm wrong, but the "mtd-mac-address = <&eeprom 0x1000>;" points exactly to the first byte of the MAC address, right?
<dangole> exactly. if it doesn't load it from there this must have other reasons
<rsalvaterra> So, from this hex dump… 0008000 7615 00a0 d128 bf27 a60d 0000 0000 0000
<dangole> that looks like an MT7615 wifi EEPROM
<rsalvaterra> … it should point to 0x8004.
<dangole> which does contain a mac address as well
<dangole> and in that case you don't even need to set it explicitely
<dangole> i set it there because i got a generic EEPROM file from the module vendor with a fake mac address there and instead of patching the EEPROM for each board (incl. checksum, ...) i only let dt override the mac address additionally
<rsalvaterra> dangole: Thing is, for some reason I'm getting this… [ 16.554338] mt7615e 0000:01:00.0: Invalid MAC address, using random address fe:30:e4:de:f5:46
<dangole> so mt7615e doesn't load that eeprom to begin with. you should also see exceptionally low tx power
<rsalvaterra> dangole: Neither the MT7615 nor the MT7603. [ 14.141100] mt7603e 0000:02:00.0: Invalid MAC address, using random address 92:cb:62:38:8e:42
<lipnitsk> rsalvaterra: I wonder if 21.02 is also broken for you?
<rsalvaterra> Which is reeeealy fishy. I know for a fact this was working until I did the mvebu 5.10 bringup (I was using the RM2100 as my main router).
<rsalvaterra> I'm going to checkout at 5d3a6fd970619dfc55f8259035c3027d7613a2a6 (5.4.98 bump, I know this one was working, for sure).
<Hauke> rsalvaterra: I also have problems with MT7612EN
<rsalvaterra> Hauke: Oh dear… same as me?
<Hauke> I think it is relaetd to the mac80211 patches introduced in december
<Hauke> it works more stable without the rate controll patches
<Hauke> it wokre fine with a build from beginning of december, and I have problems since January
<Hauke> with kernel 5.4
<Hauke> normally it works for 12 hours fine, but gets then worse
<rsalvaterra> Hauke: I see, but my situation is different. I haven't had any issues before, until suddenly the driver stopped reading the EEPROM.
<Borromini> Hauke: what kind of problems?
<rsalvaterra> BRB
<Borromini> i retired my rt-ac57u (mt7612 as well) from active duty but i recall it being very unstable with later master builds
<Hauke> rsalvaterra: ok then this is a different problem
<swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
<hurricos> ynezz: ping
<Borromini> dwmw2: i'm seeing this when i try to send to the list: https://paste.debian.net/plainh/e63cb8e1
<Borromini> did anything change on the list settings? I was able to send e-mail in still on Feb 28th.
jmv09 has quit [Ping timeout: 240 seconds]
<Borromini> on a related note, i haven't gotten any e-mails from the list since March 2nd either
<lipnitsk> Borromini: the list was down for a day or so, but has been functioning since then. I think dwmw2 had to move servers, so maybe something did change, but seems the issue is likely on your side
<Borromini> lipnitsk: at least i should still be getting mail right?
rmilecki has quit [Ping timeout: 265 seconds]
<Borromini> not even that is happening.
<lipnitsk> Borromini: yeah that's strange... FWIW I just sent a patch and it showed up in patchwork
<Borromini> yeah i've seen other e-mails from today as well
<Borromini> on the ML online, so...
<Borromini> i already restarted the vps but i'm not seeing anything different so far
danitool has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
<rsalvaterra> lipnitsk: Can't bisect here, too slow. But this really needs to be fixed.
<rsalvaterra> My router is basically unusable.
<lipnitsk> rsalvaterra: well if it's also broken on 5.4 (did you check 21.02?) then I don't think it was my 5.10 changes
<rsalvaterra> lipnitsk: I haven't checked 21.02, but I'm confident it wasn't caused by your changes.
<lipnitsk> did Dan's statement make sense when he mentioned EEPROM not being read at all? are you seeing super low tx power?
<lipnitsk> what else is in the eeprom? some firmware bits? I really have no idea
<rsalvaterra> lipnitsk: Yes, I'm seeing exactly what dangole described.
<rsalvaterra> lipnitsk: Calibration data and MAC addresses, at least. I don't know what else is there.
<lipnitsk> ah calibration stuff - maybe that's it... what controls eeprom read? still mt76?
<dangole> rsalvaterra: so apparently the dt-match doesn't work. did you try using the pci vendor/product IDs instead of just referencing 'mt76' there?
<rsalvaterra> dangole: Not yet, I was trying to bisect, but gave up, it's nigh-impossible on a Pentium 4.
<lipnitsk> so you found a good sha?
<rsalvaterra> dangole: I'll try matching by PCI ID, as you suggested.
<guidosarducci> dangole: thanks for the review and merge!
<dangole> it's the only difference i can see right now, because mtd-eeprom works well on my rbm11g here
<rsalvaterra> dangole: I'm assuming endianness isn't relevant (the data is little-endian).
<rsalvaterra> At least mt76 seems to take care of that.
<dangole> cpu endian is little endian as well on ramips and mt76 eeprom is always LE
<KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 98.4% packages reproducible in our current test framework.)
ivanich has quit [Remote host closed the connection]
<rsalvaterra> dangole: I'll try this first… https://paste.debian.net/1188361/
<dangole> rsalvaterra: yes, exactly, that's what i meant