aiyion has quit [Remote host closed the connection]
aiyion has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Tapper has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
<hurricos>
blocktrron: any luck retrieving your laptop for a u-boot .config file for rambooting mpc85xx? :^)
<hurricos>
anyone know what the key is in menuconfig to go to a thing once you'
<hurricos>
've searched for it using /?
<hurricos>
found it! You hit the indicated number.
<hurricos>
I guess SYS_TEXT_BASE will be ... whatever the address of ... oh god, I have no idea. I guess it's the location that the Aerohive boots to by default, so 0xEE840000 (where the old Linux partition was)
<hurricos>
Oh god, I don't know if mpc85xx was converted to dm_i2c in time
<hurricos>
.... about, I'm guessing, the insuitability of particular operands with regards to the & instruction
<hurricos>
s/instruction/operator
duke2 has left #openwrt-devel [#openwrt-devel]
<hurricos>
oh, it's because I need to define a thing
<hurricos>
yeah, CONFIG_TPL_TEXT_BASE.
<hurricos>
Hmmm
<hurricos>
I'm still being forced to compile the SPL
<hurricos>
urgh
<hurricos>
I wish I had a way to debug and understand any of this stuff.
<hurricos>
This is like banging my head against a wall until I bleed. Attempt to compile -> find {un,under,over}-defined symbols, check / in menuconfig, grep for them, try to understand which symbols are REALLY {un,under,over}-defined, fix them, repeat
<hurricos>
I have no basis for any of my decisions because I have no known-working state
<hurricos>
I'm at work. It's midnight.
<hurricos>
I'm wasting away my life trying to please maintainers enough to merge stuff by showing good-faith effort to pursue the "real solutions" suggested
<hurricos>
why do I even bother with these boards
<hurricos>
why is everything so god-dang broken
<hurricos>
;(
<neggles>
hurricos: why do you bother? masochism, probably
<neggles>
why is everything broken? capitalism, mostly
<neggles>
and, a couple things - you don't need I2C_SPL, you don't need much of anything enabled in the SPL actually, only the bare minimum neccessary to get the main image booting
<hurricos>
it doesn't even explain the options which were required to compile in 2013
<hurricos>
I have tried and failed (probably because I'm an impatient, unorganized slob) to compile using the right options for then.
<hurricos>
frankly I don't know what I'm compiling.
<hurricos>
I'm expecting about a ~300KB binary which only gives me a, whatever the heck you call the non-Hush shell. Or maybe the default shell is hush.
<hurricos>
not sure, but the point is, giving you a u-boot shell and having enough brains to not mess everything up upon bootm.
<hurricos>
I don't actually know how any of this crap works, I have no idea how MMU init is generalized, what I'm looking for
<hurricos>
all of the abstractions are broken fragments in time
<hurricos>
my usb-c to 3.5mm jack just died. Static electricity while shifting around my jacket / backpack
<hurricos>
I've gone through one per month ever since I bought a phone without a jack
<hurricos>
I'm so done in so many ways with so many things
<hurricos>
blocktrron had booting from RAM working on the msm460, but he's overloaded with finals / school
<hurricos>
dpeel's at her wit's end since Tom died on the 21st of Jan
<hurricos>
things are just falling apart, jfc
<hurricos>
work is driving me insane, promises galore but never any relief, assistance, salary increases or any other opportunities. Our team was guaranteed a new hire for me to train on Oct 19. We still don't have a viable candidate
<ynezz>
mkresin: could you please check https://github.com/openwrt/openwrt/pull/4312 ("[19.07] kirkwood: increase kernel partition of Linksyses") which claims to fix easy back to stock firwmare broken by 9808b9ae of yours
<stintel>
and this is without services running in ujail, and without dnsmasq
<rsalvaterra>
stintel: Uncomfortably linear…!
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
<stintel>
the fact that I haven't the slightest clue where the mem usage is coming from bothers me more
<ynezz>
try perf?
<stintel>
perf what?
<ynezz>
kernel?
<ynezz>
the hot pats are visible, so the memory leaks might be corelated
<ynezz>
s/pats/paths/
<rsalvaterra>
stintel: Does it grow linearly with no traffic at all?
<stintel>
not sure what you mean with perf kernel, kernel is not a perf command
<stintel>
rsalvaterra: it's not routing anything
<ynezz>
stintel: perf top
<ynezz>
for the start
<stintel>
that doesn't show anything memory related?
<hurricos>
wow
<hurricos>
sleep has done wonders for my mood
<ynezz>
stintel: I didn't used it for a long time, but it should show you top hot paths, so if you've some issue reproducible with iperf it might give you some pointers where to start
<stintel>
ynezz: this graphs is 48h, I think it's going to be very hard to spot in perf top
<ynezz>
so for example in working kernel you might be able to see buffer alloc/dealloc, but in borken kernel you might not see deallocs
<ynezz>
stintel: IIRC someone was able to trigger it faster with iperf
<neggles>
hurricos: glad to hear it :P
<neggles>
ynezz: not exactly
<stintel>
ynezz: I tried, didn't work
<neggles>
so far the only thing on my build that consistently bumps it is dnsmasq restarts and dns queries, iperf never did anything
<neggles>
but i need to update to the kernel stintel is on
<stintel>
and dnsmasq is not even in my image :)
<neggles>
i had zero memory leaks despite thrashing the hell out of the thing when i didn't have dnsmasq in my image
<stintel>
it's really weird, also if I add all entries in /proc/meminfo I don't even get to the total memory usage
<neggles>
that is normal
<neggles>
FPA buffers, anonymous pages
<neggles>
octeon bootmem
<stintel>
it shouldn't be normal, it should be reported, how else can you debug issues like this ffs
<neggles>
i suspect that will suffer from the same problem kmemleak suffers from
<neggles>
namely that it can't trace the FPA buffers
<ynezz>
then add manual tracing to those?
<neggles>
not possible.
<ynezz>
it's kernel function?
<neggles>
no, FPA is hardware
<neggles>
an octeon is not a "processor with a bunch of peripherals" SoC
<neggles>
it is "a bunch of peripherals with a processor"
<neggles>
CPU can't communicate with much of anything without hardware accelerators
<neggles>
and the hardware accelerators all have really messy drivers and are opaque as hell
<ynezz>
so kernel knows, that the memory is leaking, but don't know where, that sounds weird to me
<stintel>
I'm gonna vote we drop octeon if that is the case
<neggles>
dropping pre-octeon-III is probably not a bad idea
<neggles>
octeon III should be possible to fix, and honestly i wouldn't be surprised if just changing from march=octeonplus to march=octeon3 solved some things - there are a lot of hackarounds in the drivers to account for the CN6000 series chips and the CN7000 series having major internal differences
<neggles>
but it probably says a lot that even a software image for a commercial product first released in 2021, built on an SDK from 2020, is running kernel 4.14...
<ynezz>
4.14 is still supported kernel, 19.07 uses it
<karlp>
neggles: it's still and LTS on kernel.org...
<karlp>
4.4 even...
<karlp>
it's "stable" don't complain :)
<neggles>
oh i know, but *the company that makes them* doesn't appear to be able to make even kernel 5.4 work in a fashion their customers are happy with
<neggles>
a 5.4 based SDK exists, but nothing in the wild seems to use it, even on octeon TX/TX2
robimarko has joined #openwrt-devel
<neggles>
OTOH, the memory leak is probably one of those things that would be really obvious once you worked it out...
<neggles>
like, a "oh. yep. that would do it. should've seen that coming"
<robimarko>
neggles: Yeah, they have SDK11 but its still to be seen in the wild
<neggles>
robimarko: yeah, I'd have expected to see it on the sophoses, but they're all 4.14/SDK10 despite being a *very* new product line
<ynezz>
neggles: cvmx_fpa_alloc/cvmx_fpa_free you're refering to those?
<neggles>
ynezz: the FPA is essentially what handles memory allocation for all communications between the CPU and the majority of the high-speed peripherals
<ynezz>
yes, I can see that, but I don't see how it can grow without kernel knowing about it
<neggles>
the FPA is handed chunks of memory that then completely fall out of the kernel's view. it stores pointers to them, and those pointers are visible, but when the CPU wants to send data to (say) the NPU, it asks the FPA for a buffer. FPA hands it a pointer, it writes data (or sends a read request), the peripheral does something with that data and (for
<neggles>
writes) hands the buffer straight back to the FPA without any CPU involvement
<mkresin>
ynezz: done. thanks for pinging
<Habbie>
stintel, i haven't gotten around to plugging in my erl, but i see you spotted the leak again
<neggles>
this is probably not entirely accurate and is based on some conversations in patch mailing lists where a cavium dev was asked to justify some code
<f00b4r0>
oh dear. It *is* loading. Only it takes minutes
<hurricos>
bonus points
<hurricos>
ask marvell for the sdk or threaten to kill the target
<dangole>
hurricos: i don't think they would care much. octeon target is mostly a retirement resort for EOL devices...
<f00b4r0>
^
<hurricos>
true enough
<dangole>
hurricos: and that makes it a valuable asset for OpenWrt users with ubnt,erlite or rare firewall appliances from 10 years ago, absolutely worth keeping if we can. but i wouldn't expect any help from the chipvendor, i'd actually be surprised if anyone involved with design or drivers for that chip even still works in the same position...
<dangole>
hurricos: so from their sales perspective the best for them is most likely to **not** support it at all, as then people are forced to by new devices, indirectly generating more sales...
<dangole>
to *buy...
<robimarko>
Dont count on Marvell at all, they have no incentive for these old MIPS Octeons to work
<robimarko>
I am sure that they would preffer to sell you a TX2 device instead
xes_ has quit [Quit: bye..]
xes has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
valku has joined #openwrt-devel
xes_ has joined #openwrt-devel
xes has quit [Ping timeout: 480 seconds]
mattytap has joined #openwrt-devel
robimarko has quit [Quit: Page closed]
sborek has joined #openwrt-devel
sborek has quit []
sborek has joined #openwrt-devel
<sborek>
IDENTIFY
sborek has left #openwrt-devel [#openwrt-devel]
sborek has joined #openwrt-devel
sborek_ has joined #openwrt-devel
sborek has quit []
<arnd>
oddly enough, the CN7xxx (and CNF7xxx) MIPS chips have not officially been discontinued and are still listed on https://www.marvell.com/products/data-processing-units.html, unlike a most of the Arm chips that got canned or sold off in the meantime (Armada XP/370/38x/39x, 37xx, 8xxx, ThunderX, ThunderX2, PXA19xx, Berlin, ...)
minimal has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
reiffert has joined #openwrt-devel
<reiffert>
Hey guys - I'm trying to install strongswan on openwrt 21.02 and it refers to a package kmod-crypto-authenc which requires kernel 5.10 - what are my options?
eduardo010174 has joined #openwrt-devel
eduardo010174_ has joined #openwrt-devel
eduardo010174 has quit []
eduardo010174_ has quit []
eduardo010174 has joined #openwrt-devel
<stintel>
reiffert: pastebin /etc/openwrt_release and /etc/opkg/distfeeds.conf ?
<hurricos>
arnd: thankfully Marvell's old stuff is all golden and all still out there
<hurricos>
88F* all being kwbootable makes my heart glow
<hurricos>
dangole: yikes!
eduardo010174 has quit [Quit: Leaving]
<dangole>
hurricos: yes, still from back in the days when the go-to single-board computer was the SheevaPlug (replacing the nslug)... they did a good job back then and it still shines well beyond the targets they intended for "the open source community" back then...
<stintel>
could this explain why my 2000km away Unifi 6 Lite didn't return after sysupgrade? it was on 5.4 before
<rmilecki>
dangole: stintel: interesting, I soft bricked my R6220 this weekend
<stintel>
either somewhat device specific or very very recently introduced breakage
<rmilecki>
i have to say I'm surprised by amount of such faiilures in non-Broadcom targets
<rmilecki>
i have an experience of more stable code with Broadcom somehow
<PaulFertser>
Someone on #openwrt said today's snapshot made Totolink X5000R hang on "Starting kernel".
<stintel>
I'll try to repro / bisect
<PaulFertser>
Snapshots occassionally were "bricking" boards during ath9k times too. They're just snapshots after all.
<minimal>
I binned my Sheevaplug about 2 years ago. Still have 1 Pogoplug left though (same Kirkwood chipset)
<rsalvaterra>
dangole: What…? o_O
<rsalvaterra>
No issues whatsoever on my Redmi AC2100… :/
<rsalvaterra>
uname -a: Linux rocket.lan 5.10.94 #0 SMP Thu Jan 27 18:52:10 2022 mips GNU/Linux
<stintel>
my Jan 27 image on eap615 is fine too
<stintel>
I'm building master now
<stintel>
one of my eap615 has a ttl header and molested case so I can access said header without opening
<rsalvaterra>
ynezz: Hardware revisions can get quite confusing. I have an Archer C6 v2, which is ath79.
<ynezz>
vendors :P
<rsalvaterra>
And the version is pretty much a footnote. You probably won't see it anywhere in the box, maybe in the barcode, if you're lucky.
<dangole>
rsalvaterra: i guess it's just kernel size or decompression hick-up, i've suggested to switch to LzmaLoader, but that didn't work (but I also never did that for mt7621)
sborek_ has quit [Remote host closed the connection]
<rsalvaterra>
dangole: Yeah, my kernels are rather slim, since I have all modules built-in and interprocedural optimisation does wonders. :)
<rsalvaterra>
However, if it's a kernel size issue in the bootloader, maybe the kernel size isn't limited in the build makefile? I haven't checked, though.
Tapper has quit [Ping timeout: 480 seconds]
<rsalvaterra>
Well, 5.10.26 is out. Bumping.
<stintel>
.26?
<stintel>
get out of your time-machine :P
<rsalvaterra>
*96
<stintel>
bloody mtk u-boot seems to ignore vlan in env
<rsalvaterra>
stintel: Sure, Marty. :P
<stintel>
right, device has a switch, so setting vlan in u-boot is probably not sufficient
<stintel>
grrr
<stintel>
oh well, no repro/bisect then
svlobanov has quit [Remote host closed the connection]
<Slimey>
whats in the archer ax1800 1.26 i picked one off a student that had it connected in their dorm
<Slimey>
maybe they will forget and not come get it back
svlobanov has joined #openwrt-devel
<stintel>
can't reproduce on zr-2662 (WIP), but that uses lzma-loader
goliath has joined #openwrt-devel
svlobanov has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
Borromini has joined #openwrt-devel
<stintel>
ok, can reproduce on eap615
<stintel>
tftpbooting initramfs stops after
<stintel>
Loading Device Tree to 87e68000, end 87e6daa4 ... OK
dedeckeh has quit [Remote host closed the connection]
<Slimey>
nm its bcm
Tapper has joined #openwrt-devel
svlobanov has joined #openwrt-devel
svlobanov has quit [Ping timeout: 480 seconds]
<stintel>
oh ffs killed my bisec
svlobanov has joined #openwrt-devel
<Borromini>
stintel: the MT7621 issues in master?
<stintel>
yes
svlobanov has quit [Ping timeout: 480 seconds]
<Borromini>
:)
svlobanov has joined #openwrt-devel
<reiffert>
is there a way to get the firewall in logging mode? For some reason my pings won't work through openwrt when the firewall is started while everything is on ACCEPT. Strongswan ipsec client is running on openwrt itself and transfer net is bound to the WAN interface. As soon as when I disable the firewall from the start-scripts my pings to the destination network go through
<stintel>
reiffert: you can add option log '1' to a zone
<stintel>
but ipsec is a special case
<stintel>
I can advise you to use xfrm interfaces, makes it much less painful to debug
<reiffert>
option log '1' was added to all zones however no entries found with logread -f
<stintel>
if you do not use vti or xfrm you're going to have to use special rules to join traffic in a zone
<stintel>
I don't have examples at hand anymore because I have been using vti and later xfrm for a long time
<reiffert>
xfrm would get me a tunnel interface from my working ipsec sa's?
<stintel>
yes
<reiffert>
amazing
lucenera has joined #openwrt-devel
<stintel>
it's a bit meh to configure in OpenWrt tbh, but you *really* want it over the stuff without interface
<jow>
in hindsight, vti (or the concept of xfrm interfaces in general) is such a no-brainer, makes one wonder why it took decades to happen (on linux)
<stintel>
bisect is most likely going to point me to f4a79148f8cbb7dfbcddfb0c1128caec45a01596 which does not make sense
<stintel>
maybe that commit leaks KERNEL_LOADADDR somewhere ?
<stintel>
anyway if bisect points to that commit I'm reverting it
<stintel>
actually yes, that *is* the problem
<stintel>
Load Address: 0x82000000
<stintel>
observed in u-boot when kernel doesn't boot
goliath has quit [Quit: SIGSEGV]
<Borromini>
so it's something for *all* mt7621 devices
<Borromini>
?
<stintel>
not all, things using lzma-loader avoid the problem
<Borromini>
k. still bad enough though
<Borromini>
i remember a build recipe for ipq40xx or ipq806x earlier that leaked into other code and bricked almost all of those devices =)
<stintel>
reverted and pushed
* Borromini
bows
* Borromini
is rescuing another bricked OpenWrt device with his new CH341a toy
<PaulFertser>
stintel: awesome, thank you so much for prompt fix
<PaulFertser>
stintel: do you think the generated images should be removed from the servers for now?
<stintel>
maybe, but I don't have root on mirror-02 so I can't do that
<stintel>
and people running master should be able to fix soft-bricks anyway
<Borromini>
hear hear.
<PaulFertser>
KERNEL_LOADADDR is present in DEFAULT_DEVICE_VARS so it's unclear how it can be leaking.
<Borromini>
i feel sorry for the people who bricked their stuff running master but if you don't have serial handy...
<stintel>
yeah, and can't be arsed to debug it further, I'm already going to have to travel to fix my mt7621 device in Belgium
<reiffert>
hm. ipsec up conn was working fine. I was installing the two xfrm related packages - no charon keeps dying. I was uninstalling the two packages, I restarted - charon keeps dying claining it received a critical signal.
<reiffert>
no charon keeps dying = NOW*
<reiffert>
two strange warnings showing - failed to open /dev/net/tun: No such file or directory and plugin 'uci' failed to load: Error relocating /usr/lib/ipsec/plugins/libstrongswan-uci.so: uci_lookup: symbol not found
svlobanov has quit [Ping timeout: 480 seconds]
<jow>
reiffert: the opkg install likely updated dependencies or installed incompatible ones
<Borromini>
stintel: sorry, that sucks.
<stintel>
well, I should have tested it first locally but I only have one U6Lite
<stintel>
although I should have noticed it on the eap615 too
<stintel>
but I did those a few days earlier
<Borromini>
a few commits can make a world of difference...
<stintel>
that'll teach me again to buy stuff without RJ45 console port
<Borromini>
that's how i bricked this TL-WR1043ND v2 too
<Borromini>
flashed a master testing build, turned out the day after some commit had broken lots of ath79 stuff... and serial gave me the middle finge
<Borromini>
* finger
<stintel>
asked my dad to unplug find the DAP-2695 and replace the U6Lite with that
<stintel>
I hope its config is not too old compared to the one on the U6L
<stintel>
other option is I buy a couple of EAP615 and have them shipped there, ask to plug one of those in
<stintel>
but they seem to be unobtanium atm :P
<Slimey>
heh
<Borromini>
:P
<reiffert>
jow: Thank you. That's it.
<stintel>
sent Sungbo a mail about the revert too
<stintel>
derp
<stintel>
I only tested tftpboot
<stintel>
seems the commit before it breaks vbooting from flash
<stintel>
grmbl
<stintel>
wait, I might have messed up
<stintel>
doesn't help that my only mt7621 device with serial console is not in tree yet
svlobanov has joined #openwrt-devel
<stintel>
bisect/revert was correct, just flashed the last image built during bisect, after the revert I forgot to switch to my eap615 branch and so I did not build a new image for that device
svlobanov has quit [Ping timeout: 480 seconds]
<Borromini>
:)
<stintel>
also doesn't help that I'm switching between workstation and xbox all the time :P
goliath has joined #openwrt-devel
<Tapper>
Hi Plans for openwrt-21.02 branch?
<Habbie>
Tapper, what's the question?
<Tapper>
Is ther a plan to branch soon?
<Habbie>
21.02 was branched quite some time ago
<Tapper>
The next branch mate.
<Tapper>
point 2 or what ever we are up to.
<Habbie>
ok mate
<stintel>
read the ML :)
<Tapper>
KK I will have a look now. thanks stintel
<Habbie>
there's also a recent openssl mips advisory
<rsalvaterra>
dangole: You pushed a patch into my tree…? o_O
<rsalvaterra>
How even…?
svlobanov has quit [Ping timeout: 480 seconds]
<dangole>
rsalvaterra: that's what github allows owners of projects you open a PR on to do with the tree your provide for that PR....
<rsalvaterra>
Scary.
<dangole>
rsalvaterra: the commit is still there and github now links it to openwrt repo, though it has never been committed there
<dangole>
rsalvaterra: (see link in the comment)
<rsalvaterra>
Sorry about the blunder, but I totally missed it. :(
* rsalvaterra
still doesn't GitHub very fluently.
<Habbie>
github, unlike gitlab, stores the main repo and all forks in a single 'git network', which, as i understand it, is a single git repo with some careful namespacing
Borromini has quit [Read error: Connection reset by peer]
<rsalvaterra>
dangole: Fetching the linked commit as a patch and applying locally.
svlobanov has joined #openwrt-devel
<rsalvaterra>
Ok, I think it's fixed here. dangole, mind if I add your SoB, since you also contributed to the 5.14 commit?
<dangole>
rsalvaterra: yes, go ahead
<rsalvaterra>
*5.10.94
<stintel>
weird typos mate ;)
Borromini has joined #openwrt-devel
<rsalvaterra>
stintel: Broken flux capacitor. xD
<stintel>
😂
<stintel>
and off all my esp32-c3's, the ones in my AC units have broken OTA
<stintel>
they're soldered to the AC PCB for power supply
<stintel>
plugging in USB to flash will kill something
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
Borromini has quit [Read error: Connection reset by peer]
Borromini has joined #openwrt-devel
Borromini has quit [Quit: leaving]
svlobanov has quit [Remote host closed the connection]
<stintel>
alright my dad unplugged the U6Lite and plugged in the DAP-2695, so my sonoff in Belgium has network again :P
<f00b4r0>
He seems to have misunderstood the cover letter for the driver I wrote (which was merged ages ago), and does not understand the specifics of that platform
<f00b4r0>
the technical solution in #4679 is sound and correct.
<hauke>
f00b4r0: is the MikroTik cAP ac actually affected by this "problem"?
<f00b4r0>
and it has zero side effects for other platforms
<f00b4r0>
hauke: it's bound to be. All these devices share the same platform.
<f00b4r0>
*hardware platform
<rsalvaterra>
hauke: How have I missed the upstreaming of 434-nand-brcmnand-fix-OOB-R-W-with-Hamming-ECC.patch…?
<hauke>
rsalvaterra: it probably still still applied with some offsets
<hauke>
I will have some sleep now
<rsalvaterra>
nn
<f00b4r0>
hauke: as an aside #4679 has been amply tested (as shown in the PR comments)