**** BEGIN LOGGING AT Thu Oct 23 03:00:00 2014 Oct 23 04:33:17 build #677 of ar71xx is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/677 Oct 23 07:14:55 I fear http://wiki.openwrt.org/doc/howto/hardware.button is horribly outdated and wrong - how do you hook linux input events (ie a button press) to a script? Oct 23 07:36:18 tharvey: you can search git / codebase - https://dev.openwrt.org/log/trunk/package/base-files/files/etc/rc.button might have some infos / changelogs regarding buttons - or you ask on the mailing list Oct 23 10:10:35 is there a way to resemble that with procd Oct 23 10:10:38 i have a init script that is pre procd, it basically uses inotifyd to check if /dev/tty* is created and than spawns a process using this device, so if there are tow /dev/tty* changes two processes are spawned Oct 23 10:23:43 build #725 of ppc44x is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/725 Oct 23 13:14:02 jow_laptop: have you ever seen anything like this? http://imgur.com/a/BagJD Oct 23 13:14:26 I get strange header mixups with uhttpd and chromium, and I've got no idea why Oct 23 13:16:28 I haven't ever seen it on any apges but my own, but I don't look at the main status pages much, I tend to assume they just work. Oct 23 13:17:55 it's like uhttpd takes too long to reply and chromum just makes up smething and assumes it's text/plain somehow? Oct 23 13:19:24 I've even seen it happening with images :| Oct 23 13:19:37 karlp: the odd part is the "0" at the top of the response.. that's the end of the previous chunked response Oct 23 13:20:05 yeah, I know, somethings all screwy, and I've no idea why Oct 23 13:20:15 i'd be curious to see what the previous request looks like, and why chromium thinks it ended early Oct 23 13:20:17 I'm not having much luck working out the right way of googling it either. Oct 23 13:20:35 and I can't trigger it reliably so I can't get a clean wireshark trace Oct 23 13:22:39 is there any official way to make the tmpfs partition smaller, since block-mount can't detect tmpfs i no short of adding an init script for that purpose Oct 23 13:24:16 karlp: ok, the other weird thing in your screenshot... why is it sending a Content-Length header if it's chunked encoding Oct 23 13:26:02 Voltara: no clue, Oct 23 13:26:25 maybe that's a normal thing, but maybe it's also a clue as to how chromium is getting confused Oct 23 13:27:31 the other hting is, when it works, the page loads very quickly. Oct 23 13:27:38 when it failes, it takes ~20seconds Oct 23 13:28:16 20 seconds, that's also the keepalive timeout that luci sends Oct 23 13:29:41 i'm guessing wireshark will be important to diagnosing it Oct 23 13:31:29 the confusing thing is that the data is there in the end. Oct 23 13:34:18 nbd r43033 trunk/package/kernel/mac80211/patches/343-ath10k-add-SURVEY_INFO_IN_USE-for-current-channel-on.patch * ath10k: fix survey output channel in-use flag Oct 23 13:34:24 nbd r43034 trunk/package/kernel/mac80211/patches/402-ath_regd_optional.patch * ath: process regulatory notifiers with CONFIG_ATH_USER_REGD set Oct 23 13:39:46 karlp: try disabling keepalive Oct 23 13:40:42 -k 0 on the uhttpd command line? Oct 23 13:42:05 that does seem to work. Oct 23 13:44:50 is that a bug in my scripts? or what? why would I have only started seeing this in the last few weeks? Oct 23 13:45:05 (this is probably about the time I switched form AA to BB, but I couldn't say for sure on that) Oct 23 13:46:12 if i want to add a script that runs only on the first boot where could i add it, something like /etc/uci-defaults ? Oct 23 13:47:00 or should i simply add an initscript that will delete itself after first time run ? Oct 23 13:51:34 ok i just throw it in uci-defaults Oct 23 14:00:57 karlp: most likely a bug in uhttpd/ustream Oct 23 14:04:17 I don't know how to trigger it, so I don't know what sort of bug report I could file, if you even want one Oct 23 14:04:52 well I guess the server side state gets confused Oct 23 14:05:01 http keepalive is a minefield Oct 23 14:05:22 lots of bugs in clients that in turn have workarounds on the server breaking other clients that work around them... Oct 23 14:05:48 also, sorry about that uhttpd mimetypes patch ending up as two emails, I was just trying to edit the subject line to include uhttpd, but to have the patch still just say mimetypes for the uhttpd2 repo. Oct 23 14:08:10 what does ustream do? is that how you plug ssl into uhttpd? Oct 23 14:10:28 ah, uhttpd1 didn't do keepalives, Oct 23 14:15:07 ustream is a kind of dynamic buffer / socket / fd abstraction library Oct 23 14:15:34 you can like sprintf() into a ustream socket object and its flushed blockwise behind the scenes Oct 23 14:15:35 goes with ubox+uloop then I take it? Oct 23 14:15:41 driven by uloop, yes Oct 23 14:16:42 these all came out as libevent2 was too big? or you just wanted things that it wasn't doing, and didn't need to support windows so it could be chopped? Oct 23 14:17:44 uhttpd2 was mainly built by nbd, and he decided to create ustream Oct 23 14:18:36 was there someting broken in uhttpd1 that I didn't notice? Oct 23 14:18:42 also given that libevent2 is 3x the size of uhttpd Oct 23 14:19:03 uhttpd1 was really easy to DoS Oct 23 14:19:12 due to its architecture Oct 23 14:20:24 fair enough then :) Oct 23 14:54:21 build #771 of orion is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/771 Oct 23 14:57:00 build #694 of sibyte is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/694 Oct 23 15:17:10 I fear http://wiki.openwrt.org/doc/howto/hardware.button is horribly outdated and wrong - how do you hook linux input events (ie a button press) to a script? Oct 23 15:25:00 karlp: if you don't mind sharing a pcap of the http issue, I could take a look.. I have BB but haven't seen any issues so far with Chromium Oct 23 15:26:45 Voltara: is keepalive enabled in your uhttpd2 install? Oct 23 15:26:49 Voltara: iirc its off by default Oct 23 15:29:18 jow_laptop: is uhttpd2 the default httpd in BB? whatever came pre-installed is doing keepalive, and i didn't touch the configs Oct 23 15:29:31 ok Oct 23 15:29:34 yeah its default Oct 23 15:29:53 it's 20 sec on by default. Oct 23 15:29:56 it could be that the keepalive stuff gets out of sync under specific circumstances (aborted request, failed request) Oct 23 15:30:11 I assume you do a lot of ajax polling Oct 23 15:30:18 yeah, plus websockets Oct 23 15:30:30 well, not a lot of ajax these days actually, it's being replaced byt he websockets Oct 23 15:34:58 http://paste.fedoraproject.org/144623/78469141/ by itself is failing. Oct 23 15:35:49 interesting Oct 23 15:36:07 whats the filesize? Oct 23 15:36:20 I mean of the rendered template Oct 23 15:37:34 http://palmtree.beeroclock.net/~karlp/uhttpd2-keepalive-issue.pcapng is the pcap if it's useufl. Oct 23 15:38:37 where should I get the filesize of the rendered template from? I can get the source from chroimum? Oct 23 15:39:35 4.3kb from the "network" tab in chromie dev toosl Oct 23 15:41:19 in that pcapng, the jquery-migrate and mqttws.js both failed Oct 23 15:41:50 is the footer.htm really ending with three newlines? Oct 23 15:42:05 four Oct 23 15:42:19 karlp: when you say 'failed', do you mean chromium gives the first line of the response as "0" ? Oct 23 15:43:04 Voltara: I mean it takes 20seconds to reply, and chroimum treates the headers as content, and the mimetype as text/plain instead of the correct ones. Oct 23 15:45:17 karlp: hm, the 2nd response in your pcap is a 304 with content-length: 0 and an empty http chunk trailer Oct 23 15:45:18 http://paste.fedoraproject.org/144629/14079106/ is footer.htm Oct 23 15:45:20 hmm so both of the URLs that 'failed' are followed immediately by a 304 NotMod Oct 23 15:45:23 karlp: thats likely whats confusing chrome Oct 23 15:45:34 let me remove the lines there, and see if does anything. Oct 23 15:45:38 so.. is a '304' supposed to even have a response body Oct 23 15:45:45 Voltara: likely not Oct 23 15:46:11 I don't think we actually touched the footer from the bootstrap theme Oct 23 15:46:42 https://github.com/joyent/node/issues/4437 Oct 23 15:47:00 at least we're not the first to trip over that technicality :-) Oct 23 15:47:34 http://palmtree.beeroclock.net/~karlp/uhttpd-example-fail.png is what I mean by "fail" Oct 23 15:48:45 removing the blank lines in the footer template doesn't help Oct 23 15:49:41 build #706 of avr32 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/706 Oct 23 15:54:41 http://paste.fedoraproject.org/144635/14140796/ is an even simpler failing page. Oct 23 16:02:34 karlp: http://pastebin.com/x0DEpeYM Oct 23 16:02:37 karlp: try this please Oct 23 16:02:51 moment Oct 23 16:03:38 nvm, try the one I pasted Oct 23 16:03:41 jow_laptop: should you maybe move the http_code check into uh_use_chunked, to prevent the "Transfer-Encoding: chunked" header from being sent either? Oct 23 16:03:58 Voltara: good idea Oct 23 16:05:05 (just worried that some browsers might expect to see the "0\r\n" if they get "T-E: chunked") Oct 23 16:05:42 karlp: that one: http://pastebin.com/yX9prTTQ Oct 23 16:05:48 its untested, not even compile tested Oct 23 16:05:56 let me know if it works and I'll clean it up Oct 23 16:06:11 I'd like to get rid of the superfluous "Content-Length: 0" too Oct 23 16:08:42 bbl Oct 23 16:14:50 jow_laptop: since you're going to touch Content-Length anyway, looks like RFC2616 declares it a "MUST NOT" to send Content-Length if you're doing chunked Oct 23 16:16:18 jow_laptop: http://tools.ietf.org/html/rfc2616#section-4.4 Oct 23 16:17:39 that seems to work well. Oct 23 19:20:53 Hauke: how can we add support for R7000/R8000? they use BCM4709 Oct 23 19:21:06 i think BCM4709 is quite identical to BCM4708 from our POV Oct 23 19:21:15 hi Oct 23 19:21:21 should we create new DTS file for bcm4709? Oct 23 19:21:22 zajec: what's different? Oct 23 19:21:28 i don't know really Oct 23 19:21:54 CPU speed? Oct 23 19:22:03 800 MHz -> 1000 MHz? Oct 23 19:22:42 BCM47081 was worth separated file, because it has one core only Oct 23 19:22:58 broadcom knows how to name their chips :P Oct 23 19:23:39 zajec: I created the arch/arm/boot/dts/bcm4708.dtsi because theer are some SoCs with just one CPU core Oct 23 19:23:44 Devastator: yeah, there is such a small difference between BCM4706 and BCM4708/BCM4708.... :p Oct 23 19:23:51 Hauke: right Oct 23 19:23:58 Hauke: that's why I created bcm47081.dts :) Oct 23 19:24:15 I would create a new one Oct 23 19:24:31 even if identical to bcm4708.dts so far? Oct 23 19:24:48 create bcm470x.dtsi? Oct 23 19:25:21 cp bcm4708.dtsi bcm4709.dtsi Oct 23 19:25:24 the arm guys do not like something with a var in the name Oct 23 19:25:27 s/bcm4708/bcm4709/ Oct 23 19:26:04 i don't have any opinon, i'm find with every solution :) Oct 23 19:26:13 but on the other hand we could add that when we find any differences Oct 23 19:26:36 and use bcm4708.dtsi till we need something different Oct 23 19:26:45 Hauke: so should I use compatible=brcm,bcm4708 on bcm4709 devices? Oct 23 19:26:51 or should i add new compatiblity string? Oct 23 19:26:57 the bcm4709.dtsi would be a one to one copy Oct 23 19:27:40 the compatible should be something like this: compatible = "netgear,r7000v1", "brcm,bcm4709", "brcm,bcm4708"; Oct 23 19:27:48 ok Oct 23 19:27:50 thanks Oct 23 19:28:33 so if we find anything special for bcm4709 we can add support for that later without changing dts file Oct 23 19:29:08 clever :) Oct 23 19:29:37 dts is considered api, so we should be compatible to any dts file we ever supported Oct 23 19:30:35 in practical this is not important for bcm47xx as nobody includes the dts file into the boot loader as far as I know Oct 23 20:12:49 there seems to be an error in iwinfo’s handling of tx power offset Oct 23 20:13:49 it’s regarding a set of ubiquity SR71 cards that have a 7dB offset, about which a lot has been written in the past and many mistakes made Oct 23 20:14:45 “iwinfo wlan0 txpowerlist” always lists 7dB more than is allowed according to regulatory settings Oct 23 20:15:15 for isntance in europe on 2.4GHz band max tx power is 20dBm, and iwinfo lists up to 27 dBm Oct 23 20:16:52 when actually setting the power to 27 dBm, the real measured output power is close to 20 dBm Oct 23 20:17:40 so it seems that the 7 dB offset is accounted for twice in the output that luci uses for display on the website Oct 23 20:18:08 btw… I’m using 14.07 on AR71xx Oct 23 20:19:23 does anyone else have the same problems? a quick fix? or should I put this on the mailing list? Oct 23 20:21:42 vanDrunen: iirc, there was a commit about this yesterday Oct 23 20:22:04 ath9k: fix tx power reporting Oct 23 20:22:09 git-svn-id: svn://svn.openwrt.org/openwrt/trunk@43032 3c298f89-4303-0410-b956-a3cf2f4a3e73 Oct 23 20:23:52 thanks zorun, I’ll check it out Oct 23 20:25:18 these fixes are in trunk, any chance they will be fixed in BB? Oct 23 20:30:15 I wouldn't count on it too much Oct 23 20:30:27 anyway, CC is supposed to be released at the end of the year :) Oct 23 20:35:49 I’m not sure this fixes the problem I have Oct 23 20:36:16 the whole txpower offset thing is messed up Oct 23 20:37:47 look at the commit, it's a fairly big patch Oct 23 20:38:06 “cat /sys/kernel/debug/ieee80211/phy0/power” always seems to show the correct power Oct 23 20:38:45 it’s the ath9k driver that writes to this file in /sys am I right? Oct 23 20:40:51 since the ubiquity SR71 cards have a 7dB amplifier onboard, the value communicated to the atheros chipset is 7dB lower than the actual output power Oct 23 20:41:31 since the real output power is correct in /sys/kernel/debug/ieee80211/phy0/power, the driver already took the 7dB offset into account Oct 23 20:42:16 in a hardware.txt file in the iwinfo source there is a list of frequency and txpower offsets for a lot of cards and now it seems that the offsets are done double Oct 24 00:17:03 florian r43035 trunk/toolchain/ gcc/patches/4.8-linaro/221-musl_mips64.patch gcc/patches/4.9-linaro/221-musl_mips64.patch * toolchain: fix mips64 musl linker names Oct 24 00:17:15 florian r43036 trunk/target/linux/generic/patches-3.14/063-mips_decompressor_memmove.patch * kernel: add a memmove() implementation for MIPS boot decompressor Oct 24 00:17:28 florian r43037 trunk/target/linux/ (11 files in 5 dirs) * netlogic: add XLR/XLP support Oct 24 00:17:42 florian r43038 trunk/target/linux/ (9 files in 6 dirs) * netlogic: add basic user-space support Oct 24 00:17:53 florian r43039 trunk/target/linux/ netlogic/patches-3.14/001-modular_usb.patch netlogic/patches-3.14 * netlogic: fix modular USB build **** ENDING LOGGING AT Fri Oct 24 03:00:00 2014