**** BEGIN LOGGING AT Fri Apr 05 02:59:57 2019 Apr 05 07:12:19 rmilecki: great work on tracking these perf issues btw. Apr 05 07:12:30 jow: thank you :) Apr 05 07:12:38 jow: it's nice to hear someone appreciating that! Apr 05 07:13:03 jow: I just send perf output (a minute ago), hopefully we know what to blame now Apr 05 07:13:06 *sent Apr 05 07:13:12 anyone an idea why memblock_alloc always returns zero at kernel? (BMIPS4350 / BCM3380 Docsis3.0 SoC) Apr 05 07:13:43 jow: i'm wondering if it's a matter of csum_partial() being slow on ARM or is there something specific in OpneWrt's network config that triggers kernel calling csum_partial() in the first place Apr 05 07:14:20 rmilecki: https://elixir.bootlin.com/linux/v4.19.33/ident/csum_partial Apr 05 07:14:29 rmilecki: it appears to have no dedicated ARM implementation Apr 05 07:14:55 I could well imagine that its fast on e.g. x86 due to the use of specific ASM (didn't yet actually look at the x86 lib implementaiton) Apr 05 07:15:22 https://elixir.bootlin.com/linux/v4.19.33/source/arch/x86/lib/csum-partial_64.c#L134 - this uses inline asm Apr 05 07:15:42 this not: https://elixir.bootlin.com/linux/v4.19.33/source/lib/checksum.c#L129 (which is likely used by arm) Apr 05 07:15:44 interesting Apr 05 07:16:55 Felix' com,ment on hw- vs. non-hw offload support makes sense too Apr 05 07:17:06 (but does hw offloading really apply to *partial* checksumming?) Apr 05 07:44:02 jow: in vlan_gro_receive() there is a call to the skb_gro_postpull_rcsum() it's worth checking that function: https://elixir.bootlin.com/linux/latest/source/include/linux/netdevice.h#L2715 Apr 05 07:44:15 it's updating csum only if it was valid before Apr 05 07:44:51 so maybe for devices with hw offloading csum_valid is false? and then csum_partial() is not called at all? Apr 05 08:01:12 ah Apr 05 08:01:44 reminds me of my patch for ag71xx that switched netif_receive_skb to napi_gro_receive. faster iperf but slower routing Apr 05 08:29:24 i'm adding support for a zyxel brcm63xx-based router, and when my initramfs boots i lose LAN connectivity. i suspect it's because the mac address isn't set properly. however i can't change it, i get "SIOCSIFHWADDR: Not supported" from ifconfig Apr 05 08:29:50 how to fix? Apr 05 08:34:48 donn_: you get that in response to what, exactly? Apr 05 08:35:20 ifconfig eth0 hw ether xx:xx:xx:xx:xx:xx Apr 05 08:36:02 does your eth0 show up in the boot messages (e.g. via dmesg)? Apr 05 08:37:11 yep Apr 05 08:37:39 when it boots i get this mac address "eth0 Link encap:Ethernet HWaddr 00:00:00:00:7E:B2" (snippet from ifconfig eth0) Apr 05 08:38:30 do you know what the macaddr is supposed to be (from a label on the case or from stock fw)? Apr 05 08:38:46 yes, it's shown when cfe starts Apr 05 08:39:24 have you tried looking through the flash partitions for that macaddr? on ramips it is in a "factory" flash partition. Apr 05 08:40:09 i'll have a look, but if i already know it, how does that help? Apr 05 08:41:00 on ramips, the dts points at the right offset to find the macaddr. i have no idea if that's why your network isn't working. Apr 05 08:41:27 ok, i made the dts myself, and didn't include such an entry (yet) Apr 05 08:42:00 i'll try to find the offset and then set that in the dts Apr 05 08:42:58 e.g.: Apr 05 08:43:06 ðernet { Apr 05 08:43:06 mtd-mac-address = <&factory 0x28>; Apr 05 08:43:06 }; Apr 05 08:43:29 that's from a ramips dts Apr 05 08:43:33 ok Apr 05 08:43:42 i don't have factory, but i have nvram Apr 05 08:44:27 also "customer" and "data", besides "rootfs" Apr 05 08:45:35 i don't see that in brcm63xx/dts ... Apr 05 08:46:04 nope, as i said i am adding support, so i made a new dts Apr 05 08:46:42 here's what i have in my dts https://pastebin.com/vsd1U08b Apr 05 08:46:50 no, i mean the mac-address stuff Apr 05 08:47:44 oh i see, you mean brcm63xx/dts doesn't support the mtd-mac-address stuff Apr 05 08:50:13 i don't know if it doesn't support it, but i don't see any other devices that are using it. Apr 05 08:50:33 ok i found the mac address at 0x6a0 in nvram Apr 05 08:51:16 * russell-- has zero experience with brcm63xx Apr 05 08:51:43 heh Apr 05 08:52:00 i've got the gpl'd source for this router, any idea where i'd look for this in there? Apr 05 08:53:33 you might do a grep -r mac target/linux/brcm63xx in the openwrt tree. there seem to be some relevant patches. Apr 05 08:54:34 ah yes, i see bcm63xx_enet Apr 05 08:54:37 thanks i'll browse Apr 05 08:54:54 btw what is the difference between bcm and brcm? Apr 05 08:56:03 donn_: one letter Apr 05 08:56:46 jow: it seems ARM has ASM code for csum_partial after all Apr 05 08:56:52 jow: LXR just can't find it Apr 05 08:57:03 jow: it's in the arch/arm/lib/csumpartial.S Apr 05 10:16:48 ynezz: will you further handle this one? https://git.openwrt.org/?p=openwrt/staging/xback.git;a=commit;h=6c8cfda23b0dc0d233b331cbcfbf5ab9457f55f6 Apr 05 10:18:01 xback: yeah, I could do this Apr 05 10:18:44 If you handle it, dont forget to change the state in patchwork too :) Apr 05 10:20:17 yep Apr 05 10:38:14 hey guys Apr 05 10:38:37 I just realized something the other day. Did you all know that OpenWRT has been in space? Apr 05 10:39:18 A board running OpenWRT went up on a Blue Origin rocket last May. I realized later that might be cool news, but I didn't think to mention it at the time. Apr 05 10:41:53 Anyway, lots of cool satcomm stuff happening with OpenWRT. Apr 05 10:42:10 hopefully not on ar71xx :) Apr 05 10:42:38 dansan: do you've some link with more details? Apr 05 10:43:49 lol! Apr 05 10:44:25 I can try to find the link about the launch and the internet company. It's the company I worked for and I asked if I could disclose it and my client told me yes Apr 05 10:44:30 *work Apr 05 10:45:00 When I talk to him tomorrow I'll ask if I can get more details to post to the list Apr 05 10:45:35 yeah, that would be great, thanks Apr 05 10:45:39 Oh, actually it was April: https://www.blueorigin.com/news/payload-customers-on-new-shepard-s-8th-test-flight Apr 05 10:46:02 I'm under NDA, so I have to be careful what I disclose w/o making sure it's not confidential! :) Apr 05 10:47:03 I know the board was an experimental variant of this MCG-101 https://www.gsat.us/products/mcg-101 Apr 05 10:47:30 lol, it made me think of that corrupted core from Portal 2 that's obsessed with going to space Apr 05 11:00:58 well, can't find any details about the used SOC/platform of mcg-101 Apr 05 11:46:57 There seems to be a recursive dependency in latest master: https://pastebin.com/S5bntML7 Apr 05 11:51:16 It was caused by f6aeed3 unbound: Make ECDSA support explicit Apr 05 11:54:20 I've just merged a PR fixing this. Apr 05 11:55:38 cotequeiroz: Thanks! that was fast :) Apr 05 11:55:48 i'll give it a quick spin Apr 05 11:56:09 I just tried to flash my DM200 with openwrt 18.06 (kernel 4.9) and the arp problem is still present (all the test i made before were done with branch master, kernel 4.14) Apr 05 11:56:52 with the newer gphy driver the problem persists, so i dont know if the problem is driver or kernel related Apr 05 11:58:39 is there a way to debug gphy drivers? or signal this bug to the producer? Apr 05 12:00:23 cotequeiroz: confirmed it's fixed. thanks again Apr 05 12:04:40 These recursive dependecies are hard to catch sometimes. It was caused by an unbound commit, and it wasn't even on your log. Apr 05 12:15:40 Does someone know how the DMA aka IUDMA on brcm63XX works? Apr 05 12:16:55 I've seen that it's used by both the USB and the Eth driver. So far I have seen that each drivers uses a different DMA controller. Apr 05 12:17:35 Also the PCM interface have this DMA and i'm working on a PCM driver so I would know how the DMA works. Apr 05 16:32:30 KanjiMoster: One more question regarding znc. Currently, -O2 is appended to CFLAGS, overriding our setting. Can I turn that off (./configure --disable-optimization), reducing size from 2352 to 1972? Apr 05 21:14:41 malwar3hun73r: Status -> Routes, look at IPv6 Neighbours Apr 05 21:14:57 whoops, wrong channel **** ENDING LOGGING AT Sat Apr 06 02:59:57 2019