<hitech95>
dammit openwrt goes OOM now on 64MB of ram! I don't have any device compatible.
<Ansuel>
robimarko anyway we should really consider creating a proper way (with dts binding) to select a mem profile
<Ansuel>
also a sysfs mode would be good IMHO
<Ansuel>
also thinking about the shitty soc like ipq60xx
<zx2c4>
aparcar[m]: wg syncconf is what you're looking for
<zx2c4>
Can you revert that commit?
<Ansuel>
hitech95 we are embracing security stuff and that require memory
valku has quit [Quit: valku]
genuser1 has joined #openwrt-devel
<aparcar[m]>
zx2c4: sure can, even though the same approach exists for dhcp and wireless. Since you're the maintainer you have the say but please don't consider this option as exotic
<hitech95>
Ansuel: I got that. Unfortunatly lot of HW is on 64MB of ram...
<zx2c4>
aparcar[m]: ahh there's precident for it?
<aparcar[m]>
zx2c4: syncconf is what I need, however the configuration file is created with a netifd proto and that currently only support regeneration on restarts
<hitech95>
*Most of supported HW is on 64MB of ram
<robimarko>
Ansuel: Honestly, the hacks to get ath11k working on 256 are not worth the crappy HW
<robimarko>
IPQ60xx is decent, but it needs the RAM
<robimarko>
I personally couldnt care less about that HW, its essentially e-waste as soon as it was made
<aparcar[m]>
zx2c4: openwrt comes with configured but disabled wifis per default. if you want to temporarely disable dhcp you can do so by setting a flag instead of removing all config options
<Ansuel>
but i suspect the mem profile also limit other kind of thing.. agree on the ipq50xx... that can go as low as 64mb am i wrong?
<robimarko>
No
<robimarko>
Its the same deal
<robimarko>
Designed for at least 512MB
<robimarko>
With 64MB on that you would have enough RAM after the reserved nodes to boot the kernel
<Ansuel>
but they will never put 512mb on that soc
<robimarko>
Memory profiles limit the ath11k features and they reduce the reserved memory for Q6(ath11k)
<robimarko>
Ansuel: IPQ50xx is new stuff
<robimarko>
Its just getting on the market
<Ansuel>
isn't that lower spec than ipq60xx ?
<Ansuel>
or i'm confused
<robimarko>
Nope
<robimarko>
As far as I can tell its WiFi 6E focues
<Ansuel>
ohhhh so the real wifi6 stuff
<robimarko>
Yeah, like real budget stuff
<robimarko>
As its only dual core
<Ansuel>
and one nss
<robimarko>
Yeah
<Ansuel>
so no crypto stuff
<robimarko>
Yep, same as IPQ6k
<robimarko>
So, its a weird thing
<robimarko>
I mean, you are right its less specced then the IPQ6k
<robimarko>
Only dual core @ 1GHz, single NSS @ 1Ghz
<aparcar[m]>
zx2c4: you make the call, let me know
<Ansuel>
wonder if they will add wifi6e to ipq806x or they will follow the external pci way ?
<Ansuel>
ipq807x*
<robimarko>
IPQ807x can do 6E just fine
<robimarko>
IPQ60xx as well
<Ansuel>
i mean if they have plan of including it in the soc directly like it's currently for 2.4 and 5
<robimarko>
That is what I mean
<robimarko>
SoC can do it
<robimarko>
You just need to use the correct companion radio IC
<Ansuel>
so it will come for sure
<robimarko>
As they have moved the whole RF part to companion IC
<robimarko>
So it can be really flexible
<robimarko>
Anyway, time to go to sleep
<robimarko>
Gotta work tommorow(Actually today)
<Ansuel>
same thx for the good talking
<slh>
with wifi6e, you'll need at least 3 radios with quite some power consumption and heat dissipation anyways, that's not going to become 'cheap' soon
<Ansuel>
slh i think the ax3600 is more than enough
<Ansuel>
with ax9000 they went full meme with a fu*king fan LOL
<slh>
it's a great device, once OpenWrt runs properly - only RAM is a tad limited (thinking about adblock)
<robimarko>
Yeah, luckily for them its gonna take some time for ETSI/EU to harmonise the 6GHz band
<slh>
yeah, I'm just waiting for the ax9000 to become cheaper
<Ansuel>
slh 200€ i don't think it can go lower
<robimarko>
I doubt its gonna get cheaper
<slh>
well, I'm not in a hurry
<robimarko>
Its built like a tank compared to the AX3600
<slh>
and if not, the ax3600 will do ;)
<Ansuel>
anyway in theory if we really want to follow the offload path (by putting tons of effor and implementing our simplified version of nss) ram won't be a problem for both wifi and ath11k (but robi hate this path)
robimarko has quit [Quit: Page closed]
genuser1 has quit [Quit: Page closed]
<slh>
do you remember rough throughput figures for non-offloaded wired routing speed?
<Ansuel>
problem is shitty driver... so wired actually require offload or packets are dropped...
<slh>
grr
<Ansuel>
they really desined all with the use of nss primarly and give a broken switch with no nss
<Ansuel>
anyway time to go bb
Ansuel has quit [Quit: Probably my PC crashed or time to sleep.]
<digitalcircuit>
Finally getting back to OpenWRT debugging - making a custom build with "ccflags-y += -DDEBUG" in openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-11.2.0_musl_eabi/linux-5.10.72/drivers/mmc/core/Makefile, and "#define CONSOLE_LOGLEVEL_DEFAULT 10 //CONFIG_CONSOLE_LOGLEVEL_DEFAULT" in [...]/linux-5.10.72/include/linux/printk.h, to try to get more details.
<digitalcircuit>
(The kernel doesn't boot to the point of getting to specify debug level on the console, and I didn't want to risk OpenWRT potentially regenerating the kernel config, hence the hackish LOGLEVEL override.)
<digitalcircuit>
(Editing u-boot env args is another option, but if I'm custom-compiling anyways I figured I'd do it self-contained)
<dwfreed>
on the nbg6817, the kernel ignores the params passed by the bootloader
<dwfreed>
afaict, the only thing openwrt manipulates on the spi flash is the dual-boot flag indicating which partition to boot
<mangix>
so https://git.openwrt.org/?p=openwrt/staging/blogic.git;a=blob;f=target/linux/ipq806x/patches-4.9/900-net-dsa-make-the-slave-device-inheret-the-MAC-of-the.patch;h=d16a94931e209b71d2517fb74b102b401993194a;hb=dd3bdac6d1dcd98d4d494052f7df31ca21558d6f uses master/slave terminology
<mangix>
wonder how long before the language nazis remove it from the kernel
<mangix>
oh yeah. it's gonna happen.
<mangix>
There are around 19.5k mentions of "slave" within the kernel source tree, mostly within the kernel networking code. The string "master" is mentioned some 26.9k times. For "blacklist" are around 888 mentions when checking in the current Git tree.
<Tusker>
controller/willing servant ? :)
<mangix>
as an actual slav, I find the whole thing hillarious
<Tusker>
well... blacklist I don't mind them changing it. why have a colour dictate whether something is blocked or allowed...
<Tusker>
master/slave... that is the relationship so why change the words ?
<digitalcircuit>
dwfreed: Noted! That's a good point - I vaguely recalled something special about bootloader params for NBG6817, but I didn't realize they were all entirely ignored. Build from source is the proper way too, then :)
<mangix>
because there are actual language nazis that believe the words evoke certain feelings.
Andi_ has joined #openwrt-devel
<mangix>
it's just them though
<dwfreed>
digitalcircuit: I discovered this myself today when reading the wiki page for it
<dwfreed>
digitalcircuit: dmesg notes that the bootloader passed args are ignored
<Tusker>
the words should envoke feelings
<slh>
most device tree based targets override the bootloader cmdline
<slh>
in very many cases the bootloader provided one is just wrong/ problematic
<mangix>
Tusker: no feelings are evoked when I see master and slave
<dwfreed>
slh: in the nbg6817's case, changing the bootloader args is straightforward, at least
<mangix>
nor black and whitelist
<dwfreed>
the u-boot env is in the 0:APPSBLENV partition
<slh>
yep
<slh>
apart from the "what happens if you'd want to push-button tftp the OEM firmware again" (I know, ways around that are plenty
<dwfreed>
yeah, I've got images of my SPI flash now
<dwfreed>
will be useful in case I botch repartitioning the eMMC
<slh>
there's even bootloader based support for that, somehow
<dwfreed>
I'm just going to do it in two passes; currently booting off the secondary partition, so going to flash and boot the primary, then move and resize the secondary partition; flash and boot the secondary partition, then adjust the size of the primary partition
<dwfreed>
I will have to adjust the u-boot env to indicate the new kernel locations
<digitalcircuit>
Hmm. After a successful (non-booting due to MMC issue) normal build, I made the two changes above (added "ccflags-y += -DDEBUG" to openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-11.2.0_musl_eabi/linux-5.10.72/drivers/mmc/core/Makefile, changed CONSOLE_LOGLEVEL_DEFAULT to 10 in [...]/linux-5.10.72/include/linux/printk.h), then ran: make --jobs $(nproc) world
<dwfreed>
your client can with the appropriate script
<dwfreed>
but I doubt you want it to accept :q without prompting
<slh>
I'd already be happy if it would fetch/ filter out :q :q! :w :wq and :wq!
<mangix>
slh: lol. isn't that a client issue?
<mangix>
i use vi bindings on my shell. It's quite annoying
<slh>
mostly an issue between keyboard and chair - and admittedly KDE 5.23.0 not marking the active window explicitly enough
dangole has quit [Ping timeout: 480 seconds]
<slh>
pretty much no colour contrast between light grey and slightly less light grey
<mangix>
i'm used to the home key going to the beginning in my shell. enabling vi bindings does something else
<mangix>
quite annoying
<mangix>
that one hack rebinding caps lock to esc takes some getting used to.
<digitalcircuit>
slh: Thank you!
* digitalcircuit
starts a(nother) new build...
<slh>
no need to clean between those fix-up builds of the same revision, so that shouldn't take more than ~3-4 minutes
<digitalcircuit>
14m2.383s last time; my system's not quite as fast :)
<digitalcircuit>
(My full command is: time nice --adjustment=10 ionice --classdata 7 systemd-inhibit --who="OpenWRT build" --why="Compiling software" make --jobs $(nproc) world ; kdeconnect-cli-ping-status "OpenWRT partial build")
<Andi_>
by here it takes 1 ~ 2 minutes between builds
<digitalcircuit>
Noted! Hmm. I should probably set up ccache and/or find the build command to build the kernel only and make the image, not build the packages too ("world").
<digitalcircuit>
But given "dyndbg: unclosed quote: file", I need to get double quotes into the device tree bootargs = "stuff here" (already uses double quotes). It's correct during runtime (no error from... echo "file drivers/mmc/* +p" > /sys/kernel/debug/dynamic_debug/control).
* digitalcircuit
tries the classic "\"stuff\" other stuff"
hubvu has quit [Ping timeout: 480 seconds]
hubvu has joined #openwrt-devel
Andi_ has quit [Ping timeout: 480 seconds]
Andi_ has joined #openwrt-devel
<digitalcircuit>
I've gotten "Kernel command line: rootfstype=squashfs,ext4 rootwait noinitrd fstools_ignore_partname=1 dyndbg="file drivers/mmc/* +p" root=/dev/mmcblk0p5", but nothing new shows up. I'll have to continue looking tomorrow (haven't eaten, nearly 1 am here) :)
<digitalcircuit>
(No complaints, just.. no new MMC driver data. And dynamic debug is enabled.)
<digitalcircuit>
(Ah, there's a "dynamic_debug.verbose=1" to try)
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
nitroshift has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
nitroshift has joined #openwrt-devel
Grommish has joined #openwrt-devel
<Tusker>
ah ha... overriding Image/Prepare and then calling my make target, and then calling the appropriate real Image/Prepare/$1 seems to work to allow me to inject the dtb and kernel into the rootfs before mkfs
rmilecki has joined #openwrt-devel
Tapper has joined #openwrt-devel
goliath has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
bluew has quit [Remote host closed the connection]
<Grommish>
Anyone know anything about ujail throwing up SIGSEGV? Seems to be coming from dnsmasq. do_page_fault(): sending SIGSEGV to ujail for invalid read access from xxxx
<rsalvaterra>
mangix: Have you noticed/reproduced the ARP issue I'm seeing on your MT7621 device?
<rsalvaterra>
(I think it also happens on my Omnia, but I haven't used it in a while.)
goliath has joined #openwrt-devel
danitool has joined #openwrt-devel
dangole has joined #openwrt-devel
eduardo010174 has joined #openwrt-devel
<stintel>
Grommish: there have been some fixes to procd recently, are you running most recent version?
rua has quit [Quit: Leaving.]
<mangix>
rsalvaterra: I have no idea what this issue is
robimarko has joined #openwrt-devel
<robimarko>
digitalcircuit: Just set the log level to 10 using kernel_menuconfig
eduardo010174 has quit [Quit: Page closed]
pmelange has joined #openwrt-devel
eduardo010174 has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
eduardo010174 has left #openwrt-devel [#openwrt-devel]
pmelange1 has joined #openwrt-devel
pmelange has quit [Read error: Connection reset by peer]
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
Andi_ has quit [Ping timeout: 480 seconds]
Andi_ has joined #openwrt-devel
pmelange1 has quit [Ping timeout: 480 seconds]
eduardo010174 has joined #openwrt-devel
eduardo010174 has quit [Quit: Page closed]
robimarko has quit [Quit: Page closed]
<rsalvaterra>
mangix: Basically, ARP entries lingering in /proc/net/arp long after the devices disconnect (i.e., forever).
<stintel>
@daily reboot
* stintel
hides
<rsalvaterra>
This doesn't happen when flow_offloading_hw is enabled.
<rsalvaterra>
stintel: You're horrible. I like you. :P
<stintel>
:P
<rsalvaterra>
I believe I see this also on the Omnia and the Archer C6 v2, but haven't used them in a while.
<stintel>
what arch was this again?
<rsalvaterra>
I run a public AP, just for fun. People connect to it, disconnect, and the ARP entries stay forever. That's how I noticed the problem.
<rsalvaterra>
stintel: Right now, it's on my Redmi AC2100, MT7621.
<stintel>
hmmz, I don't use any ramips devices in L3 mode
<rsalvaterra>
No ARP for you, then. :P
<stintel>
what state are they in ?
<rsalvaterra>
FAILED
<stintel>
I do have one FAILED on my APU2 here in Belgium
<stintel>
ah but that's the printer being probed by observium every 5 minutes
rua has joined #openwrt-devel
<rsalvaterra>
If it's connected, should be fine. I believe I'm seeing an ARP ageing problem, but I can't be sure. This is networking, so I have no idea what I'm doing. :P
* rsalvaterra
hides
<stintel>
and on main router in Bulgaria it seems to be similar. I probably still have something configured trying to access some hosts on their old IP
<russell-->
rsalvaterra: how is it a problem?
<rsalvaterra>
russell--: You tell me… :)
<rsalvaterra>
Having a constantly growing number of ARP entries doesn't "feel" right. Is it a problem? I don't know.
<rsalvaterra>
I can imagine a malicious client connecting/disconnecting continuously with a random MAC. What would happen then?
<rsalvaterra>
(Sure, at a certain point the IP address pool would recycle, but still…)
<russell-->
i can tell you this isn't new
<rsalvaterra>
I'm not arguing that… :)
<russell-->
ip n | grep REACHABLE
<rsalvaterra>
russell--: I know, at the moment all my entries are either reacheable or stale, no problem there.
<Weissnix4711>
Hey, could someone review my new ramips device patch from a while ago? I kinda forgot about it myself lol.
<Weissnix4711>
Or should I resend it to the mailing list?
<PaulFertser>
Weissnix4711: resending would be odd in this case. I wonder if it would be polite enough to ask Adrian Schmutzler to review it, but he's not on IRC these days.
<PaulFertser>
Weissnix4711: hm, probably just send a regular e-mail to the mailing list "kindly asking" for review, and someone would pick it up probably.
<Weissnix4711>
Sure, I'll try that. Should I also send Adrian an email? Is he still a maintainer, or is he just not on IRC anymore?
<PaulFertser>
Weissnix4711: he's a rather busy maintainer, yes, IRC is not necessary to be one :) Not sure if he minds you pinging him via e-mail, I wouldn't recommend doing it, he reads all the mailing list postings so better just send to the mailing list I think.
<Weissnix4711>
kk, will do. Thanks
<PaulFertser>
Weissnix4711: thank you for contributing! BTW, I have some patches waiting for review too...
<hitech95>
Are qualcom fast path patches also acellerate LAN to WAN or it always goes trought the linux bridge interface?
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
genuser1 has quit [Quit: Page closed]
goliath has quit [Quit: SIGSEGV]
f00b4r0 has quit [Ping timeout: 480 seconds]
<hauke>
mangix: we would like to do 21.02.1 on Firday, is there anything in the package feed we have to take care of?
goliath has joined #openwrt-devel
<hauke>
mangix: I think a ksmbd update would be nice, they fixed some security problems recently
<mangix>
hauke: I'll set up a PR
<mangix>
I personally think ksmbd should be moved to base.
<mangix>
To avoid these update issues
<hauke>
mangix: we can also do this later
<hauke>
I think it is a good idea
valku1 has joined #openwrt-devel
valku has quit [Ping timeout: 480 seconds]
valku1 is now known as valku
dedeckeh has quit [Remote host closed the connection]
Guest3402 has joined #openwrt-devel
aparcar[m] has joined #openwrt-devel
bluse-blue[m] has joined #openwrt-devel
decke[m] has joined #openwrt-devel
evils[m]1 has joined #openwrt-devel
fieryeagle954[m] has joined #openwrt-devel
fpsusername[m] has joined #openwrt-devel
gnustomp[m] has joined #openwrt-devel
GuruPrasathGovindarajan[m] has joined #openwrt-devel
hexagonwin[m] has joined #openwrt-devel
John[m]12345678 has joined #openwrt-devel
JuniorJPDJ has joined #openwrt-devel
Q__ has joined #openwrt-devel
lipnitsk has joined #openwrt-devel
MatMaul[m] has joined #openwrt-devel
nick[m]1234 has joined #openwrt-devel
olmari has joined #openwrt-devel
pavlix has joined #openwrt-devel
ServerStatsDiscoverertraveler4 has joined #openwrt-devel
stintel[m] has joined #openwrt-devel
t4h4[m] has joined #openwrt-devel
MatrixTravelerbot[m] has joined #openwrt-devel
whatevs111[m] has joined #openwrt-devel
will[m] has joined #openwrt-devel
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #openwrt-devel
Andi_ has quit [Read error: Connection reset by peer]
Tapper has quit [Ping timeout: 480 seconds]
Andi_ has joined #openwrt-devel
<mangix>
hauke: PR posted
pmelange has left #openwrt-devel [#openwrt-devel]
<hauke>
mangix: thanks
<hauke>
dangole: mt76 is not able to probe the mt7915e on my Linksys E8450 (UBI) any more: https://pastebin.com/RSY4Npwi
<hauke>
do you know what is wrong there?
philipp64 has joined #openwrt-devel
dangole has quit [Ping timeout: 480 seconds]
goliath has quit [Quit: SIGSEGV]
Tapper has joined #openwrt-devel
valku has quit [Read error: Connection reset by peer]
valku has joined #openwrt-devel
ldir has quit [Quit: +++Divide by cucumber error+++]
ldir has joined #openwrt-devel
rmilecki has quit [Ping timeout: 480 seconds]
guidosarducci_ has joined #openwrt-devel
guidosarducci has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
guidosarducci_ is now known as guidosarducci
fda has quit [Ping timeout: 480 seconds]
rua has quit [Ping timeout: 480 seconds]
<PaulFertser>
hauke: certain (all?) units have the calibration data written to flash without ECC and the new flash driver doesn't ignore the ECC errors anymore, is that probably the case you see?
rua has joined #openwrt-devel
fda has joined #openwrt-devel
fda has quit [Ping timeout: 480 seconds]
fda has joined #openwrt-devel
<PaulFertser>
Both old and new driver can be used to reflash the calibration data partition.