<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?
<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
<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>
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
<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>
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 (216.68.5.57) 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
<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]
<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]
<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.
<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
<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
<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
<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