**** BEGIN LOGGING AT Wed Jan 16 02:59:56 2019 Jan 16 06:57:16 I wonder if we should simply drop 4MB flash support [in binary releases] completely after 19.01 Jan 16 06:57:59 as an owner of no such devices, I have no issue with that. Jan 16 06:58:00 alternatively, instead of dropping, prepare images that boot off usb by default for devices that happen to feature usb Jan 16 06:58:25 and only drop support for 4M devices without usb Jan 16 06:58:42 that's an interesting approach Jan 16 06:59:10 not sure of kexec is viable and stable on mips these days Jan 16 06:59:38 jow: FWIW, I've seen kexec related commits backported on kernel.org for MIPS Jan 16 06:59:54 so I would assume well Jan 16 07:06:57 need to try this eventually Jan 16 07:11:39 dropping luci from tiny targets might be a short term 'solution' Jan 16 07:12:31 (but that might change quickly with kernel 4.19, post 19.01) Jan 16 07:12:44 jow: speaking of pinging, I do request that this get looked at before branching: https://patchwork.ozlabs.org/patch/1019491/ Jan 16 08:09:21 morning Jan 16 08:09:37 any dev familiar with mvebu? Jan 16 08:09:44 came across this: https://github.com/MarvellEmbeddedProcessors/linux-marvell/commit/f68088d1eac6f4a7d5c7b18980c29e29c9017e42 Jan 16 08:09:58 and this: https://github.com/MarvellEmbeddedProcessors/linux-marvell/commit/8b0db552d8614888dfe278d311b89f33aa105870 Jan 16 08:12:47 don't know whether they apply to armada 385 or only to the newer soc's Jan 16 08:23:13 upon further searching here: https://wikidevi.com/wiki/Marvell they don't apply to armada 385, only to newer armada soc's Jan 16 08:31:00 <\x> oooooooooooooooooooo Jan 16 08:31:12 <\x> 2.5 Gbit? Jan 16 08:31:27 <\x> so, are these for the crab nics that are coming soon? Jan 16 08:34:47 \x, they are for the existing a37xx, a7k and a8k soc's Jan 16 08:35:19 such as the clearfog gt 8k Jan 16 08:41:17 <\x> hmmmmmmmmmmmmmmmmmmm Jan 16 08:41:29 oh, btw, I received my 8k Solidrun board last week. Jan 16 08:42:17 * nitroshift hates SwedeMike Jan 16 08:42:42 SwedeMike, did you get the board with RAM included? Jan 16 08:42:49 nitroshift: yes I did. Jan 16 08:42:52 nice Jan 16 08:43:05 i'm thinking of getting the one without ram Jan 16 08:43:18 nitroshift: in my testing so far the board doesn't do more than 4 gigabit/s of "openwrt forwarding". Jan 16 08:43:29 with large packets and a few TCP streams Jan 16 08:43:38 SwedeMike, even with flow offload enabled? Jan 16 08:43:55 nitroshift: yeah, I need to test that as well, I realised I had forgotten to click that. Jan 16 08:44:04 but I don't think it'll make a huge difference Jan 16 08:44:17 nitroshift: newer 64-bit mvebu Jan 16 08:44:22 has support for 2.5g Jan 16 08:44:30 this board needs DPDK, XDP or similar way of forwarding packets to really perform. Jan 16 08:45:03 heck, even a much higher clocked Intel x86 processor has problems doing 10GE using normal kernel forwarding Jan 16 08:45:07 SwedeMike, https://github.com/MarvellEmbeddedProcessors/dpdk-marvell Jan 16 08:45:47 nitroshift: yes, but I want openwrt. From what I know, there is no easy way to use DPDK forwarding in OpenWrt so that is used instead of the kernel. Jan 16 08:48:57 SwedeMike, correct Jan 16 08:52:34 would be interesting if someone did flowoffload with XDP. Jan 16 09:41:34 SwedeMike: regular not good enough? Jan 16 09:41:50 mangix: nope, 4 gigabit/s on a 10GE platform isn't enough Jan 16 09:42:06 irq bound? Jan 16 09:42:41 mangix: don't know, looks like one core is running 100% sirq Jan 16 09:43:37 hrm something like XDP is needed then Jan 16 09:44:03 mangix: yes, probably. Jan 16 09:44:23 quite unfortunate that the kernel is not up to the tast Jan 16 09:44:25 *task Jan 16 09:45:59 nitroshift: those commits were also upstreamed Jan 16 09:46:39 kernel 4.19 should be good for mvebu. a lot of improvements, especially for those 256MB linksys routers Jan 16 09:47:46 mangix, pr for 4.19 on mvebu is still open Jan 16 09:47:59 it's almost like people gave up using software routing decades ago for high speeds.... Jan 16 09:51:27 karlp: And started hiding it all in poorly documented partially functional hardware blocks? Jan 16 09:51:32 :) Jan 16 10:06:03 SwedeMike: does mvebu 10G driver support multiple queues and interrupts per nic? Jan 16 10:41:49 quark_: I don't know, I'm still investigating. Now for some reason I can't even make the thing boot properly. I had it working last week. Jan 16 10:55:20 I'm wondering how hard is it to get docs for that 8k SoC from Marwell, even under NDA Jan 16 11:12:59 ynezz: http://macchiatobin.net/product/macchiatobin-double-shot/ has quite a lot under board anyway. In my interaction with Marvell they've been pretty open about things, but I haven't requested any level of documentation for development purposes Jan 16 11:21:57 SwedeMike: another thing is what kind of tcp and ip offload driver supports. even modern x86 can handle only around 10Gbits TCP traffic with one CPU core Jan 16 11:22:15 if all nic offloads are disabled Jan 16 11:23:16 SwedeMike, you were lucky! I've requested the u-boot sources or the precompiled binary and was denied access Jan 16 11:27:56 SwedeMike: For you it might be a lot, but for me, there's nothing interesting at that link :) Well, having layout/schematic is nice Jan 16 11:29:19 quark_: most of the offloads are only used when device is the destination of the traffic, not in kernel routing mode. 8040 is perfectly capable of doing iperf3 at 10GE speeds. But when the kernel is used for routing then I only get 4 gigabit/s Jan 16 11:29:36 quark_: I get same difference on x86 btw Jan 16 11:35:26 SwedeMike: hmm. have to run couple of test to verify if that is the case in x86 side Jan 16 11:39:01 iperf3 is btw single thread. old iperf2 supports threads Jan 16 11:56:53 quark_: PC1 <-> ROUTER <-> PC2 if I run iperf3 between PC1 and ROUTER or between PC2 and ROUTER I get basically full 10GE speed. If I run iperf3 between PC1 and PC2 and ROUTER is either marvell 8040 or x86 machine running openwrt I get worse performance. Jan 16 11:59:31 nitroshift: http://wiki.macchiatobin.net/tiki-index.php?page=Build+from+source+-+Bootloader I haven't looked into the sources here, are they just binary blobs? Jan 16 12:03:07 SwedeMike, nope, they're source code Jan 16 12:04:42 the macchiatobin is kind of nice, it can boot uboot from sd card if you set the jumpers accordingly. Nice for unbricking :P Jan 16 12:05:05 now I managed to boot latest snapshot, I discoverd I forgot "rootwait" in the bootargs line Jan 16 12:05:29 so I'm going re-run my speed testing Jan 16 12:10:25 SwedeMike, macchiatobin is supported in mainline u-boot too Jan 16 12:10:47 make mvebu_mcbin-88f8040_defconfig Jan 16 12:33:11 build #1162 of kirkwood/generic is complete: Failure [failed targetupload] Build details are at http://phase1.builds.lede-project.org/builders/kirkwood%2Fgeneric/builds/1162 blamelist: Mathias Kresin Jan 16 12:35:53 is it possible to get my fritzbox 7320/7330 nd USB patch into the next release please? Jan 16 13:24:40 anyone else got weird linker errors for hostapd? something probably isn't all deterministic there: Jan 16 13:24:41 :(.text.ap_sta_add+0x19e): undefined reference to `sta_track_claim_taxonomy_info' Jan 16 13:24:41 collect2: error: ld returned 1 exit status Jan 16 13:25:29 (building hostapd-wpad-full-internal) Jan 16 13:40:45 regarding the macchiatobin performance with current snapshot, I'm getting around 2.5 gigabit/s of iperf3 running through it. Using 10 paralell TCP sessions brings it up to 3.3 gigabit/s. Running to the host itself doesn't yield much improvements. Jan 16 13:46:16 SwedeMike, what about running the "official" firmware? Jan 16 13:52:49 has anyone seen the following in dmesg on lantiq devices? Jan 16 13:52:51 [709739.855248] ltq_etop 1e180000.etop eth0: tx ring full Jan 16 14:18:41 it seems to happen under load and breaks all connectivity Jan 16 14:19:09 lan, wan, wifi Jan 16 14:19:54 have to restart lan to get it working again Jan 16 14:21:49 nitroshift: that's what I am going to do now. On the other 8040 platform I have I did get 10GE speed to the box itself. Jan 16 14:21:59 so I need to try the same thing on the macchiatobin Jan 16 15:47:45 stintel: ping - just pushed an update to dnsmasq that I'm wondering if relevant to your strange & intermittent 'won't give me a dhcp lease' problem. Jan 16 15:49:59 ldir: thanks for the heads-up Jan 16 15:50:26 still at work and cooking for a visitor after, probably have to check later Jan 16 15:50:38 although it would be epic if that issue would be resolved =) Jan 16 15:50:46 stintel: http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=18eac67c0a15b673c8d27002c248651b308093e4 Jan 16 15:52:14 interesting Jan 16 15:53:17 yeah - you can see why I thought of your problem when I saw the patch description. Certainly something that needs to be fixed, hence the push. Jan 16 15:54:46 might explain the other net thing Jan 16 15:56:57 so your client boots, gets an ipv4 address, then gets ipv6 via odhcpd, which kicks dnsmasq, which re-reads the hosts file and then partially loses track of the ipv4 lease.... then your client renews the ipv4 and it all goes....a bit mental. It's a theory/guess at this stage :-) Jan 16 15:59:16 so I quit early today (have some overtime from last days and week :)) Jan 16 15:59:19 let me try that stuff Jan 16 15:59:38 lol - it's not *that* important :-) Jan 16 16:00:12 it is for me :P Jan 16 16:00:33 I get mad when there is suddenly 2 weeks of missing stats in my monitoring from the printer that changed its IP ;) Jan 16 16:03:54 ldir: building :) Jan 16 16:04:22 I just hope you don't shout at me if it doesn't solve it Jan 16 16:08:25 ldir: I won't :) Jan 16 16:08:34 really appreciate the heads-up Jan 16 16:25:56 sigh, of course I'm having a build failure now :P Jan 16 16:31:17 random failure that no longer occurs when running make again Jan 16 16:31:31 alright, flashing Jan 16 16:31:37 now grocery shopping Jan 16 17:16:03 ldir: well bloody hell, it actually looks good! Jan 16 17:16:44 resume laptop from suspend, previous IP yesterday was .190 (dynamic), now .12 (the static lease) Jan 16 17:16:50 !ldir++ Jan 16 17:17:35 well let's wait a little while longer before getting out the champagne Jan 16 17:18:31 build #1098 of ramips/rt305x is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/ramips%2Frt305x/builds/1098 Jan 16 17:19:18 it's something I'd never have thought of! Jan 16 17:36:39 Assuming nothing else falls out of the latest fixes, this should be cherry-picked for 18.06 after a couple of days. Jan 16 17:40:24 hah, forgot to buy champagne! Jan 16 17:40:26 damnit Jan 16 17:44:25 lol Jan 16 17:52:03 build #272 of gemini/generic is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/gemini%2Fgeneric/builds/272 Jan 16 18:05:49 build #828 of ramips/mt76x8 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/ramips%2Fmt76x8/builds/828 Jan 16 18:21:47 anyone have a PS4 and also running CT ath10k firmware? Jan 16 18:48:00 greearb_: are you here? Jan 16 18:48:27 greearb_: if so, i set luci to this when i did the packets, how can i be sure it's set to capture in 80mhz and if not, how can i set it manually? Jan 16 18:50:34 greearb_: https://imgur.com/a/Boxnntg Jan 16 18:52:14 I'm here, and not sure how to do that in luci unfortunately Jan 16 18:52:31 greearb_: nevermind, i figured it out :) Jan 16 18:52:33 let me try again Jan 16 18:52:48 greearb_: also let me stress : you need a ps4 pro, a stock/slim ps4 doesn't support 5Ghz Jan 16 18:53:46 iw has ways to set it manually, google around for sniffing in monitor mode...make sure you see some frames in wireshark that are 40Mhz or 80Mhz Jan 16 18:54:05 iw wlan0 set freq 5180 80 5210 is what i needed Jan 16 18:55:16 ok, another co-worker has ps4-pro and will try to bring it tomorrow so we can test Jan 16 18:55:23 let me get those captures for you quick as well :) Jan 16 18:55:29 sure thing Jan 16 19:01:33 woah, 40mb Jan 16 19:08:48 greearb_: https://cloud.movishell.pl/s/iixBg58waknZYZP enjoy :) Jan 16 20:09:06 SwedeMike: I made quick test inside KVM. C1 -> R1 -> R2 -> C2. All those are openwrt 18.06.1 images 2vCPU, 1G RAM. Jan 16 20:09:36 direct iperf between R1 and R2 around 20Gbits Jan 16 20:09:53 iperf between C1 and C2 13Gbits Jan 16 20:10:56 SwedeMike: are you briding or routing on the macchiatobin? Jan 16 20:14:28 and that was with one nic queue. no nat just plain routing between lan and wan. I'll try add second queue to every VM to see if performance doubles. Jan 16 20:30:41 last time I did performance testing with VMs, forwarding TCP was *much* faster than forwarding UDP Jan 16 20:31:37 it was a different setup though: physical machine 1 <--> VM on physical machine 2 <--> physical machine 3 Jan 16 20:32:00 so the NICs on physical machine 2 probably had something to do with the result Jan 17 00:14:05 build #1163 of kirkwood/generic is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/kirkwood%2Fgeneric/builds/1163 Jan 17 02:23:08 build #1152 of lantiq/xrx200 is complete: Failure [failed kmodupload] Build details are at http://phase1.builds.lede-project.org/builders/lantiq%2Fxrx200/builds/1152 blamelist: Hans Dedecker , Kevin Darbyshire-Bryant **** ENDING LOGGING AT Thu Jan 17 02:59:57 2019