<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 ...
<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
<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
<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>
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?
<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
<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