<wigyori>
stintel: i recall routing was about 7-800mbits or so, can't recall the NAT performance tbh
<stintel>
hmmm so not ideal if you're on a gigabit uplink
<stintel>
wigyori: thanks for letting me know
<f00b4r0>
quickie: due to apk and/or zst changes, my understanding is that we can no longer "blindly" cherry-pick a package master commit into 23.05, is this correct?
<stintel>
the example config suggests you can put a script, e.g. option notify_backup"<switch-backup-state-script>"
<stintel>
while in practice it uses hotplug-call which results in always calling /etc/keepalived.user
<stintel>
no wonder my failover was completely broken
<stintel>
rsalvaterra: since you're playing around with ppc, can you test if package/devel/perf builds for you?
<stintel>
it fails on qoriq (ppc64) in intel-pt-decoder
<stintel>
I will probably fix it by setting NO_AUXTRACE=1 for ppc64
<stintel>
but if it doesn't build on ppc either might fix that as well while at it
<rsalvaterra>
stintel: I'm playing with mpc85xx, which is 32-bit, though. Let me see if it builds here…
<stintel>
that's exactly why I'm asking, I am qoriq, which is ppc64, and I already know it doesn't build there ;)
fakuivan has quit [Remote host closed the connection]
fakuivan has joined #openwrt-devel
goliath has joined #openwrt-devel
<Ansuel>
stintel SDK to the rescue to quickly check ?
<rsalvaterra>
stintel: Hm, can't select it, having some issues with the dependencies (never used perf in OpenWrt), let me see…
<rsalvaterra>
I think it's the kernel perf events…
<rsalvaterra>
Yep, it is. Building an image now.
<stintel>
tempted to remove source-only for qoriq so these things can hopefully be detected automatically / sooner
<stintel>
Ansuel: no time for extended yak shaving right now
<stintel>
rsalvaterra: thanks
<rsalvaterra>
stintel: undefined reference to `__cpu_to_le32'
<rsalvaterra>
Lots of these.
<rsalvaterra>
Build fails.
<stintel>
rsalvaterra: alright
<rsalvaterra>
Also the other way around, undefined reference to `__le32_to_cpu'
<stintel>
rsalvaterra: can you try https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=commitdiff;h=edadcc5f1ab43d80a57710050f5d3c021db20c5d;hp=f10d55df9e0a2622d4b2d08b79b9a8c9c585cfef
<rsalvaterra>
Endianness… :P
<rsalvaterra>
Sure, let me cherry-pick that…
<rsalvaterra>
stintel: That fixes the build for me too.
<stintel>
rsalvaterra: thanks for testing!
<rsalvaterra>
My pleasure. :)
<stintel>
shall I add a Something-by: ?
<rsalvaterra>
Build-tested-by…? :P
<rsalvaterra>
But that isn't a thing, I guess. No need. xD
<stintel>
so maybe just Tested-by: ?
<rsalvaterra>
That wouldn't be true, since I haven't run-tested…
<antonkh>
@robimarko I don't know much about this stuff but I'm curious, isn't it possible to read the register S16 which according to the datasheet indicates the current address mode?
<robimarko>
ntonkh: Thats not the issue, issue is a systematic way for U-Boot to switch back to 3byte adressing when resetting
<robimarko>
As there is no way to do that currently
<hitech95>
nbd, dumb question is the netifd bonding implementation stable? I've seen that there is no documentation in the wiki.
<hitech95>
the "proto-bonding" package has some issues on my user case and I was wondering if is safe to use the built in netifd version.
<hitech95>
I'm working on the luci support in the luci-module-network
<antonkh>
@robimarko the datasheet says there are instructions to switch the mode. So if you can detect the mode, and there are instructions to switch it, if it's not the mode you want, then why doesn't it work?
<robimarko>
antonkh: It does work if you actually send the opcode to switch
<robimarko>
The issue is that U-Boot does not have restart equivelant to Linux
<robimarko>
There is no teardown of drivers
<robimarko>
It just calls do_reset which then depends on the exact driver but it literaly usually resets the CPU
<robimarko>
So you have no place to make the switch back to 3byte, there is no driver removal
<robimarko>
And in the current code it will enter 4byte mode and never exit it
<Ansuel>
robimarko if you have control of uboot... you already know the only way is to do what OEM usually does and mess with tweaking the stuff done in the bootm command
sestowner has quit [Ping timeout: 480 seconds]
<hurricos>
rsalvaterra: I mean, when am I not? What've you found
<hurricos>
mrnuke: i'm bad at c :(((((
<hurricos>
mrnuke: reading it, I'm fine, even inspecting it during operation. But writing? every time I have to do a man 3 calloc I die a little inside
<hurricos>
honestly, my problem really is just thinking about memory management.
<hurricos>
or, ... no ... buffers.
<hurricos>
> P1020EWLAN
<hurricos>
how did you get that rsalvaterra? It doesn't really matter, but ... TL;DR p1020rdb is upstream-supported AFAIK, we just don't have a generic image build for it
<robimarko>
Ansuel: This is with mainline U-Boot, hacking it is rather easy but that doesnt fix it for anybody else
<robimarko>
And I have been upstreaming IPQ4019 to U-Boot, its now fully usable for SPI-NOR and SPI-NAND devices
<robimarko>
No NAND nor eMMC for now
<mrnuke>
hurricos: C is an art for those who like to self-punish
<hurricos>
;^)
<hurricos>
I like going above and below it. I wrote most of a complete H8/538 model SLASPEC up in Ghidra!
<hurricos>
But doing real C, real well? cursed, sucks. I'd be better at it if I were better at the tooling.
<mrnuke>
I think it's perfectly normal ro be confused by C. C lets one take shortcuts that most languages wouldn't allow.
<mrnuke>
So then it's really consufing as to what the "proper way is... and most people end up using the wrong way anyway
<hurricos>
I feel that.
<Ansuel>
well it seems my mt7621 wax201 is now in bootloop and is in a remote location....
<Ansuel>
very nice....
<hurricos>
Ansuel: RIP :(
<Ansuel>
problem is that it's a snapshot image... but looking at the recent changes i can't find one that might cause the bootloop...
<mrnuke>
Ansuel: Any way to powder cycle it remotely?
<Ansuel>
already tried no luck
<mrnuke>
hurricos: I'm getting close on that RTL8238 dialect for realtek-poe. There is this one initialization command that I haven't yet figured out, and it's driving me nutz
<Mangix>
ffontaine's PKG_CPE_ID fixes all look good
<hitech95>
hey dumb question is there a way in openwrt a way to pin an interface name by the mac address like i can do with other distros? I've seen that when the kernel changes can happends that enumeration is different, this makes the configuration broken. (I'm on x86)