<hurricos>
so it wasn't the re-merge that screwed it up, nor anything more recent!
<hurricos>
err.
<hurricos>
... like, all the little cleanup that the community did after the 5.7 re-merge
csharper2005 has joined #openwrt-devel
<stintel>
git bisect good v5.8
csharper2005 has quit [Read error: Connection reset by peer]
<stintel>
running out of beer :/
Ansuel has joined #openwrt-devel
<Ansuel>
popcorn reading this LOL
<stintel>
bring me some ;)
<Ansuel>
that would distract you from bisecting :(
<Ansuel>
(sad that this is for 5.4-5.10... i had the same problem at times with a qcom error for gpio button and i just porsted every damn kernel version to openwrt (did the same for 5.10 to 5.15)
<stintel>
git bisect bad v5.9
<Ansuel>
so problem from 5.8 to 5.9 ?
<slh>
Ansuel: guess you've read Robert's remarks in the backlog already, but the RAX120 *v2* should be an ordinary ipq8074a SOC and probably (assuming there are no funny games with secure boot and similar, which I don't know) relatively straight forward to for porting OpenWrt, apart from its price. the v1 (respectively RAX120 without a listed hardware revision) would be the problematic ipq8074
<Ansuel>
yep i read that but i assume most of the people have v1 as it was entusiast segment of netgear
<Ansuel>
afaik netgear path with secureboot stuff is just
<Ansuel>
fusing secure boot but keeping access to uboot
<slh>
depends on when they bought it, availability was scarce in the beginning
<Ansuel>
so to install serial access is required and we just have to change the boot command
<Ansuel>
so change default boot command and then fw recovery with tftp
<slh>
and they started out only lending them out for a monthly subscription fee (which allowed upgrading to newer routers later)
<Ansuel>
wait what? subscription for router upgrade?????
<Ansuel>
wtf
<slh>
don't ask me... ealry adopters/ gamers...
<Ansuel>
it's the netgear armor shit?
<stintel>
if that's what it takes to make manufacturers offer updates ... :)
<stintel>
better than not having any
<slh>
nah, that would come as an additional subscription
<Ansuel>
Protect Your Family and Your Home Network from Cybersecurity Threats
<Ansuel>
what a joke...
<Ansuel>
sure lets pay a subscription to voluntary get backdoors on ouy system yay
<slh>
they had (have?) a hardware subscription for always-the-latest-top-end-router
<Ansuel>
oh ok... still strange stuff it's not like we have a new router tech every year...
<slh>
it probably helped to 'guide' demand (I guess there weren't that many devices available early on) and to hide the costs (prices were really high at first, obviously any subscription will turn out more expensive over time, but... gamers...)
<Ansuel>
anyway some spoiler.. i have this crazy idea for ipq807x... using the nss firmware ONLY for wifi offload... in theory we should be able to keep only patches to mac80211 and to nss-drv without adding additional patch to the kernel (aka no ecm shit)
<Ansuel>
will start working on it after 4th april and also start sorting out all the mess for nss-drv
<Ansuel>
but i still have to check if it's doable... in theory wifi offload should totally be separate from the ecm crap that requires tons of special patch by qca
<slh>
I'm pretty surprised how well the ax3600/ ipq8071a has been working lately
<Ansuel>
all massive robi work
<Ansuel>
especially the pci ath11k stuff...
<Ansuel>
still it's a real disaster that ax9000 doesn't work
<slh>
I just hope the ipq40xx/ kernel v5.15 PR gets merged 'soon', in order to rebase ipq807x on top (without having to go through it multiple times)
<Ansuel>
(also wifi offload will fix the ath11k memory leak as all the ring will be handled by nss core)
<slh>
RAM usage has been rather steady for me
<slh>
high, yes, also increasing slowly, but very slowly
<znullptr[m]>
did they figure out the authoring with those patches?
<Ansuel>
solution = redo the patch from scratch... IMHO we won't find a solution about that
<Ansuel>
also they are not that well made so they should be refreshed/reworked anyway
<znullptr[m]>
I couldn't even get them to build, but it would be nice to have that working in 5.15
<Ansuel>
slh problem is that it's really easy to make the system crash you can totally have something in the background that require the ram and the wifi keeps growing with all your wifi device idle
<slh>
Ansuel: yeah, understood - but at least for me (rather idle usage over the last few weeks, in parallel to my normal setup) it has held up well so far
csharper2005 has joined #openwrt-devel
<Ansuel>
znullptr[m] not checked them... honestly scared... the ipq806x nss patch were in such a bad state (i was one of the creator so i was also part of the problem) so they are probably tons of changes in multiple patches with not criteria and just a kernel bump makes them not apply anymore
<Ansuel>
slh i notice the graph and it seems the situation is getting better. but still i see wifi offload something needed considering the bandwidth of ax
<znullptr[m]>
They are mostly small changes, like some cache * that looks like it wasn't needed and kernel dropped it, yet the code depended on it
<Ansuel>
already found a solution about it
<Ansuel>
we can totally drop that
<Ansuel>
just qsdk not using the correct way to handle DMA stuff
<znullptr[m]>
yes it wasn't needed for the arch, i had just commented them ... but build failed later in something i wasn't familiar with and didn't have time to dive down the rabbit hole
<Ansuel>
my idea is to find every way possible to make nss-drv compilable and that doesn't require kernel patch... rework that driver to make it modular (and drop everything we don't need) and patch mac80211 and ath11k code for wifi offload
<Ansuel>
that way we should be able to use at least part of the nss cores
<znullptr[m]>
yeah that's the best option with that much of someone elses mess to deal with, will fix issue of build being frail and the rest isn't even being used
csharper2005 has quit [Read error: Connection reset by peer]
Ansuel_ has joined #openwrt-devel
<mangix>
Ansuel: ping
<Ansuel_>
?
<mangix>
you asked about clang earlier
<Ansuel_>
yep any news?
<mangix>
what were you asking about specifically?
<Ansuel_>
would be interestin using clang instead of gcc
<mangix>
for the toolchain or?
<mangix>
host packages work by editing rules.mk
<Ansuel_>
well introducing support for that would be a first step but i was talking for the build process
<Ansuel_>
so clang for the kernel and firmware package
<mangix>
so toolchain. I've not done any work on that.
Ansuel has quit [Ping timeout: 480 seconds]
<Ansuel_>
read somewhere that is not trivial and clang lacks support for some target
<mangix>
most host packages compile fine with clang. I've slipped a bunch of fixes in the tree
<mangix>
clang toolchain would be...interesting.
<Ansuel_>
yep totally
<mangix>
It's probably the way forward honestly.
<Ansuel_>
but afaik nobody ever tried / did actual test
<Ansuel_>
clang it's good for some static analyzing tool
<mangix>
clang has -Oz (extra small) as well as a smaller libc++ than gcc
<Ansuel_>
their tools are superior than gcc
<Ansuel_>
imho would be an interesting thing something like adding a draft pr on github and check if the community wants to help with the efforts
<mangix>
nbd added something similar for bpffilter.
<mangix>
an LLVM host build that takes forever to compile
<slh>
targets other than x86_64/ arm (mips...) probably don't see much attention from clang
<mangix>
not correct.
<mangix>
the GPU people use LLVM a lot
<slh>
even better, not to claim that mips would see much attention from anyone ;)
<Ansuel_>
yep problem is that this is a classic example of a workaround that became a permanent solution
<mangix>
ehhhh I could argue the problem is std::pair
<mangix>
if one of the arguments is not const, it's not trivially copyable.
<Ansuel_>
imho it's a strange bug from the compiler
<mangix>
which probably confuses the compiler
<Ansuel_>
i mean it's something that the compiler should fix. probably the assert make the compiler understand the thing in a better way but it a flawed logic
csharper2005 has quit [Read error: Connection reset by peer]
<neggles>
hurricos: yes I can
<Ansuel_>
well time to go bed bye
Ansuel_ has quit [Quit: Probably my PC crashed or time to sleep.]
<neggles>
and yes it’s initramfs
<hurricos>
I'm sorry neggles, I have no brain. It literally, says in your system.map that it was an initramfs
<stintel>
:P
<neggles>
except I’m looking at the wrong system.map after all
<neggles>
I loaded a firmware from January because I forgot about my stupid symlink
<neggles>
but also the kernel config is unchanged from that build
<neggles>
i just don’t have its debug info so let me go ahead and reproduce the dumps
<hurricos>
omg
<hurricos>
Well, not really "omg", just silly that it was the wrong system.map. Stintel is almost done bisecting so
<hurricos>
it's some deeply cursed memory management thing
<stintel>
Bisecting: 4 revisions left to test after this (roughly 2 steps)
<stintel>
I think I will go to bed now :D
<hurricos>
wait, wait! give us the range
<hurricos>
we'll just revert the whole thing and test with that :D
<hurricos>
oh no, we lost him.
<hurricos>
Oh well, pick this up tomorrow lol
<stintel>
it's in mm or asm-generic
<stintel>
so it's probably "nobody uses mips64" and nothing octeon specific at all
csharper2005 has joined #openwrt-devel
csharper2005 has quit [Read error: Connection reset by peer]
<hurricos>
I just realized that I will survive with just the 8 cores I have
<hurricos>
it already dissapates too much heat to be worth using lol
csharper2005 has joined #openwrt-devel
<neggles>
hurricos: if you want something with 16, EdgeRouter Infinity / UniFi Security Gateway XG-8
<neggles>
CN7360, 16 cores, pulls 70W at idle
<stintel>
lol
<neggles>
8x10G direct to CPU though so that's neat, and it's SPI-chained-to-eMMC boot
<stintel>
but 70W idle :/
<stintel>
and I'd have to use 2 ...
<stintel>
my UPS runtime will suffer
<neggles>
what did you expect
<neggles>
they ain't power efficient :P
<stintel>
that's a eufemism
<stintel>
s/f/ph/
<stintel>
English is hard ;)
<neggles>
as someone whose grasp of other languages is superficial at best
<neggles>
yes, yes it is, it sucks
<neggles>
I would kind of like to get the host-to-device pretend-o-ethernet stuff working on snic10e, but getting the NAND controller working is necessary first, and it seems like that never even worked in the SDK
<neggles>
and the pcie card CCR2004 makes the snic10e a lot less interesting to me (though admittedly it's 10% of the cost)
<neggles>
here's a cursed thought: would it be possible to put rootfs on an SPI NAND connected via a gpio-spi interface?
<hurricos>
you can probably fit everything in just the 8MB NOR
<neggles>
you 100% cannot
<hurricos>
U-boot has been recently ported back, are you sure it won't fit in lzma?
<hurricos>
... sorry, I meant to say that basic bootloader functionality is becoming available for Octeon II and III in mainline U-boot
<neggles>
yup. I have only barely managed to shrink a kernel+initramfs down to <6MiB with lzma in the "compress this every way you possibly can until you find the smallest option"
<neggles>
the sdk uboot has lzmadec btw
<hurricos>
nice
<neggles>
i do have an image in the NOR on this that it'll boot off
<hurricos>
the other obvious option is, of course
<hurricos>
driver :^)
<hurricos>
you're connected to a PCIe host. Boot like liquidio expects to boot.
<Grommish_>
Wait.. What now? I just got up :D
<hurricos>
Grommish_ The memleak is fixed
<neggles>
Grommish_: stintel found the bad patch
<neggles>
and 2 weeks ago someone sent a fix to the ML
<Grommish>
I'm building a 5.15 build with that patch to test
<stintel>
hmm, 6:12, time for bed
rua has quit [Quit: Leaving.]
<Grommish>
stintel: Enjoy the rest of your weekend!
rua has joined #openwrt-devel
<stintel>
thanks
<Grommish>
stintel: and thank you for all the help throughout all of this saga
<stintel>
I should have listened to you folks, restarting dnsmasq was a good reproducer after all
<stintel>
hurricos: and no that didn't ruin my night, finding the commit that broke things is one thing, fixing it another ... I would have just reverted the bad commit entirely, the fix in linux.git is probably better
rua has quit [Quit: Leaving.]
<hurricos>
I was just kidding. :^)
<hurricos>
stintel: go to bed now!
<stintel>
already there
<hurricos>
night :)
rua has joined #openwrt-devel
<stintel>
now I also have a reason to play with the snic's again :P
<neggles>
:P
<stintel>
that k3s cluster is never going to be revived :P
<mangix>
stintel: do you use xtables-addons?
<stintel>
mangix: I migrated to firewall4/nft months ago
csharper2005 has quit [Read error: Connection reset by peer]
hexagonwin has joined #openwrt-devel
hexagonwin has quit [Remote host closed the connection]
<hurricos>
neggles: real way to deal with that would be a memory exclusion in the DTS imo
<neggles>
except we dunno how big the kernel is
<hurricos>
oh shit
<neggles>
it's placed relative to the end of the kernel image
<hurricos>
fair OK
<hurricos>
right
<hurricos>
lol
<hurricos>
I mean bootloader really should be parsing that
<hurricos>
this commit is a hack around the bootloader not knowing how to set up the rest of the device tree
<neggles>
except it does
<hurricos>
because we all know octeon II/III still doesn't
<neggles>
u-boot does plenty of other stuff based off the device tree
Misanthropos has quit [Ping timeout: 480 seconds]
<hurricos>
right, but obviously doesn't send memory exclusions
<hurricos>
for "right after the kernel"
<hurricos>
as it should do.
<neggles>
not for bootmem no
<hurricos>
The same thing needs to be done for the fdt on powerpc
<neggles>
problem is you can't move it
<hurricos>
My undersatnding is that there's a struct that Linux needs to be passed here
<neggles>
oct-remote-console etc. all expects it to be in the same spot
<hurricos>
it needs to not allocate on that space
<hurricos>
I can't see any issue with communicating that to Linux through the bootloader
<neggles>
ah it does get passed the struct actually
<hurricos>
my commentary is that u-boot not being mainline is the real issue
<hurricos>
not Linux doing something wrong
<hurricos>
notice the SoB line
<hurricos>
nokia.
<hurricos>
Nokia is a notorious cavium octeon user :^)
<neggles>
btw mainline octeon3 support in u-boot is still missing major chunks of initialization code and does not actually work-work at last check
<hurricos>
I'm just complaining because I can fwiw
<hurricos>
yeah, I'm aware
<neggles>
yeah fair
<hurricos>
Aaron Williamson will never finish it
<hurricos>
lol
<neggles>
at least they're trying
<hurricos>
hahahahahaha
<hurricos>
I guess :D
<neggles>
something beats nothing, and stops the code getting dropped entirely :P
<hurricos>
true.
<hurricos>
OK, time to submit my BSAP2030 PR :D
<neggles>
I still reckon we should split octeon into octeonplus and octeoniii
<hurricos>
oh Christ, it's 3AM.
<neggles>
go to sleep? :P
<Grommish>
neggles: It'll never be approved due to resource limitations
<neggles>
then we should drop pre-cn6000 support
<neggles>
it is time for the erlite-3 to die goddamnit
<Grommish>
neggles: Well, last time I checked, the ER-Lite was out-used than the other devices combined
* neggles
grumbles
<slh>
the biggest question would be if splitting (or bumping) really makes a tangible performance difference for typical networking tasks (and not just floating point stuff no one sane is going to use on this hardware anyways)
<Grommish>
neggles: I initially looked at Octeon3 target branch when I started, and was told it wasn't worth the duplication of already limited resources
<neggles>
it does!
<neggles>
even just a subtarget for octeon3 with a different kernel config would cover it
<neggles>
the problem isn't supporting octeon/octeonplus per se, but supporting all 4 generations with one kernel - that's part of the reason why the kernel images are so yuge
<Grommish>
I've got no informed opinion in that fight, at the time I brought it up, it wasn't worth it.. Since there, a few other targets have been added, so it might be bringing it back up, just don't expect a positive outcome is all I can say
<Grommish>
I can easily justify a split target locally, but I don't have to try to find the buildbox resources
<neggles>
i guess i'm going to have to quantify the performance/size improvements
<Grommish>
The Itus box has 3 images associated with it, one for each of the front-panel switch positions, but OpenWrt only supports the one for the reasons outlined above
csharper2005 has joined #openwrt-devel
<neggles>
Grommish: true but you could still use all 3 by just dumping the same initramfs image into all the filenames and using the different cmdline arguments to pick from 3 different rootfs with different configs :P
<neggles>
that's all the itus really did anyway
<Grommish>
neggles: I did that and was told no because it builds for the image
<Grommish>
The only difference was the ITUS_CMDLINE pointing to the different rootfs
<neggles>
oh yeah that'd be a local/imagebuilder thing
<neggles>
and for that you want to switch to using the devicetree to supply the overridden commandline
<neggles>
so one image, three DTBs
<Grommish>
*sobs* More DTB talk ;p
<neggles>
you have a device tree!! u-boot loads one and passes it in!
<neggles>
you're just not building a custom one
<Grommish>
Well, yeah, but the difference was I didn't have to mess with it :) And.. Itus did something far more stupid for dealing with things.. They used an init.d script and a sleep call until the mmcblk came up
<Grommish>
So they literally had 3 idential images and just waited to see which was present at boot
<neggles>
that's entirely reasonable, the point of initrd/initramfs is to do whatever's necessary to get rootfs mounted
<neggles>
if that means checking a switch position to decide which partition to mount that's fine
<hurricos>
holy f
<hurricos>
the BSAP2030 can push line-rate
<hurricos>
with iperf3
<hurricos>
that's better I think than P1020s can do
<hurricos>
must just be the higher clock?
<neggles>
single-thread?
<hurricos>
single-thread
<neggles>
that'd do it yeah
<neggles>
the ap300 is what 667mhz or something?
<hurricos>
this guy's 1GHz
<hurricos>
ugh how do I prevent opkg from trying to ipv6
<hurricos>
=_=
<slh>
DTS would indeed make it trivial to provide 3 images just differing in their CMDLINE (and whatever else reacts to that in userspace)
<Grommish>
hurricos: uci del network.wan6? :D
<neggles>
all you'd need to do is pass a different root=/dev/mmcblk{}
<Grommish>
Granted,not a great option..
<Grommish>
Yah, but at this point, for the less than 500 units produced, I think it's safe to say anyone who still is using them is either running a 3.x kernel, or binned them a while ago.. so one option is better than none
<hurricos>
uci show | grep 6 gives no relevant results whatsoever
<hurricos>
no wan at all fwiw
<neggles>
hurricos: uci set network.lan.delegate='0' ?
<hurricos>
my /etc/resolv.conf points at another OpenWrt router
<neggles>
one of my biggest annoyances with openwrt is how every single-interface device defaults to trying to become the ipv6 DNS/router master for everything
<hurricos>
which does do DHCPv6
<neggles>
and resolves AAAAs no doubt
<hurricos>
but this device does not nor do I want it to
<hurricos>
no
<hurricos>
it's not!
<hurricos>
It's SSL.
<neggles>
oh
<hurricos>
the box thinks it's Mar 15 :rofl:
<hurricos>
ahhhhh
<hurricos>
easy
<neggles>
wait... it wasn't DNS?
<neggles>
that's illegal
<hurricos>
neat!
<hurricos>
wow no
<hurricos>
it clears LESS THAN HALF
<hurricos>
of the bandwidth
<hurricos>
as a sender over iperf3
<hurricos>
err
<hurricos>
sorry
<hurricos>
not less than half. slightly more. 485Mbps vs 930
<hurricos>
but surprisingly different
<hurricos>
533mhz
<hurricos>
is why
<neggles>
yes'm
<neggles>
half the clock :P
<hurricos>
yeah.
<hurricos>
BSAP2030 is "just better" :o
<hurricos>
interesting.
<hurricos>
stays at 21% idle too
<hurricos>
OK, wish me luck! sysupgrade time
<hurricos>
Oh shit I forgot mtdsplit
<hurricos>
no I didn't. It was in config-5.10 :^)
<hurricos>
left the image to build as sysupgrade-tar =_=
csharper2005 has quit [Read error: Connection reset by peer]
<hurricos>
let's fix that, shall we?
<rsalvaterra>
I just woke up and read the backlog.
csharper2005 has quit [Read error: Connection reset by peer]
bluew has quit [Ping timeout: 480 seconds]
csharper2005 has joined #openwrt-devel
Borromini has joined #openwrt-devel
csharper2005 has quit [Read error: Connection reset by peer]
danitool has joined #openwrt-devel
cbeznea has joined #openwrt-devel
csharper2005 has joined #openwrt-devel
csharper2005 has quit [Read error: Connection reset by peer]
mattytap has quit [Ping timeout: 480 seconds]
cbeznea has quit [Quit: Leaving.]
cbeznea has joined #openwrt-devel
<Borromini>
stintel: thanks for the octeon fix :)
<Borromini>
though nobody wants my damaged ERLite it seems :P
robje has quit [Quit: "upgrade"]
robje has joined #openwrt-devel
csharper2005 has joined #openwrt-devel
csharper2005 has quit [Remote host closed the connection]
csharper2005 has joined #openwrt-devel
robimarko has joined #openwrt-devel
dwmw2 is now known as dwmw2_gone
<stintel>
rsalvaterra: in the end it was just git bisect ¯\_(ツ)_/¯
<stintel>
Borromini: yw :)
* stintel
yawns
<PaulFertser>
Oh wow you finally squashed that memleak on octeon bug?!
<stintel>
if only I hadn't ignored the "restarting dnsmasq triggers it" bit ...
<stintel>
bisecting went relatively smooth
<stintel>
and if upstream didn't fix it, the commit introducing the problem reverts cleanly so that would have been a possible intermediate solution
<Borromini>
stintel: will you give it some time before you revert the source-only on 22.03 as well?
<Borromini>
would be good if the images got built for the first RC so it gets wider testing
<Borromini>
don't know if after hnyman's mail someone will pull the trigger on an RC1 :)
<stintel>
I'm not doing anything in 22.03 for now, too much other work on my plate
<Borromini>
ok
* Borromini
has moved all his own stuff to 22.03 already
<stintel>
now that the octeon leak is plugged I'm tempted to mess around with the SNICs a bit more :)
shibboleth has joined #openwrt-devel
<rsalvaterra>
stintel: Someone just backport the patch, revert the source-only status of Octeon and ship it! :)
<rsalvaterra>
I'll do it later today if no one beats me to it.
<rsalvaterra>
We can deal with the rebasing conflicts later when the patch hits stable.
<rsalvaterra>
(Trivial.)
<rsalvaterra>
Borromini: Avoid moving stuff. Just stay in master. ;)
<stintel>
oh fsck, chores calling
cbeznea1 has joined #openwrt-devel
cbeznea has quit [Read error: Connection reset by peer]
_lore_- has joined #openwrt-devel
csharper2005 has quit [Ping timeout: 480 seconds]
_lore_ has quit [Ping timeout: 480 seconds]
<Borromini>
rsalvaterra: well if it was just me in the house... :P
<rsalvaterra>
stintel: Nevermind, I see it's in master already, but we still need to backport it for 22.03.
<stintel>
like I said, I'm not doing 22.03 for now
<stintel>
feel free to cherry-pick
<PaulFertser>
I wonder if anybody has already researched reasonable options for getting ethernet over PCIe. Seems like every NIC vendor invents something custom so far?
dlg_ is now known as dlg
rua has joined #openwrt-devel
ekathva has joined #openwrt-devel
castiel652 has quit [Quit: Leaving]
csharper2005 has joined #openwrt-devel
mattytap has joined #openwrt-devel
shibboleth has quit [Quit: shibboleth]
srslypascal is now known as Guest1094
srslypascal has joined #openwrt-devel
Guest1094 has quit [Ping timeout: 480 seconds]
cbeznea1 has quit [Read error: No route to host]
cbeznea has joined #openwrt-devel
gladiac is now known as Guest1095
gladiac has joined #openwrt-devel
Guest1095 has quit [Ping timeout: 480 seconds]
castiel652 has joined #openwrt-devel
robimarko_ has joined #openwrt-devel
mattytap has quit [Ping timeout: 480 seconds]
<stintel>
of course macOS has to be a bitch again
<stintel>
goddamnit
goliath has joined #openwrt-devel
robimarko has quit [Ping timeout: 480 seconds]
mattytap has joined #openwrt-devel
mattytap has quit [Remote host closed the connection]
mattytap has joined #openwrt-devel
mattytap has quit [Remote host closed the connection]
mattytap has joined #openwrt-devel
mattytap_ has joined #openwrt-devel
mattytap has quit [Read error: Connection reset by peer]
<stintel>
Filesystem Size Used Avail Capacity Mounted on
<stintel>
/dev/gpt/rootfs 3.9G 3.6G -55M 102% /
<stintel>
go home fbsd, you're drunk
<Borromini>
compression?
<stintel>
compression or not, df shouldn't show negative values for avail or > 100%
<stintel>
it's retarded
<stintel>
ahh, they still haven't fixed their packaging. lol
<stintel>
so you have /usr/bin/getopt and /usr/local/bin/getopt if you install getopt with pkg
<stintel>
basically a similar mess as macOS
* stintel
remembers why he stopped playing around with bsd a long time ago
csharper2005 has quit [Ping timeout: 480 seconds]
bluew has joined #openwrt-devel
cbeznea has quit [Quit: Leaving.]
cbeznea has joined #openwrt-devel
<Grommish>
stintel: There is a reason bsd and bsdm are only 1 letter off
<stintel>
:D
csharper2005 has joined #openwrt-devel
<Borromini>
:P
<stintel>
ok so on the Firebox M200, mdio list suggests 2 macs are connected to the marvell switch
<stintel>
it also confirms the phy for the other 3 macs is mv88e1543 (but I knew that already from removing the heatsink)
<stintel>
time to compare the register values in u-boot vs linux and then hopefully figure out how to fix networking
gladiac is now known as Guest1106
gladiac has joined #openwrt-devel
<neggles>
PaulFertser: there is actually a standard for the eth-over-pcie kinda
<neggles>
there are two common ways it's done, 1) pretend to be some other kind of NIC, 2) present a PCIe non-transparent bridge and use the NTB ethernet driver that's in-kernel
Guest1106 has quit [Ping timeout: 480 seconds]
<neggles>
in the case of the snic10e it actually shouldn't be too difficult, most of the plumbing is already in there because that's how the LiquidIO versions of the card work
<neggles>
IIRC it can use the third common option, which is "present an openvswitch interface"
mrkiko has joined #openwrt-devel
<PaulFertser>
neggles: thanks!
hexagonwin has joined #openwrt-devel
danitool_ has joined #openwrt-devel
csharper2005 has quit [Ping timeout: 480 seconds]
csharper2005 has joined #openwrt-devel
danitool has quit [Ping timeout: 480 seconds]
valku has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
hexa- has quit [Quit: WeeChat 3.3]
hexa- has joined #openwrt-devel
dangole has joined #openwrt-devel
mrkiko has quit [Quit: leaving]
minimal has joined #openwrt-devel
pepe2k has joined #openwrt-devel
<yolo>
building openwrt under WSL2, it got stuck at tools/{...,quilt} for like 10+ minutes, I have a 16-core i7 with 64GB memory and can build the yocto poky in 20 minutes, not sure what's going on here.
<yolo>
top shows two threads: mconf and cc1plus
<stintel>
tools takes >20m in github ci on ubuntu and ~1h on macOS, nothing wrong here
<yolo>
ok, it's just that most cpus are idle, i guess it's some dependencies at building tools
<stintel>
did you pass -jX ?
<yolo>
i pass -j
<yolo>
when it gets to build packages, cpus are fully loaded in general
<yolo>
as a comparison, yocto loadavg shots up to 60 overall, openwrt is 3 for the first 15 minutes(building tools)
<yolo>
did not check buildroot but it does finish in 8 minutes
<yolo>
to build a full c/c++ sdk there
<stintel>
you can't compare them really
<yolo>
all pkgs are pre-downloads to remove network speed factor
<stintel>
there are just a lot of things to be built
<Slimey>
run with V=sc to see details
<schmars[m]>
i had the impression that -j only applies to the packages stage anyway
<yolo>
true, but i got a new laptop and just want to build everything and see speed improvements, next is to build android
<schmars[m]>
didn't actually verify, but just an impression from observing my own full builds
<Slimey>
i know it doesnt apply to makesqushfs or something :P
<stintel>
no but at least we no longer limit mksquashfs to 1 CPU
<Slimey>
ah
<stintel>
shaves 4m of image build time for M300
<Slimey>
thats it
<yolo>
schmars[m]: you're probablly correct, before pkgs the parallel build is not really flying, if at all
<stintel>
there is only 1 Makefile in tools that sets PKG_BUILD_PARALLEL but I'm not sure if tools/* respects that
<yolo>
now it's still at gcc gdb binutils fortify-headers compile, those can at least levarage multiple cpus, but only 3 out of 16 cpus are busy
<Grommish>
yolo: Are you setting WSL limitations on cores in your wsl.conf?
<Slimey>
i would try it but the only boxes i have with that more horsepower are work servers
<yolo>
Grommish: no, intentionly i want to stress it, so no wsl.conf, no -jX just -j
<Grommish>
yolo: If you want to stress it, use -j$(nproc)
<Grommish>
or just echo $(nproc)
<yolo>
i thought -j is more aggressive?
<Grommish>
to see how many "cores" its working with
<yolo>
yeah it's 16, i use top's 1 to see them all in real time
<Grommish>
I peg my cores @ 100% using WSL to the point I had to set limitations in the config (.wslconfig for global) so I could use it during compiles
<Grommish>
I would try -j$(nproc) and see
<yolo>
in my case i don't use windows, i ssh into WSL and actually use it from another lower-powered ubuntu screen
<Slimey>
i like btop
<yolo>
so, i will still everything from windows into wsl
<yolo>
s/still/steal/
<Grommish>
I'm sure you have your reasons, but I expect someone to ask why use WSL at all in that case
<Grommish>
But yes, it should redline
<yolo>
because that windows laptop is more powerful, i want to see if it can work as a build machine
castiel652 has quit [Read error: Connection reset by peer]
<Grommish>
yolo: *nod* I'm a big fan of WSL2 personally
<yolo>
tried virtualbox but under heavy io(building yocto/openwrt in parallel while downloading) will crash virtualbox, wsl so far is robust
<Grommish>
and it's what I use to build
<yolo>
google reports virtualbox can fail under 'heavy IO scenarios'
<Grommish>
There is no real difference in giving it more than 16gb RAM BTW, it won't use it
<Grommish>
at least not during building that I can see
<yolo>
a quick checking of tools/Makefile toolchain/Makefile found nothing about -j or 'PARRALEL'
<Grommish>
The gcc-initial and gcc-final seem to take a while
<Grommish>
But you only will need tro do it infrequently
<Slimey>
im drawing a blank whats the name of the dtb decoder
<aparcar[m]>
Slimey: pyFTD?
<aparcar[m]>
Anyone tried gcc12 betas for openwrt?
<rsalvaterra>
aparcar[m]: Not betas, but I'll try the final as soon as it's out.
<yolo>
took 47 minus to build, something is goofy
<yolo>
will record and move on. one thing is for sure, tools esp toolchains are not parallelized
<hurricos>
yolo: err, what? yes they are. It's make all the way down. Perhaps you got stuck on a config step.
<hurricos>
make passes its args to submake
<hurricos>
if it's make at the bottom with a Makefile having multiple targets, it'll parallelize that by splitting up independent jobs
<hurricos>
config step seems most likely -- the config / "toolchain check" setup step in each place does horrible things just to verify it can.
csharper2005 has joined #openwrt-devel
csharper2005 has quit [Read error: Connection reset by peer]
<hurricos>
isn't it possible to pull caldata directly out of nvram by mentioning it correctly in the device tree?
<hurricos>
for e.g. ath10k hw which has a non-eeprom-based caldata store.
<hurricos>
s/nvram/flash/
<hurricos>
something something nvmem-cells, not sure what the binding I need is really
<hurricos>
Yes it is! and it's recent!
<torv>
stintel: Can I get a wiki account? I'd like to add details after having several times thought "Oh, this section is missing a detail/a template part not filled yet." for devices I serviced myself.
<Slimey>
heh same here
<schmars[m]>
same - wanna create wiki page for Unifi Switch Flex - outdoor poe switch that gained workable openwrt support recently
<Slimey>
hurricos when i look at the flashrom dump of the eeprom it starts at a different address for cal data
<stintel>
torv: schmars[m]: /q me your email and preferred username
<stintel>
Slimey: was the "same here" for a wiki account?
<stintel>
if so, see previous message :P
<hurricos>
Slimey: I have the address, no worries. Just hacking on nvmem-cells access for the caldata.
<Slimey>
k
<Slimey>
yeah you where right looks like 3FC5000
csharper2005 has joined #openwrt-devel
<Slimey>
but there is something else at 3F85000
<Slimey>
AP135-020-0001
<stintel>
I'm getting an awful lot of BGP connection attempts on some of my public IPs ... is BGP hacking the new hipster thing among kiddies? :P