**** BEGIN LOGGING AT Thu Jan 17 02:59:57 2019 Jan 17 03:05:34 build #286 of at91/sama5d2 is complete: Failure [failed targetupload] Build details are at http://phase1.builds.lede-project.org/builders/at91%2Fsama5d2/builds/286 blamelist: Hans Dedecker , Kevin Darbyshire-Bryant Jan 17 03:31:41 build #1094 of ramips/mt7620 is complete: Failure [failed targetupload] Build details are at http://phase1.builds.lede-project.org/builders/ramips%2Fmt7620/builds/1094 blamelist: Stijn Tintel , Hans Dedecker , Kevin Darbyshire-Bryant Jan 17 03:41:34 build #1124 of brcm63xx/smp is complete: Failure [failed kmodupload] Build details are at http://phase1.builds.lede-project.org/builders/brcm63xx%2Fsmp/builds/1124 blamelist: Hans Dedecker , Kevin Darbyshire-Bryant Jan 17 04:18:13 build #90 of ath79/nand is complete: Failure [failed targetupload] Build details are at http://phase1.builds.lede-project.org/builders/ath79%2Fnand/builds/90 blamelist: Stijn Tintel , Hans Dedecker Jan 17 05:28:19 zorun: I am routing. Jan 17 10:11:36 build #1099 of ramips/rt305x is complete: Failure [failed kmodupload] Build details are at http://phase1.builds.lede-project.org/builders/ramips%2Frt305x/builds/1099 blamelist: Stijn Tintel , Hans Dedecker Jan 17 10:12:40 [sender] io timeout after 121 seconds -- exiting Jan 17 10:12:46 broken hardware? Jan 17 11:50:10 regarding the macchiatobin, now I booted their hacked up 4.4.52 kernel with openwrt-dd to try that, and I get ~5 gigabit/s of forwarding using iperf3 with 10 sessions. 1 session yields marginally lower results. https://pastebin.com/NVgGYupP shows "cat /proc/interrupts" Jan 17 11:54:34 top shows 25% sirq which is consistent with all traffic hitting single core, which I guess is what the interrupts are showing as well Jan 17 11:56:04 maybe try installing irqbalance(d)? Jan 17 12:03:08 well, considering https://pastebin.com/MA4h3aLT "receive-hashing: off [fixed]" I'm not even sure it supports receive hashing? Jan 17 12:04:33 there are also lots of error messages such as "[ 1697.224004] eth1 selects TX queue 24, but real number of TX queues is 16 Jan 17 12:07:05 I changed the smp_affinity and then I can get 6 gigabit/s Jan 17 12:39:05 i have an issue with possible loop detection on modem connected to my rtn-56u with single eth0 device, separated to 3 vlans. As soon as i connect my ruter's vlan2 (wan pppoe) and vlan4 (port 4) to modem's ports 1 and 4, wan on my ruter is shut down due to loop detection in modem is presume, because modem stops to communicate on this port Jan 17 12:39:55 the current openwrt 18 snapshot mvpp2 with public drivers have working irq balancing, but doesn't support changing smp_affinity Jan 17 12:40:13 SwedeMike, o/ Jan 17 12:40:27 any results with clearfog? Jan 17 12:40:36 nitroshift: yes, that's what I'm rambling about above Jan 17 12:40:45 i just joined Jan 17 12:40:55 nitroshift: with the marvell hacked up 4.4 kernel I get approx twice the performance of the open drivers. Jan 17 12:41:14 I thought you said 4 vs 3.5, not twice? Jan 17 12:41:19 might be worth looking through their patches Jan 17 12:41:59 they should be on github Jan 17 12:43:05 i am pretty sure that somekind of a loop is detected on my modem, because if i change vlan4 port to tagged, then pppoe is kept connected, as all packets are discarded by the switch Jan 17 12:43:15 karlp: it depends on what I am doing, bidirectional traffic or not, parallel sessions etc. Jan 17 12:43:30 that's all my assumptions of course Jan 17 12:44:13 i have some unclear facts, that maybe some of you can clarify, for example: Jan 17 12:45:30 karlp: for instance if I am doing 10 A->B sessions and 10 B->A sessons through the device, I get ~1.7 gigabit/s each directon. This was quite a lot higher with the 4.4 proprietary version after I did some smp_affinity changes. Jan 17 12:45:57 I'll try that again just to be sure Jan 17 12:50:41 when i set switch_vlan port 4 to tagged (4t), no packets that don't have vlan tag 4 are ever received by the cpu, according to tcpdump. Does this mean that the packets are being dropped on hw level? Jan 17 12:51:29 karlp: I can get an aggregate of upwards 8 gigabit/s of traffic through it using the proprietary drivers with smp_affinity Jan 17 12:52:25 whereas with the open drivers I can't really get more than ~3.5 gigabit/s aggregate Jan 17 12:53:48 also with the proprietary drivers I can run iperf3 single session between the device and connected PC at basically full speed. That doesn't work with the open drivers, so I imagine some offloads are working much worse. Jan 17 12:54:16 [ 4] 0.00-10.00 sec 10.3 GBytes 8.81 Gbits/sec receiver Jan 17 12:56:08 [SUM] 0.00-10.00 sec 5.73 GBytes 4.92 Gbits/sec receiver with the open drivers. Above was with proprietary drivers Jan 17 12:57:18 what i want to achieve is have packets received by cpu port and then drop them, so i can have the cable stay connected and go from there. but is seems to me, that the loop is detected on the level i can't control Jan 17 12:57:35 SwedeMike, that's quite a difference Jan 17 13:08:31 is there a way to have complete control over a physical port on my rt-n56u, which has on physical eth0 with 5 ports separated to virtual vlans? Jan 17 14:00:03 build #1153 of lantiq/xrx200 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/lantiq%2Fxrx200/builds/1153 Jan 17 14:53:18 build #287 of at91/sama5d2 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/at91%2Fsama5d2/builds/287 Jan 17 15:06:36 ynezz: about the ARTIFACTS. I tried to enable it, but for some reason it is called always with last device name Jan 17 15:06:59 see https://pastebin.com/A0jFaQzY Jan 17 15:08:45 I enabled to every target to confirm that it is always last one. It can be seen from size of file that all u-boot's are sun50i-h5-orangepi-zero-plus ones Jan 17 15:13:10 build #1125 of brcm63xx/smp is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/brcm63xx%2Fsmp/builds/1125 Jan 17 15:14:17 quark_: ok, I'll look later into that, I might have probably screwed up something Jan 17 15:21:54 ynezz: thanks. I'm also trying look if found reason for that Jan 17 15:46:49 build #91 of ath79/nand is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/ath79%2Fnand/builds/91 Jan 17 16:44:06 quark_: can you please provide your cccccchdgggnhkfbhlhvlfifdlhjkfjuigfehllckjdluse case for ARTIFACTS ? Jan 17 16:44:23 damn yubikey, sorry Jan 17 16:45:38 if I'm seeing it correctly, it's currently used only in target/linux/apm821xx/image/Makefile and those files in snapshot builds look different size/checksum Jan 17 16:47:55 haha Jan 17 16:51:20 ynezz: it's that sunxi-uboot Jan 17 16:51:21 define Build/sunxi-uboot cp $(STAGING_DIR_IMAGE)/$(DEVICE_NAME)-u-boot-with-spl.bin $@ Jan 17 16:51:24 doh Jan 17 16:51:26 endef Jan 17 16:51:34 define Build/sunxi-uboot Jan 17 16:51:40 quark_: by inspecting the code, it's just doing `foreach artifact in ARTIFACTS; build_artifact($artifact); done` so I really don't see where it would get wrong filenames Jan 17 16:51:49 cp $(STAGING_DIR_IMAGE)/$(DEVICE_NAME)-u-boot-with-spl.bin $@ Jan 17 16:51:57 endef Jan 17 16:52:07 ARTIFACTS := u-boot-with-spl.bin Jan 17 16:52:07 ARTIFACT/u-boot-with-spl.bin := sunxi-uboot | check-size 896k Jan 17 16:52:38 ah, so it's probably bug in sunxi-uboot :) Jan 17 16:53:34 that $(DEVICE_NAME) does not contain correct info Jan 17 16:53:35 please provide complete makefile online, will look into it later, kids are calling :) Jan 17 16:54:08 quark_: yes, but that's not the problem of the ARTIFACTS probably Jan 17 16:54:27 but it works with IMAGES Jan 17 16:55:33 hmpf, ok Jan 17 16:56:01 but I'll provide whole makefile later. Now have to go for training Jan 17 17:05:04 ynezz: any further comment on pr# 1359 at this time? Jan 17 17:10:46 ynezz: https://pastebin.com/Ls4hW9KW that is target/linux/sunxi/image/Makefile. now I have to go Jan 17 18:45:41 DonkeyHotei: ar71xx is probably frozen and in fixes only mode, your patch is not trivial so it's very unlikely, that it's going to be merged, sorry Jan 17 18:46:48 anyway it's not forbidden, so if you're able to convince some of the maintainers (with proper real-world use case for example), it could still be merged Jan 17 18:48:40 and from the commit log of that `mtd: add CRC signature to RedBoot partition map` patch, I'm not able to understand which boards/platforms are affected righ or how did you find out about this issue Jan 17 18:50:21 if you still think, that it's useful and it should be included in the tree, then I would probably send it as separate patch to the mailing list and reword the patch subject to something like `mtd: Fix real world problem on xyz` to get some attention :) Jan 17 18:58:43 'lo Jan 17 19:24:49 o/ jow Jan 17 19:34:33 build #1095 of ramips/mt7620 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/ramips%2Fmt7620/builds/1095 Jan 17 19:41:29 ynezz: got it working by passing $(1) to uboot-sunxi. for some reason $(DEVICE_NAME) is not updated Jan 17 19:41:48 define Build/sunxi-uboot Jan 17 19:42:03 cp $(STAGING_DIR_IMAGE)/$(1)-u-boot-with-spl.bin $@ Jan 17 19:42:12 endef Jan 17 19:42:22 ARTIFACT/u-boot-with-spl.bin := sunxi-uboot $(1) | check-size 896k Jan 17 19:52:42 ynezz: and pr# 1379 ? Jan 17 20:31:41 how to add an image in openwrt.org wiki Jan 17 20:32:07 Sorry, you don't have enough rights to upload files. Jan 17 20:32:35 OK, I will upload to forum... and from there we will see Jan 17 20:35:38 not enough size for forum Jan 17 20:36:34 guifipedro[m]: /* How to add images ========> http://openwrt.org/meta/adding_images_to_openwrt_wiki */ Jan 17 20:38:12 guifipedro[m]: you need to pick the media namespace Jan 17 20:38:30 aha, I see Jan 17 20:42:29 cannot update my email in the wiki, are you using LDAP? ( This email is already associated with another user. ) Jan 17 20:43:45 wow, i just foud out that openwrt uses it's own port of opkg which uses cmake, which makes compiling a lot less shitty than friggin autohell Jan 17 21:00:52 _lore_: I managed to hose my Arch Linux setup. Testing the mt76 patch will take a while Jan 17 21:04:28 ah the case for rolling release ;) Jan 17 21:04:42 mangix: no snapshotting fs for your root? Jan 17 21:10:44 quark_: Can you please try https://github.com/ynezz/openwrt/commit/984b61a81d60f35d75b3851eade41e9976fff898 ? Jan 17 21:17:33 DonkeyHotei: I don't have any comments regarding pr#1379, so chunkeey should probably merge it once he gets up with merging mood :) Jan 17 21:17:42 thx Jan 17 21:18:06 does ar71xx still have designated maintainers? Jan 17 21:20:32 I don't think so as there is no MAINTAINER defined in target/linux/{ar71xx,ath79}/Makefile Jan 17 21:28:19 guifipedro[m]: no ldap, but github oauth Jan 17 21:28:37 mangix Borromini it's just arch i guess, no issue with rolling per se though Jan 17 21:29:02 DonkeyHotei: if you look at the git log for target/linux/ar71xx you'll see for yourself, that it's just trivial support for new devices like UniFi-AC-Mesh-Pro and TL-WA801NDv4 or fixes in the past 6+ months (or so) Jan 17 21:29:24 finally! fixed opkg to smoothly handle package upgrades in conjunction with my abi version changes Jan 17 21:30:59 Piraty: i've come to appreciate stable releases, i understand the temptation of bleeding edge though. until you cut your fingers one time too many. Jan 17 21:31:45 arch is just broken by not tracking shlibs and makes life hard because partial upgrades are not supported (because of not tracking shlibs via pacman) Jan 17 21:31:58 :) Jan 17 21:32:13 bleeding edge itself might not be a problem if you can safely roll back Jan 17 21:32:23 i do miss the simplicity of pacman compared to debian's tools, but it's been years since i used arch. Jan 17 21:33:34 as a debianaer who tried arch once to track down some bug; I absolutely hated pacman Jan 17 21:33:35 see void for example, which could (if they had more maintainers) be as bleeding edge as arch, but in case sth breaks you aren't out of luck breaking everything else by rolling back because the packagemager tells you what it needs for correct linkage. makes partial upgrades of sensitive systems also totally possible Jan 17 21:33:48 such an unintuitive selection of flags and ocmmand names Jan 17 21:33:53 yea Jan 17 21:34:03 well, debian has 3+ tools for the same job Jan 17 21:34:11 kinda useless Jan 17 21:34:19 I only ever used apt-get Jan 17 21:35:15 until today i don't even know which is the "recommended" one. debian's lifecycle is too slow for me Jan 17 21:35:41 i use a mix of dpkg, apt-get and aptitude... Jan 17 21:36:10 so yeah. at least i switched to pre-release buster now that things are being frozen :^) Jan 17 21:36:30 night gents. Jan 17 22:10:14 Piraty: in my case I managed to break bash by somehow removing libreadline Jan 17 22:10:35 haha Jan 17 22:10:43 during recent bash5 update? Jan 17 22:10:52 I guess Jan 17 22:11:08 actually, there was an update recently? Jan 17 22:11:10 arch at its best Jan 17 22:11:35 ooooohhhhh Jan 17 22:11:46 the old version was probably still loaded Jan 17 22:13:26 it seems the Turris people have invaded the packages feed Jan 17 22:33:07 <_lore_> mangix: which issue are you referring to? Jan 17 22:49:04 mangix: I think it is good that nic.cz contributes to OpenWrt Jan 17 23:49:19 _lore_: iommu Jan 17 23:49:38 Hauke: I do as well. **** ENDING LOGGING AT Fri Jan 18 02:59:57 2019