digitalcircuit has quit [Quit: Signing off from Quassel - see ya!]
digitalcircuit has joined #openwrt-devel
victhor has quit [Remote host closed the connection]
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
Grommish has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
<stintel>
nbd: just had a stall on mt7613 with 7663mp1827-20200904171623 firmware
<stintel>
reconnected my laptop (ax200) twice, first time that gave a few seconds of ping responses but then nothing and the 2nd time didn't help at all
<stintel>
I then eventually disconnected my galaxy s21 and shortly after that it unstalled
<Grommish>
Can anyone tell me the best way to strip double-quotes from a string inline in a Makefile? I'm trying to use CONFIG_TARGET_SUFFIX, but it's set to ="musl", which brings the "'s
<Grommish>
So $(ARCH)-unknown-linux-$(CONFIG_TARGET_SUFFIX) returns mips64-unknown-linux-"musl"
<stintel>
and these netlink errors are hard to debug :(
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
<stintel>
meh I see the memory usage increasing on my ap upstairs but no /proc/slabinfo
<rsalvaterra>
stintel: Do we enforce real name SoBs?
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
<stintel>
yes
<rsalvaterra>
Ok, noted, thanks! :)
<stintel>
sob with fake name makes 0 sense
<rsalvaterra>
Unless you're trying to sabotage the project, of course…
<PaulFertser>
I'd say sob with fake name that looks legit makes plenty of sense.
<mangix>
stintel: my understanding is real looking fake name is fine.
<PaulFertser>
I think SoB is needed to shift liability from the maintainers to the particular contributor.
hgl has quit [Remote host closed the connection]
<PaulFertser>
So that at any point of time the maintainers can claim they made a reasonable effort to not accept code unsuitable for inclusion.
hgl has joined #openwrt-devel
<rsalvaterra>
PaulFertser: That's another story. In fact, there are people using pseudonyms contributing to the Linux kernel.
<PaulFertser>
rsalvaterra: I'd say it's the same story. The Linux maintainers invented DCO just for that afaict.
<mangix>
I'll just add that doing a google search for ansuel mostly returns results for the same person.
<stintel>
nbd: on the AP upstairs where the mem is increasing I disassoc'd one client via hostapd_cli, memory usage dropped by 8MB instantly
<stintel>
but it keeps increasing, maybe the stalls are related to a memory leak
<rsalvaterra>
stintel: Ouch. Something's leaking.
<\x>
PaulFertser: i found another device that does that
<\x>
[ 1.375386] qcom-pcie: probe of 40000000.pci failed with error -110
<\x>
intel 4965agn
<\x>
hmmm
<stintel>
building my next image with CONFIG_KERNEL_SLABINFO=y
<nbd>
stintel: when the stall happens, frames get stuck in the hw queue
<PaulFertser>
\x: I have a theory. Probably it assumes PCIe lane reversal (connecting the 3rd lane to 0th, 2nd to 1st etc)
<nbd>
stintel: and that eats up memory
<\x>
PaulFertser: tell me more
<\x>
I can tape up pins if needed
<nbd>
stintel: if memory is recovered by restarting wifi, it's not a leak
<\x>
maaan, what a waste that mt7612 was
<\x>
not bad for 12$ though
<nbd>
stintel: and for ethernet and mt76, skb data buffers are not allocated from slab, so they will not show up in slabinfo
<nbd>
they're allocated through the page allocator
<PaulFertser>
\x: PCIe specification allows for automatic polarity inversion for individual lanes and most devices also support reversal of the lanes ordering. So if you have a 4x lane device there (you can check with lspci -vv | grep LnkSta) it might actually have lanes in reverse order to ease board layout. But now that I think about it more I find it unlikely, I'd expect a wifi card to be a 1x device.
<\x>
yep
<\x>
and the slot is also 1x
<\x>
I guess ill just have a go with mt7921k sometime, but after some searching, nobody even have an iw phy dump of it
<\x>
nbd: thanks for confirming it, I was nearly gonna buy one
<nbd>
maybe it'll get some limited ap mode someday
<nbd>
but it won't be comparable to the other chipsets
<nbd>
since it's not aimed at the ap/router market
<\x>
yeah, its bundled with asus laptops nowadays, so its like an easy to get wifi 6 card
<nbd>
if you want wifi 6, try to find something with 7915
<\x>
85 cny, so its like 14$
<\x>
nbd: well, im already trying mt7612 and it wont even initialize on ipq4019
<\x>
but yeah i can still try sometime, they arent so cheap though, 7615's
<stintel>
nbd: ok ran wifi, mem usage dropped back to ~33MB
nlowe has joined #openwrt-devel
<nbd>
\x: can you show me details about 7612 on ipq4019?
<stintel>
so it's the stall that is causing the mem increase, not the other way aroudn
hgl has quit [Remote host closed the connection]
<PaulFertser>
\x: so is it still link doesn't come up error? Can it be that something about your rework gives suboptimal signal integrity? E.g. those connections are probably not meant to be 0R?
<stintel>
but that basically means if I see the peak in my mem graphs of my monitoring, it's hitting the stall
<\x>
nbd: im not really like a coding guy or something, I only got dmesg boot of it
<PaulFertser>
\x: yes, please paste the whole PCIe init error again for nbd to see.
<\x>
<PaulFertser> \x: so is it still link doesn't come up error? Can it be that something about your rework gives suboptimal signal integrity? E.g. those connections are probably not meant to be 0R?
<PaulFertser>
But same slot works without any modifications of hardware and software with many other PCIe devices, some Intel cards, an NVMe device etc.
<\x>
prolly. the guy who posted comments on r619ac said that it needs around 22 ohms
<\x>
but i just did a solder bridge, so literally 0
<stintel>
nbd: replacing the previous or incremental ?
<neggles>
those REFCLK connections should not be a 0R, they should be 22
<neggles>
s/22/22R
<neggles>
and that's probably your problem
<\x>
mehhh
<\x>
I guess i really need to hunt a 22 ohm 0402 resistor
<neggles>
REFCLK is important, without it nothing else works, if it's not clean or it's out of phase nothing else works
<\x>
im not putting a through hole 1/8 watt on this, the pads are too small
<neggles>
yeah and it wouldn't work.
<neggles>
it's a 100MHz clock
<neggles>
signal integrity matters
<neggles>
and you'll be getting really bad ringing without those resistors; some devices will work anyway, some won't
<\x>
anything else worked though but not those two pcie 1.1 cards
<neggles>
older cards/chipsets are likely to be more sensitive to refclk disturbances, yes :P
<\x>
that hella weird when it overclocking world once you raise pcie refclock (cuz raising bclk) you need to run lower pcie rev
<neggles>
yes but that's because you're exceeding the max transfer/data rate the transceiver on the TX/RX data lines can handle
<PaulFertser>
Series resistors work for termination and that reduces ringing. But why aren't those lines terminated on device side with parallel resistors?
<neggles>
PaulFertser: technically it's not termination, it's impedance matching
<neggles>
and refclk is terminated host-side on mPCIe
<nbd>
stintel: incremental
<neggles>
*sigh* yeah, okay, I've spent far too much of my life on PCIe trace skew/impedance matching in the last year
nlowe has quit [Read error: Connection reset by peer]
<PaulFertser>
neggles: I'm not an EE so please excuse me :) So why isn't refclk impedance matched on the device side? Because you can have a star topology for that and route same refclk to several devices?
<neggles>
correct
<neggles>
refclk is common to all endpoints
<\x>
tfw im actually EE and I dont know about this
<neggles>
I'm not really an EE either, though I guess i've designed enough things that work to qualify as an armchair EE :P but I didn't feel like spending $1700 on an MXM to PCIe adapter so
<neggles>
i made one
<neggles>
the PCIe 3.0 spec and MXM 3.x spec PDFs are... something
<neggles>
"Any terminations required by the clock are to be on the system board."
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
<neggles>
REFCLK runs at ~10R higher impedance than the TX/RX pairs, requires +/-300ppm accuracy, has to be within 10ns of the length of the TX/RX pairs, and within the pair length must be matched within 0.127mm
<neggles>
a few of my designs are a testament to just how far out of spec you can be and still have things work, but :P
<neggles>
shorter version: the system is fully responsible for how the clock is generated/delivered/terminated/etc, this allows greater freedom in design (using spread-spectrum clocks if you want, etc) since there's no fixed card-side stuff to worry about
<neggles>
in my (limited) experience, PCIe cards will tolerate the actual data pairs being wildly out of spec for everything except intra-pair length matching, but they're a lot pickier about refclk
rua has quit [Ping timeout: 480 seconds]
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
rua has joined #openwrt-devel
<\x>
neggles: I wonder if you have any idea on how to overclock ipq4019 higher? theres that 896MHz patch out there and it works nicely, but as always, higher is better ;)
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
<nbd>
stintel: when you're running the new patch, please check if any kernel warnings appear in the log
<nbd>
i added some
<neggles>
\x: not a clue, and i doubt you'd have much luck
<neggles>
it'd probably struggle with thermals and power delivery if you push it much higher, and the clock generator might not be able to go higher
nlowe has joined #openwrt-devel
nlowe has quit []
<Grommish>
This thing just gets bigge and bigger.. 666M Nov 26 05:42 dl/rust-1.56.1-x86_64-unknown-linux-gnu-install.tar.xz <- Host installer :/
<neggles>
FWIW, if you don't actually need the extra performance, I wouldn't be overclocking the thing; it'll run a lot hotter, use more power, and it's much more likely to have weird glitches
<neggles>
there's no scaler in the output you can use
<neggles>
the DDR one has a weird set of multipliers/dividers on the APSS output because, well, that's what that's for
<neggles>
but even if the silicon can take it, all you're really doing is wasting power and shortening the chip's lifespan :P
<neggles>
if qcom thought it could reliably do higher clocks, they wouldn't be hidden - maybe you won the silicon lottery and yours will do 896 forever, maybe you didn't and it dies in a week
<\x>
neggles: I got three of these, one was bought sept last year, 896 since february i think, that patch first showed up after I saw right.com.cn users running 896MHz on theirs
<neggles>
i said maybe!
<\x>
I bought another two, two mopnths ag
<neggles>
there's no real way to tell :P
<\x>
months ago*
<neggles>
it's not like a pi 3b+/4 SoC, or a modern laptop/phone/tablet CPU/GPU/SoC, where it's constantly monitoring temps/power/clocks to keep itself safe & you can get extra performance by whacking a big cooler on it and telling it to ignore power usage
<\x>
running the seond one at 896MHz too, for like 2 months now, no issues yet I guess
<neggles>
it's not a huge clock bump, it's probably fine if you don't need the thing to last for 7-10 years of continuous runtime
<neggles>
what if you've ended up with a chip that's on the lower end of quality, that would've lasted forever at 710 but will only make 18 months at 896?
<\x>
neggles: this router is 22$, within 18 months ill prolly just buy a betterr one
<neggles>
well yeah. but you get my point
<\x>
yup
<\x>
ofc itll shorten the life of it considerably faster
<neggles>
the short version is, "if you're sitting at 5-10% CPU most of the time, why bother?"
<\x>
b-b--b-but overclock
hgl has quit [Remote host closed the connection]
<neggles>
especially if you're going to use perf governor to force it up to max clocks all the time
hgl has joined #openwrt-devel
<neggles>
the first Pi 4B+ I got ran perfectly fine at 2GHz for over a year at two voltage steps below the warranty-void threshold, then one day it just wouldn't turn on anymore
<neggles>
it wasn't overheating, wasn't under a lot of load, spent most of its time just sitting there
<\x>
I think I bought my newifi d3 (mt7621), sept 2018, overclocked it around may maybe, 880 -> 1100
<neggles>
if i hadn't overclocked it, it probably would've been fine
<\x>
now I just run it at 1000 ;)
<\x>
it started crashing after a few months at 1100
proxide has quit [Quit: Connection closed for inactivity]
<neggles>
i believe that proves my point :P (now that pi sits on a shelf, with a sad face drawn on the SoC in sharpie, as a reminder to not overclock things that don't need it)
<\x>
many people on the forums also had the same issues, some of them just added more capacitors all around, on some it helped, most didnt
<neggles>
that's the other thing, overclocking puts more stress on the voltage regulators supplying the chip
<neggles>
they may not be capable of delivering the power that it needs for those higher clocks reliably
<neggles>
sometimes you get lucky - you get a really good chip, the board designer put some extra margin in the power supply - and everything works out
<neggles>
most of the time it looks like it's working just fine, then it dies out of nowhere, usually just when you needed it for something >:(
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
<neggles>
i do get the "b-b-b-but overclocking!" part, it's fun & if you don't mind killing the thing, go nuts - i don't tell you how to live
<\x>
neggles: so the theory here is I need to oc that memory to also get it running on the core
<neggles>
you can't OC the memory
<neggles>
the memory clock is configured by proprietary qcom blobs in the u-boot based on the clockspeed data from the DRAM chip
<\x>
i wonder how they get data from the dram chip, it doesnt have spd on it
<neggles>
they do have vendor/part IDs though
<neggles>
there's probably a lookup table or somesuch
<neggles>
either that or it's set by the OEM when they make the thing
<mrkiko>
mx: device name?
<PaulFertser>
I'd expect vendor/part ID to come from SPD.
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<neggles>
PaulFertser: you're right
<neggles>
there is indeed no obvious way to identify a specific DDR3(L) chip on a board, must be set by the OEM when they build the u-boot
hgl has quit [Remote host closed the connection]
<neggles>
oooh it looks like this octeon build w/atrociously hacky NAND driver might actually be compiling successfully
<neggles>
made it past the kernel, woo!
<mrkiko>
neggles: was curious about the device being overclocked
<mrkiko>
vendor/model name
<neggles>
oh haha that's \x's ipq4019 board
<neggles>
i'm not brave enough to overclock the octeon yet
<Grommish>
neggles: Any idea if they've fixed the memleak on the Octeon 5.10+?
<neggles>
i'd like to have it actually, y'know, work
<mrkiko>
neggles: and we don't know the board name?
<mrkiko>
No, nevertried to overclock something as well for now.
<neggles>
um it's called the "R619AC" i believe
hgl has joined #openwrt-devel
<neggles>
Grommish: not a clue, i'm currently building 19.07.8, with the octeon SDK kernel patches rebased onto 4.14.241
<mrkiko>
neggles: thanks
<Grommish>
neggles: Ah, ok.. I'm running 5.4 because 5.10 and beyond just massive kernel memleak
<neggles>
Grommish: fwiw i've had the current (NAND-less) 5.10 build running on this CN6640 for about four days now and it's using 78 whole MB, but it's also doing... nothing
<Grommish>
neggles: It seems to be tied to networking, something networking adjacent, or the octeon ethernet driver.. I've not yet nailed it down
<Grommish>
If I pull the ethernet drive from the build, no leak.. and I'll have to work forward from there :(
<neggles>
Grommish: ah, this *is* using the octeon ethernet driver, but with a weirdo XAUI-to-SFI quasi-PHY tacked on
<neggles>
I just want to confirm whether it's actually *possible* to use the NAND controller on this thing, i can't find any product that actually uses the nand controller on a pre-7xxx octeon
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
nlowe has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
<neggles>
Grommish: actually i might have something for you ont hat
<Grommish>
neggles: Oo.. Do tell, because I've given up on 5.10+ at the moment and returned to rust-lang, but I'd like to get it figured out
<neggles>
which SoC specifically?
<Grommish>
Octeon3 CN7020 AAP 1.2
drikus_ has quit [Ping timeout: 480 seconds]
<neggles>
there was a particularly annoying patch in the cavium 4.14 tree... where'd it go...
<Grommish>
neggles: Problem is, it's not an issue in the OpenWrt 5.4 kernel, only 5.10 and forward (I've tested 5.15 as well). and I'm not sure what changed between the two revisions and everyone has said it isn't really feasible to bisect
<mrkiko>
Grommish: BTW, do you know if KFENCE or KASAN might help? Don't know how much ram memory is available on the device tough, only thinking
<Grommish>
1Gb RAM, 4Gb Flash storage divided into 4 partitions, but I'm not familar with either of those, and I've never really tracked down a memleak before - i'll see if they can help.. I enabled KMEMLEAK and slab/slabtop, which i where I found the ethernet driver issue - wrote the maintainer, and they said it's because kmemleak can't see it until the fpa releases it back or something
<Grommish>
Which is when I pulled the ethernet driver from the build, verified without networking, no leak, and then stalled out and haven't touched it since
<Grommish>
I know QNAP released a firmware update that fixed an issue with dnsmasq having a memleak, but i dunno if that issue was dnsmasq related, QNAP related, etc
<Grommish>
I'm assuming it was QNAPs cluster
<neggles>
Grommish: so uh, the octeon SDK has an entirely separate driver for ethernet on octeon3 - octeon3_ethernet
<Grommish>
Anyone on who is fairly familar with the ARMv7 family?
<rsalvaterra>
Grommish: How familiar? :)
* rsalvaterra
has an ARMv7 device.
drikus_ has joined #openwrt-devel
<Grommish>
rsalvaterra: because OpenWrt doesn't split out the ARM family in $(ARCH), I need to split it out by soc name and hardfloat vs softfloat
<Grommish>
So I added a $(CONFIG_arm_v7) check and just change it, but then I'm left with: $(CONFIG_TARGET_SUFFIX) being muslgnuabi, and I need a soft-float or hard-float split (musleabi and musleabihf)
<Grommish>
Any suggestions? :D
<Grommish>
Or, know an easy way to check a target for HF or not?
hgl has quit [Remote host closed the connection]
<Grommish>
They seem to use 'fpu' in the FEATURES field for the target, but that's such a ugly way to do it
Gaspare has joined #openwrt-devel
<neggles>
CPU_TYPE, CPU_SUBTYPE
hgl has joined #openwrt-devel
minimal has joined #openwrt-devel
Gaspare has quit [Remote host closed the connection]
<Grommish>
Hmm.. That looks like it'll format it as arm_v7 then or arm_v6?, but only if it's defined by the target?
<Grommish>
Oh, no.. I see
<neggles>
eg ipq806x = CPU_SUBTYPE:=neon-vfpv4, if you've got `vfp` in that string you've got hardfloat afaik
<Grommish>
Ok, so the vfp is hf?
<Grommish>
Gotcha
<neggles>
bcm2708, which has an ARM1176JZF-S, has `vfp`
pmelange has joined #openwrt-devel
<neggles>
but the ARM926EJ-S in the sam9x, with no FPU, well actually just doesn't have a subtype heh
<neggles>
`neon` may also indicate floating point - the neon unit can do FP, and there are a couple SoCs with neon but no vfp, not sure if that qualifies for musleabihf or not
<Grommish>
I'll just skeleton it and people who have the SOC can test it
<neggles>
the sunxi cortex-a53 target doesn't have a cpu_subtype either, so there's a few places that'd need fixing up
<neggles>
none of the A53 targets list a subtype, A53 definitely has an FPU
<neggles>
you could get away with testing just CPU_TYPE for the various kinds of cortex - A9 is the only weirdo where it might or might not have an FPU apparently? - and if it's not a cortex/starts with 'arm' but has an 'F' in the part number, it's got an FPU; but probably better to get the targets fixed to properly indicate features
dedeckeh has quit [Remote host closed the connection]
<rsalvaterra>
Grommish: Is there even ARMv7 without hardware floating point (VFP)? :/
<rsalvaterra>
I know that's a possibility in ARMv6…
<Grommish>
rsalvaterra: Dunno.. I don't run any ARM devices at all, but I know rust-lang defines an armv7-musleabi and an armv7-musleabihf
<Grommish>
so, I'd have to assume it's used by someone
<rsalvaterra>
Interesting…
<neggles>
cortex-A8, cortex-A9 it's optional
snh_ has quit [Remote host closed the connection]
<neggles>
armhf = ARMv7 + VFP3-D16 or better
<neggles>
don't think i've seen a cortex-A8 in the wild, though, and apparently its VFP module is 10x slower than the A9's
Gaspare has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
<rsalvaterra>
stintel, nbd, I've seen you guys talking about MT7613. I don't know if it's related, but has anyone noticed any stalls on MT7615 hardware?
<stintel>
and https://termbin.com/7f83 mt76_connac_mcu.c so this could be relevant for all supported chips?
<stintel>
nbd: mt7615/main.c --> I'm using mt7613, maybe that's why I'm not seeing any warnings with this change ?
<stintel>
I don't know the internals of the driver though, and git grep 7613 doesn't match anything so maybe mt7615 code is handling 7613
<rsalvaterra>
stintel: Are those links correct? Can't access them, for some reason.
<stintel>
rsalvaterra: they are
<rsalvaterra>
stintel: Yes, MT7613 is handled by the same driver as MT7615.
<stintel>
ok
<rsalvaterra>
Oh, not I can access them. Must be stubby acting up.
<rsalvaterra>
*now
<stintel>
I unplugged my QCA APs and have only 2x EAP235-Wall active for the moment
<stintel>
I will leave my network like this for a while, until the stalls are fixed or nbd gives up fixing them :P
<stintel>
this reminds me of a buggy ath9k chip when we were preparing the 1st LEDE release I think
<stintel>
1043 something
<stintel>
was an infamous AP with that chip
<stintel>
tl-wr1043nd v1 iirc
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
<hurricos>
stintel: was it an ar9344?
<hurricos>
one of the ahb ones?
hgl has quit [Remote host closed the connection]
<hurricos>
It's so funny to have started with the OpenWrt community so late. I never knew a time where ath9k was anything short of perfect
<hurricos>
with small exceptions which get fixed as soon as I report them lol
<hurricos>
like the whole smps thing
<stintel>
Atheros AR9103
<stintel>
according to the wiki
<hurricos>
oooh
<hurricos>
Ancient ._.
hgl has joined #openwrt-devel
<hurricos>
I think I have a cardbus one of those
<stintel>
I don't think I have 11n cardbus
<stintel>
but once a madwifi user sent me a cardbus card supported by madwifi back in the day
minimal has quit []
<stintel>
apparently that was in 2006 :P
<nlowe>
I still love the AR9380/AR9390 for hacking around - where perf isn't needed and you want to play - it's perfect
<stintel>
aye
<hurricos>
Yes, anything full-n (AR92xx and onwards) is very flexible. Personally I just like the realiability, I have someone old enough to be my grandmother relying on 50, 60 devices all not crashing
<hurricos>
at least not on account of the wireless hardware
<nbd>
stintel: mt7613 is a variant of mt7663, which is supported by the mt7615 driver
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
<nbd>
mt76_connac is a component used by the mt7615 and the mt7921 driver
<nbd>
stintel: so you're not seeing any warnings, but also no stalls?
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
daniel has joined #openwrt-devel
daniel is now known as Guest6864
Guest6864 has quit []
<stintel>
nbd: indeed
<stintel>
I have now also flashed my 2nd AP with the new firmware + 2 test patches
<stintel>
argh, net-snmpd not responding bug is popping up again
Gaspare has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
<nbd>
stintel: my second patch should not make a difference without also printing a warning
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
<stintel>
nbd: ok, then I guess I just didn't hit it yet
<stintel>
or one other option: as these are dumb APs, I'm not using firewall on them. but, I noticed this morning that my image config did have a bunch of ipt/nft kmods enabled and I have disabled all of those
<stintel>
do you think that could have any impact ?
spacewrench_ has left #openwrt-devel [#openwrt-devel]
spacewrench_ has joined #openwrt-devel
<spacewrench_>
Does anybody have a sense of how difficult it is to build a newer (stable) kernel for an Openwrt SOC? I can build 21.02.1 (linux-5.4.154) for my Onion Omega2+ (MT7688) and everything works fine. But I'd like to use some driver & devicetree features in a newer kernel. I was able to build 5.15.5 on the Omega2+ itself (slow!) but it doesn't boot. Is it worth continuing to try, or is it a super-guru level project?
<PaulFertser>
spacewrench_: you can try building 5.10 with OpenWrt master
<spacewrench_>
That might be recent enough to get the driver features I want to try...plus it's probably got a better chance of working than what I'm doing. I'll give it a shot, thanks!
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
nlowe has joined #openwrt-devel
nlowe has quit []
wvdakker has joined #openwrt-devel
Habbie has joined #openwrt-devel
Gaspare has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Gaspare has joined #openwrt-devel
<Habbie>
looking for development flow tips - say i was going to work on netifd, what would you do? copy over the ipk after every buil? or the binary? or drop a full debian chroot onto the openwrt device? :)
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
<dangole>
Habbie: you can use CONFIG_SRC_TREE_OVERRIDE to build e.g. netifd from your local git repo. for netifd you'd want to test a complete system eg. use qemu/kvm to boot x86/64 generic image. to speed up dev iterations, enable CCACHE for speed and/or build in RAM to make it fast (~ 1 minute on my system, building squashfs rootfs takes most time...). if you want to test on real hardware, setup TFTP server in bin/targets/foo/generic
<dangole>
and have board boot from there.
<Habbie>
oh yes, i assumed complete system - either a VM or a real device
<Habbie>
tftp boot is a nice one
<Habbie>
CONFIG_SRC_TREE_OVERRIDE is nice, thanks
<Borromini>
dangole: how much ram would you need to build in RAM (or how much do you have)?
<Habbie>
my openwrt dir goes up to 14GB of disk usage during image builds
<dangole>
Borromini: 16GB total is enough to build a basic image in RAM (while still using Firefox and stuff at the same time...)
<Habbie>
but it's on NVMe so I'm not sure RAM would help much
<Borromini>
dangole: ok, neat. thought I wasn't gonna cut it :P are there any instructions on the wiki for that?
<Habbie>
dangole, however, and i apologise if i'm missing something, is netifd -that- tied into things that i'd want to reboot for every change i make?
<Habbie>
dangole, (i totally see how the tftp suggestion makes sense for changes on a deeper level)
<dangole>
Habbie: 'opkg install --force-reinstall http://192.168.1.2/netifd-foo-412341.ipk ; /etc/init.d/network restart' is enough unless you are doing things related boot process
<Habbie>
dangole, oh URLs in opkg, also neat
<Habbie>
dangole, that's an awesome list of tips, thank you very much
<dangole>
Habbie: most welcome! looking forward to see what you are going to do :)
<Habbie>
dangole, i want to replace my openbsd router but i realised i'd like netns support
<Habbie>
dangole, also i found a small bug in the wireguard support but i'm not yet sure if that is in netifd or in the wg tooling for openwrt/netifd
<Habbie>
dangole, so i'll probably tackle the second one first, and then see how painful it would be to add support for putting interfaces in namespaces
Gaspare has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dangole>
Habbie: just that (putting interfaces into namespaces) is already supported for procd-ujail support. just that when using procd-ujail there is another netifd instance responsible for that netns which configures interfaces and also moves them back once the netns is shutdown.
snh has quit [Read error: Connection reset by peer]
<Habbie>
dangole, i saw the ujail bits, yes
<Habbie>
dangole, i haven't dug into what it does and how those processes then use the network at all
<Habbie>
dangole, but i'm looking for actual separate "routing instances" with no userspace processes involved in anythingg
<Habbie>
dangole, oh - interfaces *move into* one ujail?
<Habbie>
dangole, i don't immediately understand the usecase for that
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
snh has joined #openwrt-devel
<Habbie>
dangole, however, that kind of sounds like i could run a 'sleep <forever>' in a ujail netns that holds the interfaces that i want to separate
<dangole>
Habbie: yes, that should work :)
<Habbie>
ok
<Habbie>
you are full of wonderful ideas :)
<Habbie>
of course, that approach will not show up very well in luci
<dangole>
Habbie: I didn't mean to discourage you from implementing proper netns support ;)
<Habbie>
i already imagined separate netns boxes in luci
<Habbie>
with a wg interface sitting on a box boundary
<Habbie>
because its two sides live in two netnses
<Habbie>
(which is part of my usecase)
<dangole>
Habbie: ah ok, just using netns instead of policy routing
<Habbie>
not even sure i need policy, but without netns i'd need some carefully crafted firewall rules
<Habbie>
and that just feels wrong when netns is sitting right there
<Habbie>
no actually you're right, i would need policy routing
<Habbie>
(without netns)
Borromini has quit [Quit: Lost terminal]
danitool has quit [Ping timeout: 480 seconds]
nlowe has joined #openwrt-devel
Gaspare has joined #openwrt-devel
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nlowe has joined #openwrt-devel
<hurricos>
is danitool ever in here?
<hurricos>
I'm looking for someone who might know how to compile u-boot, and know the details on the DDR3 training program, for 88F6707
<hurricos>
oh
<hurricos>
wait
<hurricos>
danitool just left :crying:
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]