danitool has quit [Remote host closed the connection]
romany0 has joined #openwrt-devel
lmore377 has joined #openwrt-devel
SlimeyX has joined #openwrt-devel
minimal has quit [Quit: Leaving]
floof58 is now known as Guest4881
floof58 has joined #openwrt-devel
tersono has joined #openwrt-devel
Guest4881 has quit [Ping timeout: 480 seconds]
cmonroe has joined #openwrt-devel
rua has quit [Quit: Leaving.]
gch981213 has quit [Quit: Ping timeout (120 seconds)]
gch981213 has joined #openwrt-devel
rua has joined #openwrt-devel
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
isak has quit [Remote host closed the connection]
felix has quit []
felix has joined #openwrt-devel
tomn has quit [Remote host closed the connection]
tomn has joined #openwrt-devel
romany04 has joined #openwrt-devel
romany0 has quit [Ping timeout: 480 seconds]
romany04 is now known as romany0
<owrt-snap-builds> Build [#458](https://buildbot.openwrt.org/master/images/#builders/72/builds/458) of `imx/cortexa9` failed.
Mangix has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
Mangix has joined #openwrt-devel
<Znevna> morning
goliath has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
cbeznea has joined #openwrt-devel
goliath has joined #openwrt-devel
Tapper has joined #openwrt-devel
robimarko has joined #openwrt-devel
danitool has joined #openwrt-devel
<mrkiko> morning
xback has quit [Ping timeout: 480 seconds]
<oliv3r[m]> has something changed in the last few days, where builds have become super slow? I see a process running called 'faked' and instead of my normal 10 threads of cc1; I just see this single one. Builds are now taking about 10x as long as a result ...
<oliv3r[m]> seems to be (mostly) related to package generation it seems ...
<dwfreed> probably related
<oliv3r[m]> cool; but this is not merged yet is it? (I just pulled
<oliv3r[m]> probably need to distclean then
<oliv3r[m]> meh
<stintel> why?
<dwfreed> oliv3r[m]: that commit is in master
<stintel> make tools/fakeroot/clean ?
<oliv3r[m]> well this was merged; but it's still wrong
<oliv3r[m]> probably a good idea :D; but this is openwrt magic :p
<oliv3r[m]> but 'who knows what other packages are broken' atm :)
<robimarko> oliv3r[m]: Can you see if https://github.com/openwrt/openwrt/pull/11986 helps?
srslypascal has quit [Quit: Leaving]
srslypascal has joined #openwrt-devel
<oliv3r[m]> robimarko: seems to have been merged; so trying all of that now
<robimarko> oliv3r[m]: That PR was not merged
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
<robimarko> dhewg: Was it you that had the issue that disabling a radio does not work via LuCI?
<stintel> meh, tools container expects BUILDWORKER_NAME and BUILDWORKER_PASSWORD? not very usable for people to build in then
<rmilecki> nbd: i've finished testing your bgmac patches and threading support, it doesn't look good
<rmilecki> so with netifd's packet steering setup I was never able to reach more than 800 Mb/s
<rmilecki> (with bcm53xx specific packet steering I get 940 Mb/s)
<rmilecki> 1. Please note that speeds are very unstable with netifd's steering (high stdev)
<rmilecki> 2. It seems threaded NAPI helps a bit with netifd's packet steering
<rmilecki> 3. Threaded NAPI makes NAT way less stable with bcm53xx specific packet steering setup
<rmilecki> 4. bgmac_poll() and bgmac_dma_tx_add() changes usually have minimal effect
<rmilecki> 5. bgmac_poll() and bgmac_dma_tx_add() changes seem to slow OpenWrt 21.02 with threaded NAPI enabled (maybe kernel 5.4 is too old?)
<dhewg> robimarko: I think there was a issue about that, but not from me
<dhewg> But I see similar hiccups when yanking an usb wifi adapter at free will, some leftover state that's hard/weird to get rid of
<nbd> rmilecki: thanks for the test results
<nbd> i think the main issue is the fact that rps/xps is just too static
<nbd> when i have time, i will do some research to figure out if it's possible to replace it with a configurable set of network stack internal threads
<nbd> to allow more dynamic load balancing between cores
<rmilecki> nbd: https://pastebin.com/XfkZTgTT this is setup with netifd's steering + threading enabled
<nbd> what's eth1 and eth2. is it involved in your throughput test?
<rmilecki> they are unused
<nbd> ok
<rmilecki> switch port 5 goes to eth0, there are also unused switch port 7 (eth1) and port 8 (eth 2)
<nbd> so right now your bcm53xx specific rps script basically splits off parts of the network stack processing at a specific point to bounce it to a different cpu
<nbd> so i wonder if it might make sense to emulate that split with a separate thread
<nbd> making processing more dynamic based on cpu load
<rmilecki> nbd: i'm happy with any solution that can improve things
<rmilecki> nbd: right now that's the only way I managed to reach 940 Mb/s
<nbd> so i guess in the mean time we stick with something based on your '[PATCH] netifd: refactor packet steering' patch
<nbd> one thing that would be nice if you could change the patch to issue a procd trigger from the hotplug handler script
<nbd> so that procd can serialize calls to the init script
<nbd> with a timeout for merging events
<stintel> ah, could just override entrypoint probably
<rmilecki> nbd: sounds like a good idea with involvind procd
<rmilecki> i need to make some research on such trigger
<nbd> and i will let you know when i have a network stack patch for testing
<rmilecki> nbd: absolutely, please do
<dhewg> nbd: any idea about the a-msdu issue yet?
<nbd> dhewg: how big is the tpt regression?
<nbd> i tried to reproduce it, but it seems fine in my test
<dhewg> lemme revert that commit and compare directly, the sysupdate was a few weeks bump
<rmilecki> nbd: so I'm wondering if I should generate some custom event in hotplug.d/net/ script like: ubus call service event '{ "type": "net.added" }}'
<rmilecki> OR should I try to make /etc/init.d/packet_steering to listen to "net" hotplug.d events?
<dhewg> rmilecki: do you require low level device events?
<robimarko> dhewg: Ok, cause somebody asked me about it and I vaguely remembered you
<rmilecki> dhewg: i just need script to be called when net device appears
<rmilecki> dhewg: i have /etc/hotplug.d/net/20-smp-packet-steering which does only this: [ "$ACTION" = add ] && /lib/network/packet-steering.sh
<rmilecki> dhewg: but nbd pointed out I should use procd event instead
<dhewg> a net device as in uci "network interface"?
<rmilecki> let me verify what /etc/hotplug.d/net/ is actually
<oliv3r[m]> ugh; now what ... bash: line 3: /workdir/staging_dir/host/bin/usign: No such file or directory
<dhewg> rmilecki: iirc procd picks up subdirs in /etc/hotplug.d/, and you automatically get a hotplug.$dirname ubus object. you just need something to fire those events then
<dhewg> and I think "net" is just for uci "network interface", so "lan", "wan" etc
<dhewg> it doesn't provide hotplug for linux net devices as in "lo", "eth0" etc
<dhewg> if you want the latter maybe this helps: http://sprunge.us/xhWhUM
<rmilecki> dhewg: as for /etc/hotplug.d/net/ i'm confused, i expected it to be for L2 devices, after all we seem to have /etc/hotplug.d/iface/ which should be for L3
<rmilecki> dhewg: but it seems /etc/hotplug.d/net/ scripts get called for devices like eth0.1 too
<rmilecki> so i'm not sure anymore what's the difference between /etc/hotplug.d/net/ and /etc/hotplug.d/iface/
<dhewg> it's been a while, and I found it confusing too, which is why I added that patch
<dhewg> maybe that's solved already, but from what I remember I couldn't get any hotplug events for the devices I was interested in
<dhewg> that was about single DSA ports on master though
gromero_ has joined #openwrt-devel
<oliv3r[m]> so i did distclean; latest master; and this faked issue is still on master? or do I magically need to clean more?
<robimarko> oliv3r[m]: There were no changes after the commit that was linked
<robimarko> You can try that 1.31 PR out
tersono has quit [Quit: tersono]
<oliv3r[m]> ah, so that's not yet merged; right; i'll give it a ago
<oliv3r[m]> but am I the only one suffering from this?
<robimarko> Cant say I am noticing any slowdown
<oliv3r[m]> so that PR isn't helping :(
<oliv3r[m]> well my single core performance isn't amazing :p it's a FX8xxx :D so 'faked' is taking forever :( is there a way to disable it? i'm building everything as root (under docker) anyway
<stintel> you should never build as root
<stintel> not even in docker
<oliv3r[m]> well actually, the container is not running as root :p
<oliv3r[m]> and 'should' vs 'lazy' are two big things :D
<stintel> building as root causes problems
<stintel> don't do it
<oliv3r[m]> well don't worry, appearantly i don't :)
<oliv3r[m]> so i need faked; but why is its so ecruciatingly slow :( I used to be able to do a full build in < 5 minutes; now looks like 30 minutes :S
<mrkiko> robimarko: may I PM?
<robimarko> mrkiko: sure
cbeznea has quit [Quit: Leaving.]
cbeznea has joined #openwrt-devel
rua has quit [Remote host closed the connection]
Jonny[m] has quit [Quit: issued !quit command]
rua has joined #openwrt-devel
madwoota has quit [Read error: Connection reset by peer]
madwoota has joined #openwrt-devel
<nbd> rmilecki: i think you should use ubus call service event
<rmilecki> nbd: i used interface.*
<rmilecki> it's what 2 other scripts do
<rmilecki> and it seems to work
<nbd> which other scripts?
<rmilecki> nbd: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=601257e388d7abb5ada1c1ac93e2cd2259ea3dd1
<rmilecki> nbd: package/utils/busybox/files/sysntpd
<nbd> interface.* is not enough
<rmilecki> nbd: package/network/services/relayd/files/relay.init
<nbd> for relayd and sysntpd it is enough, but not for packet steering
<nbd> since devices can be hotplugged without corresponding changes in interface up/down status
<nbd> e.g. when devices are simply added to a bridge
<rmilecki> ah great ;/
<nbd> so interface.* works most of the time, but not all of the time
<rmilecki> every time I miss some procd bit, it's too hard for me to remember its details over time
<nbd> this is mostly a matter of device vs interface
<rmilecki> nbd: but since /etc/hotplug.d/net/ scripts are called based on procd events, I probably could use some proper one for init.d script, right?
<nbd> doesn't have that much to do with procd itself
minimal has joined #openwrt-devel
hanetzer1 has joined #openwrt-devel
hanetzer has quit [Ping timeout: 480 seconds]
<mrkiko> When I disabled cgroup memory controller support, build fails due to the kernel config asking if cgroup memory controller support should be included or not
raenye has joined #openwrt-devel
matoro has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<raenye> hello, I'm new to openwrt development and would like to attempt porting it to DAP-1620-B1 (mt7621at/mt7615dn)
<raenye> I was able to decrypt D-Link's firmware using information from GPL sources
<raenye> also got GPIO mapping and flash layout
<raenye> I can enter D-Link recovery mode, but still did not try to flash encrypted or decrypted firmware
<raenye> I partially disassembled the access point, so I have access to serial, but not to spi flash
hanetzer2 has joined #openwrt-devel
<raenye> still haven't soldered serial header, so no bootlogs yet
matoro has joined #openwrt-devel
hanetzer1 has quit [Ping timeout: 480 seconds]
<raenye> what would be a better approach?
<raenye> 1. add telnetd to the rootfs of the original firmware, repack and flash it
<raenye> 2. compile mt7621 kernel and boot it from serial
<raenye> 3. create a DTS based on a similar devices (e.g. DIR-853-R1) and put it the correct flash/gpio info
<raenye> I read the discussion about the older HW revision DAP-1620-A1, based on mt7620a.Seems most of the problems (e.g. getting the Realtek ethernet IC to do GbE instead of FE) are irrelevant
<raenye> Also read the discussion about DAP-X1860-A1, which is mt7621a/mt7915, but the HW manufacturer seems different (firmware there is a non-encrypted tar file)
<oliv3r[m]> wth is going on with master, getting Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 now too :S
<raenye> I also read about dbdc issues in the past. Were these resolved?
matoro has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
matoro has joined #openwrt-devel
isak has joined #openwrt-devel
<tmn505> raenye: I'm no ramips expert. Usually 1. get full flash dump, which usually means attaching UART and access to bootloader, 2. investigate recovery options (OEM recovery procedure or bootloader command-line), 3. initramfs boot prepared OpenWrt image (bootloader+tftp or vendor built-in procedure), until You have all bits figured out, 4. try to flash prepared image
<raenye> @tmn505 thanks. how do you get flash dump from UART? u-boot md?
<raenye> also, where could I read more about creating and loading initramfs images?
<raenye> FCC internal images show something I don't recognize on the back of the PCB, so I'm not sure if I could get access to flash chip at all
goliath has quit [Quit: SIGSEGV]
cbeznea has quit [Quit: Leaving.]
valku has joined #openwrt-devel
cbeznea has joined #openwrt-devel
<mrkiko> tmn505: how do you do when the bootloader doesn't allow a command to boot from ram?
<mrkiko> tmn505: i.e.: how would you do if confronted with a bootloader with no such nice thingslike tftpboot? Or am I missing something?
<tmn505> mrkiko: so there comes the second point, use OEM recovery or get shell access to vendor firmware and do full copy of flash and UART even if bootloader is locked could help getting any info what is actually ocuring.
<mrkiko> tmn505: clear, but was wondering if you then are forced to write to flash during development or if there other strategies
<tmn505> usually ODM has means to program the flash with chip vendor programming tools
<tmn505> raenye: yes usually md when in u-boot but if You have shell access, then it's faster using network
<tmn505> OpenWrt builds initramfs automatically so if U-Boot does not require any magic then it should boot without problems
<tmn505> that row of solder holes near the main chip on page 9 looks like uart
<tmn505> mrkiko: to elaborate on chip vendor tools, it could be external hardware programmer or software programmer attached to particular test points or pins which supports batch programming
floof58 has quit [Quit: floof58]
floof58 has joined #openwrt-devel
mcbridematt has quit [Remote host closed the connection]
<raenye> tmn505: indeed, they're Gnd-Tx-Rx-3V3. But I'm not sure about the beige thing on page 10
<tmn505> that looks like spi flash in some kind of socket I have never seen
<tmn505> other than that, I can't see any other chips which could be a flash IC
<mrkiko> tmn505: thanks
<stintel> looks like a surface mount socket ?
<stintel> should be really easy to remove the chip and read externally
<karlp> that clips not on your personal model in hand is it? jsut in the pics?
cmonroe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<tmn505> yeah, that's probably the case, on most devices I had there was no flash in socket even tough the fcc photos had them.
<oliv3r[m]> found one similar as that one on LCSC too; gotta order something soon-ish
goliath has joined #openwrt-devel
dansan has joined #openwrt-devel
raenye has quit [Remote host closed the connection]
raenye has joined #openwrt-devel
<robimarko> oliv3r[m]: I think your buildsystem is FUBAR-ed
<robimarko> Cause, I have built master today for multiple targets and I dont see any slowdowns or issues
<raenye> karlp: yep, FCC pics only. I opened just one side of the AP.
gromero has joined #openwrt-devel
gromero_ has quit [Ping timeout: 480 seconds]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
bluew has quit [Remote host closed the connection]
raenye has quit [Remote host closed the connection]
nwf has quit [Quit: WeeChat 2.8]
Borromini has joined #openwrt-devel
bluew has joined #openwrt-devel
xutaxkamay has quit [Read error: Connection reset by peer]
xutaxkamay has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
cbeznea has quit [Quit: Leaving.]
lucenera has quit [Quit: The Lounge - https://thelounge.chat]
lucenera has joined #openwrt-devel
tersono has joined #openwrt-devel
nwf has joined #openwrt-devel
raenye has joined #openwrt-devel
<raenye> opened the other side now (pesky plastic clips!). Good ol' MX25L12835F.
robimarko has quit [Quit: Leaving]
<raenye> Guess it's 50MHz as most similar SPI ICs are
mcbridematt has joined #openwrt-devel
raenye has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
Misanthropos has quit [Read error: Connection reset by peer]
bluew has quit [Quit: Leaving]
bluew has joined #openwrt-devel
<schmars[m]> it would be crazy helpful to have the output of scripts/dump-target-info.pl everywhere on downloads.openwrt.org
<schmars[m]> just occured to me :-)
Tapper has quit [Ping timeout: 480 seconds]
bbezak8 has joined #openwrt-devel
bbezak has quit [Ping timeout: 480 seconds]
Misanthropos has joined #openwrt-devel