<Grommish>
neggles: Yeah, ER-Lite compability requires the Octeon+.. I pushed for an Octeon3 target, or at least an Octeon2, but wasn't worth the resources it would take
<neggles>
note that the "everyone is using O32" is about five years out of date
<Grommish>
Well, default kernel config doesn't set either, which is why I ask
<neggles>
Octeon2 target is, mostly a waste of time IMO - there are a lot of devices which would benefit from it in theory, but in reality the differences between -march=octeon2 and -march=octeonplus (i think those are the args?) is not really significant
<neggles>
Octeon3 target is well worth doing, there's a lot of cheap hacks that can be thrown away if you drop oct1/2 support
<Grommish>
Octeon2 because there is/was a Target for it, I'd rather Octeon3, but we were talking most-common
<Grommish>
and it still came down to the lack of viable resources to put towards a target that isn't significant in any way hehe
<neggles>
there are a _lot_ of devices out there with the dual/quad/oct/sextuple octeon3
<Grommish>
Maybe, but not _here_
<neggles>
about a dozen sonicwalls, for one
<neggles>
I've been sort of working on getting a few more
<neggles>
I have one octeon3 device here, 16-core, USG-XG-8 aka EdgeRouter Infinity
<Grommish>
I brought the first Octeon3 target on, so I fought this fight, but only when it was a single device with another one in the pipeline.. If you an help justify it with devices, that's a different story. However, the kernel memleak is still an issue past 5.4, so it maybe a moot point anyway
<neggles>
fwiw I do not experience that memleak on an octeon2 device (CN6640-SNIC10E)
<neggles>
on 5.10.35
<Grommish>
You set it to Octeon2?
<neggles>
let me check, it's been a while
<Grommish>
I've been busy in rust-lang lang, so I've not dealt with any of the Octeon stuff in a bit. I blew up my build system and spent 9 hours restoring the 160Gb tar file :D So I figure maybe I can look at it again
<Grommish>
err land*
<neggles>
I hit a wall with the octeon-nand driver
<neggles>
there's one that looks relatively new-ish and usable, but it is actually made of lies because it only works with Octeon 8000 and up - aka OcteonTX, aka Not MIPS
<Grommish>
Yah.. Liquid is.. aarch64?
<neggles>
Octeon 8xxx and up are aarch64 yes
<stintel>
I think we should abandon octeon entirely. the ethernet driver, despite being dropped than re-added from upstream Linux, is a dead end. look at the memleak that has gone unnoticed/unfixed
<neggles>
ThunderX ARM cores
<stintel>
ditch the hardware and get on with life
<Grommish>
stintel: It's my primary device. I'd hate to ewaste them
<stintel>
the ethernet driver is crap anyway, I remember the ERL used to have occasional link down, wreaking havoc in my HA setup
<Grommish>
Maybe we can ditch Octeon+ if thats the basis for the memleak
<stintel>
very unlikely I'd say
<neggles>
i ain't about to throw out a 16-core 1.8GHz / 8xSFP+ direct-to-CPU / 16GB RAM router
<Grommish>
I'll build out a -march octeon2/3 and test
<Grommish>
stintel: Well, neggles is reporting no issues, even though the rest of us are :D So, something is different.. I stopped setting -march/-mtune overrides a while ago when i started testing because I needed base results
<neggles>
it might just be that i didn't pass enough packets through tbh
<Grommish>
So my builds, with the memleak, is set to octeon+ *shrug* I don't mind testing
<neggles>
i left it running for 8 days with the NIC up and being pinged
<neggles>
and no leak
<stintel>
try generating multicast traffic
<Grommish>
The maintainer says it isn't the driver
<Grommish>
and gives a reason for it we can't test for
<neggles>
oh there's plenty of multicast traffic on the VLAN it's on
<Grommish>
Testing a false negative is.. Not something I want to do
<neggles>
hmm, he's not wrong
<neggles>
the FPA does mask things somewhat
<stintel>
anyway I tried reproducing on my snic as well, I see increase, but then when I was messing with iperf I also rmmod all modules and then loaded them again and the leak seemed to have vanished
<Grommish>
neggles: Right, but we can't test it without unloading teh drivers because the drivers spam kmemleak :D
<neggles>
there really ought to be a way to tell kmemleak about the fpa buffers
<neggles>
alright where's my boot script
<Grommish>
neggles: Probably, but I had to research just to find kmemleak, it's beyond what I can effecitvely do without just blind guesswork
<neggles>
so I threw a gigabit of iperf traffic through it for a minute or so and total used bytes went up from 29172 to 30248
<Grommish>
it never frees
<Grommish>
I was goign to test to see if it'll free when I unload the ethernet driver or not
<neggles>
welll thing about that
<neggles>
just hit with a couple gigabit for another 30s
<neggles>
now i am down to 30004 used
snh has quit [Ping timeout: 480 seconds]
<Grommish>
Hmm.. Well.. Maybe it was fixed upstream.. I've not testing in a month or more
<neggles>
Linux snic10e 5.10.35 #0 SMP Wed Nov 17 10:38:33 2021 mips64 GNU/Linux
<Grommish>
Not 5.10/5.15 anyway
<neggles>
i built this a whiiiiile ago :P
<Grommish>
Then figure out how you fixed it ;p
<neggles>
it's a very gently modified version of stintel's tree
<neggles>
my goal was to make the PCI console work, and i *did* get that to work
<neggles>
oh, i *sort of* got it to work, it works fine as long as it doesn't try to read from stdin...
<neggles>
but it looks like i didn't make any changes to anything outside of octeon-pci-console
<neggles>
Grommish: i would like to retract my earlier statement, we're using -mabi=64 which == N64 ABI so probably *should* be muslabi64
<Grommish>
Well, boo
<neggles>
who really knows with friggin' octeons, though... FWIW the official SDK 5.1 `gcc -dumpmachine` returns mips64-octeon-linux-gnu
<neggles>
but it's also gcc 4.7
<stintel>
neggles: about that tree .. I'm about to nuke it from gitlab. trying codeberg
<neggles>
this is fine, it's in my own gitlab and github as well :)
ecloud has quit [Ping timeout: 480 seconds]
<neggles>
it would be quite nice to get openWRT running on the USG-XG-8, but really I think the best I can realistically accomplish is what I already have (turning it back into an EdgeRouter, but keeping the LCD module functional)
<neggles>
partly because the LCD is controlled by an STM32F7 I don't have the source code for, and is largely autonomous / probes the vyatta JSON API to pull port stats... sigh...
<neggles>
thing pulls 75W at idle, too.
<stintel>
OpenWrt*
Borromini has joined #openwrt-devel
ecloud has joined #openwrt-devel
<neggles>
stintel: touche
<neggles>
i can push 700mbit of TCP through this sophos AP (to a 2x2 client, on 80mhz) even without nss
<neggles>
not bad.
<PaulFertser>
stintel: hey :) what is the current recommended way to try 2.5GBASE-T on U6LR?
ldir has joined #openwrt-devel
<stintel>
PaulFertser: plug it into a NBaseT 802.3at/bt switch ?
<stintel>
and run a recent master image
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
<PaulFertser>
stintel: cool, thank you! I assumed it's still in some wip branch.
<stintel>
PaulFertser: dangole pushed it a few weeks ago
<aiyion>
I'd like to see that or an updated variant in openwrt. I've used it in gluon for like two months now and would like to know how I can help make it progess faster.
<aiyion>
I've gotta go for now; can somebody tell me if he's active in irc? His last message in here appears to be from 2021-12-27.
<aiyion>
Otherwise I'd go on and continue the question in the mailthread this evening.
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
grid has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
nlowe has joined #openwrt-devel
nlowe has quit []
pmelange has joined #openwrt-devel
ldir has joined #openwrt-devel
ldir has quit []
guidosarducci_ has quit [Remote host closed the connection]
guidosarducci has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
oftc has joined #openwrt-devel
oftc is now known as Guest293
Guest293 is now known as xdarklight
ldir has joined #openwrt-devel
nlowe has joined #openwrt-devel
ldir has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ldir has joined #openwrt-devel
ldir has quit []
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Tapper has joined #openwrt-devel
nlowe has joined #openwrt-devel
ldir has joined #openwrt-devel
ldir has quit []
ldir has joined #openwrt-devel
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rua has quit [Ping timeout: 480 seconds]
ldir has quit []
rua has joined #openwrt-devel
nlowe has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
nlowe has quit []
rua has joined #openwrt-devel
ldir has joined #openwrt-devel
ldir has quit []
<openwrter>
Hi Slimey: I left it compiling last night. It's done now. Where is the file I have to tftp to the router? Also, yes, if you want to send me your compiled version I can test it
<openwrter>
Sorry, should've RTFM
f00b4r0 has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
<Slimey>
huh
<Slimey>
in your OpenWrt folder it will be in /bin/targets/sometarget/generic/
BlueBlond has joined #openwrt-devel
ldir has joined #openwrt-devel
<hurricos>
stintel: RE: Gitlab: I wanted to test out code-review and pull-request stuff on Codeberg
<hurricos>
Github is actually quite nice for code review, particularly in light of our workflow ('force-push over what you have so we know what we're reviewing')
<f00b4r0>
well it looks like this is one of these times where I wished jffs2 had snapshots. Typed "reboot" after making some - seemingly working at the time - changes and the remote router I was logged onto is now unreachable. FML.
ldir has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Borromini>
Slimey: what do you use for code management now?
<Borromini>
(just curious)
arnd_ has joined #openwrt-devel
<hurricos>
stintel: I reached out to Gitlab sales for you ;)
<BlueBlond>
anyone got any experiecne with ramfs.gpio archives? i have a rams.gpio that i can extract, but i cant rebuild it to get the exact same file back
<BlueBlond>
i'm using gen_initramfs_list.sh and gen_init_cpio, but for some reason my firmware isn't booting
<Slimey>
Borromini nothing
<Borromini>
ok :)
ldir has joined #openwrt-devel
felix has joined #openwrt-devel
chder has joined #openwrt-devel
goliath has joined #openwrt-devel
ldir has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ldir has joined #openwrt-devel
<hurricos>
Hey @slimey: pick a day that's not today and I can go through the whole GH PR process with you for your board
<Slimey>
ok
danitool has joined #openwrt-devel
<hurricos>
I just ordered a BSAP-1925 for $21
<hurricos>
after shipping and tax
<hurricos>
:^)
<slh>
there's always the alternative to mail a patch series to the mailing list
<hurricos>
(it's a good alternative)
<hurricos>
but you need to already know how to plaintext email and stuff
<hurricos>
:'(
<Borromini>
what's the selling point for that model hurricos ?
<Borromini>
i see it's 802.11n...
<hurricos>
no clue. slimey has one
<Borromini>
oh =)
ldir has quit []
<Borromini>
stintel: any chances you'll be formalising the EAP615-Wall support? :)
<Borromini>
i have a few on the way ^_^
<Borromini>
nbd: if i can help you by mailing you an EAP235-Wall (MT7613) for mt76 debugging/development, I'd be happy to.
<stintel>
Borromini: didn't get to it this weekend, maybe better luck the next one
<Borromini>
=)
Tapper has joined #openwrt-devel
<Borromini>
going to give Birger's Realtek PR a shot on my XGS1250-12
<tmn505>
dangole: on sunxi and omap rootfs-part still won't be used, since Makefile for the image still references CONFIG_<target>_SD_BOOT_PARTSIZE
ldir has joined #openwrt-devel
cmonroe has joined #openwrt-devel
<BlueBlond>
does the order of files in a gpio archive make any difference? it sure seems so, but why?
<BlueBlond>
i extract the filesystem, then repack it, both gpio archives are the exact same size, but the order of the files is different, and the bloody thing wont boot
ldir has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dangole>
tmn095: the CONFIG_<target>_SD_BOOT_PARTSIZE is another thing (which could be cleaned up next). it's the size of the FAT partition where U-Boot loads the kernel image from
<tmn505>
ahhh indeed, rootfs-part != boot-part
<Slimey>
Borromini its a wave 1 unit
<Slimey>
3x3 ac/abgn
GNUmoon has quit [Ping timeout: 480 seconds]
<Slimey>
a clone of extreme-networks_ws-ap3825i
<Slimey>
but adtran did not drill out the hole for the reset button for whatever reason
<Borromini>
oh weird however I google it it says 802.11abgn o_O
Borromini has left #openwrt-devel [#openwrt-devel]
goliath has quit [Quit: SIGSEGV]
GNUmoon has joined #openwrt-devel
_0x4a6f has joined #openwrt-devel
Lechu has joined #openwrt-devel
shibboleth has quit [Quit: shibboleth]
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
slingamn has joined #openwrt-devel
Lechu has quit [Remote host closed the connection]
<openwrter>
So far I've been succesfull in flashing TPLink DecoM5, I have issues with the 802.11s mesh and encryption. Why can't I activate the * in make menuconfig for wpad-ssl (or something) it only allows M....
Lechu has joined #openwrt-devel
ldir has joined #openwrt-devel
ldir_ has joined #openwrt-devel
ldir has quit [Remote host closed the connection]
<PaulFertser>
openwrter: check Help there, it lists dependencies and probably you have conflicts there.
<PaulFertser>
openwrter: you can include only a single wpad variant in the image.
<openwrter>
whichever option I use, it won't let me use encryption
<openwrter>
do i ahve to use wpasupplicant and/or wpad? Or one is host and the other one client?
<dangole>
openwrter: 'wpad' combines hostapd and wpa_supplicant in a single binary. either -openssl or -wolfssl variant supports SAE on 802.11s mesh networks. you need to deselect all other hostapd/wpa_supplicant/wpad variants to be able to select it as <*>