**** BEGIN LOGGING AT Thu Feb 11 02:59:58 2016 Feb 11 03:05:31 florian r48689 trunk/include/kernel-defaults.mk * kernel: Revert "kernel: set root on NFS when enabled" Feb 11 03:20:20 build #201 of rb532 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/201 Feb 11 03:28:56 build #181 of x86.kvm_guest is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/x86.kvm_guest/builds/181 Feb 11 03:35:30 build #175 of avr32 is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/175 Feb 11 04:21:58 build #195 of brcm2708 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/brcm2708/builds/195 Feb 11 05:36:59 build #171 of ixp4xx is complete: Failure [failed svn shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/ixp4xx/builds/171 Feb 11 05:37:09 build #175 of kirkwood is complete: Failure [failed svn shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/kirkwood/builds/175 Feb 11 07:41:17 i've sent reworked patches for 4.5 to Kaloz, should I send them to someone else as well? Feb 11 07:49:12 build #179 of xburst is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/xburst/builds/179 Feb 11 08:24:52 nbd, ping Feb 11 08:26:22 nitroshift: pong Feb 11 08:27:13 nbd, can you please have a look at this: http://pastebin.com/VrznQwGS if you have time? Feb 11 08:28:23 build #161 of mpc83xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/mpc83xx/builds/161 Feb 11 08:28:38 nitroshift: looks like something that rmilecki touched Feb 11 08:28:55 thanks, i'll talk to him :) Feb 11 08:30:00 nbd, i've sent Kaloz the refreshed set of patches for 4.5 but i know he's over his head Feb 11 08:30:09 do you want me to send them to you too? Feb 11 08:32:57 rmilecki, are you around? Feb 11 08:34:15 right now i'm at a conference, not sure when i'll get around to taking a look Feb 11 08:34:19 but feel free to send them anyway Feb 11 08:34:41 :) Feb 11 08:35:20 build #160 of ep93xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ep93xx/builds/160 Feb 11 08:35:58 sent Feb 11 08:57:03 nitroshift: weird, checking it Feb 11 08:58:56 nitroshift: which kernel is it? Feb 11 09:00:55 nitroshift: please pastebin your build_dir/target-*/linux-*/linux-*/include/linux/mtd/partitions.h Feb 11 09:03:24 rmilecki, http://pastebin.com/YJJqwvgZ Feb 11 09:03:31 kernel 4.5 Feb 11 09:03:34 rc3 Feb 11 09:04:43 i think i found an error in partitions.h Feb 11 09:06:45 you didn't port patches correctly then Feb 11 09:07:13 excatly Feb 11 09:07:17 do better porting target/linux/generic/patches-4.4/4* patches from 4.4 to 4.5 Feb 11 09:07:19 *exactly Feb 11 09:07:22 ok Feb 11 09:07:28 working on it :) Feb 11 09:08:02 nitroshift: this patch adding that enum is oooold Feb 11 09:08:12 nitroshift: it worries me how you picked it Feb 11 09:08:17 should we remove it altogether? Feb 11 09:08:29 it's taken from patches-4.4 Feb 11 09:08:33 nitroshift: i'm afriad you may have other patches outdates as well, it could introduce some ugly to track regressions Feb 11 09:08:52 rmilecki, i'm working on a fresh git clone Feb 11 09:09:32 nitroshift: enum is added by target/linux/generic/patches-4.4/401-mtd-add-support-for-different-partition-parser-types.patch Feb 11 09:10:06 this enum is there since the day adding 4.4 support by Jonas Feb 11 09:10:09 how did you manage to miss it? Feb 11 09:10:32 i didn't Feb 11 09:10:41 401 patch is applied Feb 11 09:11:47 strange thing is that i don't have the structure from patch 4.2 @line 70 Feb 11 09:11:56 4.2 ---> 4.2 Feb 11 09:11:58 grrrr Feb 11 09:11:59 402 Feb 11 09:19:25 rmilecki, i didn't have in partitions.h the following lines: Feb 11 09:19:27 MTD_PARSER_TYPE_DEVICE = 0, Feb 11 09:19:27 + MTD_PARSER_TYPE_ROOTFS, Feb 11 09:19:27 + MTD_PARSER_TYPE_FIRMWARE, Feb 11 09:20:30 patched the file, building now Feb 11 09:45:31 nbd: nitroshift: what about doing cp -R patches-4.4 patches-4.5 and commiting it like that? Feb 11 09:45:39 nbd: nitroshift: then adjusting everything to 4.5 Feb 11 09:45:49 rmilecki, that's what i did Feb 11 09:45:51 that way we can see exactly was has changed, what was done Feb 11 09:46:07 otherwise noone will ever really review 4.5 patch Feb 11 09:46:27 build #220 of ipq806x is complete: Failure [failed shell_14] Build details are at http://buildbot.openwrt.org:8010/builders/ipq806x/builds/220 Feb 11 10:32:53 build #219 of ramips.rt3883 is complete: Failure [failed shell_14] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.rt3883/builds/219 Feb 11 10:35:19 build #217 of ramips.mt7628 is complete: Failure [failed shell_14] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7628/builds/217 Feb 11 10:39:40 rmilecki: to review that kind of upgrade, i usually do diff -ur patches-4.{4,5} Feb 11 10:39:46 so it should be fine Feb 11 10:40:12 build #220 of lantiq is complete: Failure [failed shell_14] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/220 Feb 11 10:41:29 ok Feb 11 10:55:01 build #197 of x86.xen_domu is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/x86.xen_domu/builds/197 Feb 11 10:57:19 rmilecki, i'm getting this now: http://pastebin.com/yMFeRwEi Feb 11 11:00:20 nitroshift: i don't indent to work on problems with porting patches to 4.5, sorry Feb 11 11:00:22 rmilecki, fair enough :) Feb 11 11:01:53 build #193 of netlogic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/netlogic/builds/193 Feb 11 11:04:22 build #153 of mpc52xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/153 Feb 11 11:54:40 build #159 of mvebu is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/mvebu/builds/159 Feb 11 12:47:25 I created a package that doesn't need compilation. How do override the default buildsystem behaviour? I defined an empty Package/$(PKG_NAME)/install, but it doesn't cut it. Feb 11 12:47:34 I * Feb 11 12:49:14 ah, big/small letter? Feb 11 12:49:36 grep found this: Feb 11 12:49:37 define Package/pianod-client/Compile Feb 11 12:49:39 endef Feb 11 12:49:41 define Package/pianod/install Feb 11 12:51:00 this is described on the creating packages page. it's all useful. Feb 11 12:51:12 woah Feb 11 12:51:16 qos-scripts is hosing ipv6 throughput Feb 11 13:00:49 build #163 of at91 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/163 Feb 11 13:17:58 mamarley, here? Feb 11 13:22:38 nyt: I will be in about 10min. Feb 11 13:24:03 k, im seeing ipv6 tunnel traffic severely impacted with qos-scripts running Feb 11 13:24:12 might be related to recent patch where you added v6 support Feb 11 13:24:25 qos-stop and my tunnel speeds go from 5 to 40 mbps Feb 11 13:24:26 bah tunneled IPv6 :( Feb 11 13:24:39 well i'd test native if i could :/ Feb 11 13:24:52 right. when I'm going back to my place I'll have tunneled as well Feb 11 13:24:53 dang Feb 11 13:35:17 build #158 of mpc85xx is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/mpc85xx/builds/158 Feb 11 13:45:38 nyt: What kind of tunnel? I am assuming there is a separate network device for the tunnel endpoint? Do you have the QoS rule on the physical adapter only or the virtual adapter for the tunnel too? Feb 11 13:45:57 qos only specified on wan Feb 11 13:46:01 henet tunnel Feb 11 13:46:03 6in4 Feb 11 13:46:32 lots of retransmits Feb 11 13:47:06 nyt: what kind of Internet access medium do you have? Feb 11 13:47:22 its cable, but not really relevant Feb 11 13:48:40 The first thing that comes to my mind is that one of the default rules is somehow classifying all the tunneled traffic as bulk or something, but I don't know the specifics of how the 6in4 mechanism works. Feb 11 13:48:54 i added rules to classify it as normal Feb 11 13:48:56 nyt: btw, don't you want to use sqm-scripts instead of qos-scripts? https://wiki.openwrt.org/doc/howto/sqm Feb 11 13:49:08 no? Feb 11 13:49:53 and that's completely irrelevant to the issue anyway Feb 11 13:50:14 nyt: Is there any output from sch_hfsc.c in dmesg? Feb 11 13:50:22 nah Feb 11 13:50:55 originally it was going throught he _ct table and not getting tagged at all Feb 11 13:50:59 i added a rule to tag it as normal Feb 11 13:51:10 (the proto 41 traffic) Feb 11 13:51:22 i completely cleared all of the ip6tables rules to test Feb 11 13:51:32 so proto 41 traffic was getting set as normal Feb 11 13:51:46 and i even jumped it out to accept in one of the early mangle tables Feb 11 13:52:25 nyt: my thinking was that some other scheduler might be able to do a better job than hsfc. Feb 11 13:52:34 hsfc does fine Feb 11 13:52:47 SwedeMike: qos-scripts is a combination of hfsc and fq_codel. Feb 11 13:52:59 i easily get 120mbps down with other qos'd traffic Feb 11 13:53:13 we're talking tunnel traffic dropping from like 40mbps to 5mbps with qos-scripts running lol Feb 11 13:53:29 i just dont have the time to dig into it further at the moment Feb 11 13:53:34 nyt: without any other traffic running, or when you're loading up the connection so it's full? Feb 11 13:53:44 without any other traffic Feb 11 13:53:50 im not retarded :/ i do this for a living Feb 11 13:54:09 nyt: I never said you were, but I had no idea how you did the testing. Feb 11 13:54:21 the line is barely utilized Feb 11 13:54:43 root@rooter:~# ifstat -i eth1 -b Feb 11 13:54:43 eth1 Feb 11 13:54:43 Kbps in Kbps out Feb 11 13:54:44 8.34 4.11 Feb 11 13:54:44 2.34 0.00 Feb 11 13:54:45 lol Feb 11 13:55:00 nyt: When you added the rule to classify the protocol 41 traffic, was that in iptables or ip6tables? Feb 11 13:55:07 iptables Feb 11 13:55:10 since its ip traffic Feb 11 13:56:05 I spent quite a lot of time with sqm-scripts, testing fq_codel, cake and pie. Are you CPU bound? Or do you see drops in the scheduler? your test traffic, is that TCP? Feb 11 13:56:08 i mean, even classified as bulk it shouldnt perform this poorly Feb 11 13:56:14 im not cpu bound Feb 11 13:56:16 x86 Feb 11 13:56:16 Indeed. Feb 11 13:57:16 valentt, ping Feb 11 13:57:28 I mean, the only reason to see traffic drop that much would be if there was a shaper that basically had no buffering at all and dropped packets very early in the process of buffering according to the shaper, basically sawtoothing TCP over time Feb 11 13:57:48 ipv4: [ 4] 0.00-3.00 sec 41.9 MBytes 117 Mbits/sec 4 sender Feb 11 13:57:59 ipv6 to same server: [ 4] 0.00-3.00 sec 2.05 MBytes 5.72 Mbits/sec 41 sender Feb 11 13:58:13 nyt: seeing a TCP stream graph of your traffic at both ends would be interesting when you see the low performance. Feb 11 13:58:27 (in wireshark) Feb 11 13:59:07 I have to admit I am not sure why this is happening, though I would suspect it is something inside the traffic shaper and is not related to ip(6)tables. Feb 11 14:00:11 most likely Feb 11 14:01:47 nyt: When you get a chance, could you try adding "protocol ip" back to the "tc" commands in /usr/lib/qos/generate.sh and /usr/lib/qos/tcrules.awk and see if that makes the problem go away? Feb 11 14:02:36 I expect it will, and if it does, there is one other thing I can try with tc that may work better. Feb 11 14:02:47 sec Feb 11 14:12:19 so, added the protocol ip back Feb 11 14:12:19 and Feb 11 14:12:23 1010 iptables -t mangle -I qos_Default_ct 4 -p 41 -m mark --mark 0x0/0xf -j MARK --set-xmark 0x22/0xff Feb 11 14:12:23 1022 iptables -t mangle -I qos_Default 4 -p 41 -j MARK --set-xmark 0x11/0xff Feb 11 14:13:09 cleared out ip6tables too Feb 11 14:13:22 still same low speeds Feb 11 14:14:29 hm might have horked one of the filter rules in tc sec Feb 11 14:15:18 nope Feb 11 14:15:44 Now that is really odd. Basically the only two things I did to add IPv6 support were to add the ip6tables rules (which we already decided weren't causing the problem) and remove "protocol ip" from the tc commands. Feb 11 14:15:50 yeah Feb 11 14:15:53 might have been before that patch Feb 11 14:16:15 How old was your installation before you upgraded it? Feb 11 14:16:32 its a new box :/ Feb 11 14:16:48 Oh... Feb 11 14:17:05 really weird tho Feb 11 14:17:52 nyt: Well, there is one other thing you can try. Go yank the generate.sh and tcrules.awk files from git from the revision before where I modified them and put them in your filesystem. Feb 11 14:18:43 where is qos-scripts Feb 11 14:19:08 entwork/config nm Feb 11 14:19:11 I can't look right now, but somewhere in packages/network/ Feb 11 14:19:23 Yeah, I was going to say config, but I couldn't remember for sure. Feb 11 14:20:53 Be very careful with the tcrules.awk file in particular. Even a small typo in that file could cause your connection to stop routing. (Ask me how I know.) Feb 11 14:22:11 yep even before that change Feb 11 14:22:22 qos-scripts just gripples tun traffic for some reason Feb 11 14:23:00 Sorry :( Feb 11 14:23:17 lots of retransmits / dropped packets Feb 11 14:23:20 are you sure that its not your provider doing some DPI / "QOS" on some tunneling protocols? Feb 11 14:23:21 ill dig into it more later Feb 11 14:23:27 .... Feb 11 14:23:31 qos-scripts stop Feb 11 14:23:36 speed jumps from 5 to 40 mbps Feb 11 14:23:39 so no, not provider Feb 11 14:23:42 ah k Feb 11 14:23:46 i even routed it over a tunnel earlier lol Feb 11 14:23:49 just to make sure Feb 11 15:00:22 nbd r48690 trunk/target/linux/generic/patches-4.3/645-bridge_multicast_to_unicast.patch * kernel: fix uninitialized variable in bridge multicast-to-unicast patch on 4.3 Feb 11 15:01:49 nbd r48691 trunk/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c * ag71xx: optimize icache footprint of the receive poll function Feb 11 15:01:56 nbd r48692 trunk/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx.h * ag71xx: increase tx ring size to improve performance Feb 11 15:02:02 nbd r48693 trunk/target/linux/ar71xx/files/drivers/ net/ethernet/atheros/ag71xx/ag71xx_main.c net/ethernet/atheros/ag71xx/ag71xx_ethtool.c net/ethernet/atheros/ag71xx/ag71xx.h * ag71xx: store ring size order instead of ring size to avoid div/mod Feb 11 15:02:09 nbd r48694 trunk/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx.h * ag71xx: increase rx ring size to improve performance Feb 11 15:30:53 build #155 of sunxi is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/sunxi/builds/155 Feb 11 17:09:33 When doing a 'make package/xyz/install' for a second time, is the build directory cleaned first? Feb 11 17:10:11 suppose I deleted a file from my package, would it be gone from the resulting image too, or do I need to call make clean? Feb 11 17:14:40 make package/xyz/{clean,install} does what you want I think. Feb 11 17:14:53 you don't want things autocleaned everytime, that would be too slow. Feb 11 17:18:52 karlp: I'm still seing my files in image root after cleaning the package. Only files from package build directory are gone. Feb 11 17:19:19 which would be fine, too, if only I knew how to clean image root just in case w/o cleaning packages Feb 11 17:21:12 This way make would only need to copy files into a new root, w/o compiling anything Feb 11 17:29:53 karlp: I had a go with inotifywatch and checked inodes, it looks like the image root is being deleted every time, just not when running package/*/clean. Feb 11 17:30:00 so it's alright Feb 11 17:30:04 karlp: thanks! Feb 11 20:52:44 has anyone tried using bluetooth ttl serial? Feb 11 20:52:53 i'm trying to get rid of some cables Feb 11 21:38:50 build #171 of lantiq.xrx200 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq.xrx200/builds/171 Feb 11 21:40:48 build #165 of au1000 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/au1000/builds/165 Feb 11 21:43:39 build #217 of orion is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/217 Feb 11 21:46:45 build #217 of cobalt is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/217 Feb 11 21:47:41 build #217 of cns21xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/cns21xx/builds/217 Feb 11 22:18:45 msgctl: you could try just something like rm -rf build_dir/target-xxx/root-xxxx ? Feb 11 22:48:40 nbd r48695 trunk/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_debugfs.c * ag71xx: fix build error with debugfs code Feb 12 00:34:06 build #162 of uml is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/162 Feb 12 00:37:52 build #214 of pxa is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/214 Feb 12 00:56:05 openwrt + bluetooth? like is there anyone using bluez inside this? or no one is using any bluetooth thingy? Feb 12 01:29:04 build #166 of ramips.rt305x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.rt305x/builds/166 Feb 12 01:36:10 build #152 of gemini is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/gemini/builds/152 Feb 12 01:45:21 build #166 of cns3xxx is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/cns3xxx/builds/166 Feb 12 02:23:36 build #162 of ath25 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ath25/builds/162 Feb 12 02:28:01 build #160 of ar71xx.mikrotik is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.mikrotik/builds/160 Feb 12 02:30:53 build #206 of ppc40x is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/206 **** ENDING LOGGING AT Fri Feb 12 02:59:58 2016