**** BEGIN LOGGING AT Sat Aug 30 02:59:59 2014 Aug 30 03:35:28 build #749 of brcm63xx is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx/builds/749 Aug 30 03:39:11 build #576 of iop32x is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/576 Aug 30 04:03:36 build #719 of atheros is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/atheros/builds/719 Aug 30 04:32:57 build #623 of kirkwood is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/kirkwood/builds/623 Aug 30 05:04:08 build #71 of brcm47xx.mips74k is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx.mips74k/builds/71 Aug 30 06:42:05 build #258 of mvebu is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/mvebu/builds/258 Aug 30 07:58:43 build #524 of octeon is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/524 Aug 30 09:11:59 nbd r42333 trunk/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c Aug 30 09:12:00 ar71xx: disable ethernet descriptor splitting for now, as it seems to cause tx hangs in some setups Aug 30 09:33:16 blogic r42334 trunk/target/linux/ (194 files in 9 dirs) * ipq806x: Add support for IPQ806x chip family Aug 30 09:59:36 blogic r42335 trunk/target/linux/ ramips/Makefile ipq806x/Makefile lantiq/Makefile * target: set myself as maintainer Aug 30 09:59:47 blogic r42336 trunk/target/linux/ipq806x/Makefile * ipx806x: bump to 3.14.16 Aug 30 10:41:18 <_trine> Kaloz, have you been able to find any time yet to look into the issue of the Dockstar Hardware crypto engine not working Aug 30 11:02:40 jogo r42337 trunk/package/devel/binutils/Makefile * binutils: link libbfd and libopcodes dynamically again Aug 30 11:04:37 jogo r42338 branches/barrier_breaker/package/devel/binutils/Makefile * BB: binutils: link libbfd and libopcodes dynamically again Aug 30 11:07:16 stintel: oh, it actually was you. Wasn't sure if this was your ticket, so I didn't add you as reported by. Of course *after* committing I see your name as the file owner in the ls output ;) Aug 30 12:23:00 <_trine> nbd will you please take a look at why wifi connections are not working properly, I might expect you to say that is a vague description however its is vague simply because there seems to be more than one thing interacting with each other Aug 30 12:25:24 <_trine> and I refuse to type a better description until I know you are least seeing this and are interested in sorting it out Aug 30 12:27:01 <_trine> in the meantime I am going to flash back to a known working version from November 2013 Aug 30 12:27:12 what have you observed about the issues so far? Aug 30 12:27:13 <_trine> sad as it seems Aug 30 12:27:22 <_trine> well Aug 30 12:28:20 <_trine> let me explain that this morning after having dismal results with the current kernel I tried the newer upand coming kernel Aug 30 12:28:37 <_trine> and got better results Aug 30 12:29:02 <_trine> the situation with the current openwrt kernel is this Aug 30 12:29:26 <_trine> the November 2013 code appears to work very well Aug 30 12:29:53 <_trine> when connecting to a particular AP Aug 30 12:30:34 <_trine> I have set up a nano here in my room pointing out of the window so its not under fairly good controlled conditions Aug 30 12:31:10 <_trine> I have been flashing it backwards and forwards with new compiled code and the November 2013 one Aug 30 12:31:26 <_trine> so I can make sure I have consistant results Aug 30 12:31:32 <_trine> as far as is possible Aug 30 12:32:26 <_trine> the November 2013 code can connect and achieves on average about 15 to 20MB/s Aug 30 12:33:23 <_trine> the current code, ie not with the new kernel, finds it hard to actually connect and when it does only achieves max about 4MB/s Aug 30 12:34:09 <_trine> now with the newer kernel it seems nearly as good at connecting but not quite as good as the November 2013 code Aug 30 12:34:44 <_trine> but with this newer compile and kernel comes other problems Aug 30 12:35:45 <_trine> firstly the nano only seems to be able to achieve about 8 to 10 MB/s Aug 30 12:36:03 <_trine> instead of the previous 15 to 20 MB/s Aug 30 12:36:07 did you write anything after "< _trine> when connecting to a particular AP"? Aug 30 12:36:13 got disconnected Aug 30 12:36:26 <_trine> yes Aug 30 12:37:06 <_trine> I have set up a nano here in my room pointing out of the window so its not under fairly good controlled conditions Aug 30 12:37:11 <_trine> I have been flashing it backwards and forwards with new compiled code and the November 2013 one Aug 30 12:37:17 <_trine> so I can make sure I have consistant results Aug 30 12:37:22 <_trine> as far as is possible Aug 30 12:37:28 <_trine> the November 2013 code can connect and achieves on average about 15 to 20MB/s Aug 30 12:37:36 <_trine> the current code, ie not with the new kernel, finds it hard to actually connect and when it does only achieves max about 4MB/s Aug 30 12:37:44 <_trine> now with the newer kernel it seems nearly as good at connecting but not quite as good as the November 2013 code Aug 30 12:37:49 <_trine> but with this newer compile and kernel comes other problems Aug 30 12:38:06 <_trine> for example Aug 30 12:39:00 <_trine> when I connect to the Ocula speed test site the webpage always gets stuck at a particular point just before it actually starts the ping test Aug 30 12:39:35 <_trine> I can resolve this issue by doing cpcudh -i eth0 Aug 30 12:39:55 <_trine> that seems to make it possible to actually get a speed test to work Aug 30 12:40:24 <_trine> but again as I said it never achieves the same speed as the Novemebr 2013 code does Aug 30 12:40:57 <_trine> even when the webpage as become stuck pressing F5 has no effect at all Aug 30 12:41:12 <_trine> so thats where I am with it Aug 30 12:41:32 ok Aug 30 12:41:47 <_trine> the speed test web site with the new code always gets stuck at the same point Aug 30 12:41:55 is the displayed signal strength the same for the old and the new build? Aug 30 12:42:05 i mean 2013 vs current Aug 30 12:42:33 build #166 of brcm2708 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/brcm2708/builds/166 Aug 30 12:43:11 then there's another thing that i need: the output of cat /sys/kernel/debug/ieee80211/phy0/netdev:*/stations/*/rc_stats for both the old and the new build after transferring some data Aug 30 12:43:42 <_trine> I would have to check that for you by reflashing if you want an exact answer but I am fairly sure there isnt much difference Aug 30 12:44:12 ok, please get me the signal strength and the above stats after transferring some data with both builds Aug 30 12:44:19 and then another thing: Aug 30 12:44:29 /sys/kernel/debug/ieee80211/phy0/ath9k/ani Aug 30 12:44:33 also for both Aug 30 12:44:48 once i have those dumps, i'll take another look Aug 30 12:45:07 <_trine> so you want just the signal strength and /sys/kernel/debug/ieee80211/phy0/ath9k/ani ?? Aug 30 12:45:14 <_trine> for both Aug 30 12:45:19 and the other one Aug 30 12:45:23 rc_stats Aug 30 12:45:31 <_trine> ah yes Aug 30 12:45:49 maybe also xmit Aug 30 12:46:04 all after transferring at least some megabytes of data Aug 30 12:46:43 you can send it to me via email - makes it easier to keep track of Aug 30 12:47:03 <_trine> am I right in thinking at this point you are not interested in data from the upcoming kernel Aug 30 12:47:28 right. if it's a wireless driver issue, the kernel shouldn't matter Aug 30 12:47:37 <_trine> ok Aug 30 12:55:36 build #604 of au1000 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/au1000/builds/604 **** BEGIN LOGGING AT Sat Aug 30 14:45:18 2014 Aug 30 16:41:30 Hauke: hey Aug 30 16:41:37 zajec_: hey Aug 30 16:41:41 Hauke: a big discussion about this flash, isn't it/ ;) Aug 30 16:41:46 yes Aug 30 16:43:10 Hauke: since OpenWrt doesn't seem to be really ready to overlay initramfs with some "rootfs" or "rootfs_data" JFFS2 partition, I was thinking about this squashfs problem Aug 30 16:43:23 any idea where I should start lookint at? Aug 30 16:43:32 you were saying something about size... or offset? Aug 30 16:43:36 i dont' remember Aug 30 16:43:50 i mean firmware with SquashFS booting (or not) randomly Aug 30 16:44:51 this looks like a problem in the boot loader and it does not know if it is initramfs or squasfs Aug 30 16:45:26 i didn't know CFE checks for that at all Aug 30 16:45:31 I would try to make the squasfs image look like a initramfs image for the boot loader and see what happens, or vice versa Aug 30 16:45:38 but... even if it does.. why is that random?! :| Aug 30 16:45:51 some timing stuff?? Aug 30 16:46:15 it is random with the same image isn't it? Aug 30 16:46:17 filesystem check being affected by timing? weird Aug 30 16:46:21 right Aug 30 16:46:26 I upload one image Aug 30 16:46:35 and without changing flash content i plus and unplug power cable Aug 30 16:46:41 sometimes it boots, sometimes not Aug 30 16:46:49 without changing firmware on the chip at all! Aug 30 16:51:28 I haven't investigated this problem I was lucky when I was able to boot an image at all ;-) Aug 30 16:51:35 I am still missing tftp boot Aug 30 16:53:32 yeah Aug 30 16:53:54 however this flash over SPI seems to be at least a bit faster than serial flashes on MIPS Aug 30 16:54:18 at least I think so Aug 30 16:56:26 Hauke: btw. do GPIOs work on ARM? Aug 30 16:56:29 i didn't check that Aug 30 16:56:41 I have never tried gpios on arm Aug 30 17:40:40 KanjiMonster_: no worries :) Aug 30 17:42:14 build #672 of ppc44x is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/672 Aug 30 17:43:44 build #172 of x86_64 is complete: Failure [failed compile_1] Build details are at http://buildbot.openwrt.org:8010/builders/x86_64/builds/172 Aug 30 18:10:04 Hauke: GPIOs work except for irq Aug 30 18:10:19 driver_gpio.c uses bcma_core_irq which returns 0 on ARM Aug 30 18:35:45 zajec_: thanks for testing Aug 30 18:36:09 zajec_: I can jot remember any code which assigns an irq to the gpios Aug 30 18:36:18 in the broadcom code Aug 30 18:41:34 i can Aug 30 18:41:44 it's simply in bcm5301x.c Aug 30 18:41:50 soc_cca_irq_enable Aug 30 18:49:17 build #278 of imx6 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/imx6/builds/278 Aug 30 23:07:48 Hauke: could you take a look at [PATCH 1/3] gemini: switch to kernel 3.10 Aug 30 23:08:13 zajec_: the original plan was that someone with the hardware tests this Aug 30 23:08:29 is there any chance for that? Aug 30 23:08:49 I do not think so Aug 30 23:09:02 yeah, i was afraid of that Aug 30 23:09:13 as we can remove kernel 3.9 support then I will probably apply your patches Aug 30 23:09:19 so should we blindly move this to the newer kernel/ Aug 30 23:09:23 or disable the targeT? Aug 30 23:10:07 yeah, I think (I hope) we don't want to stick to the 3.9 any longer ;) Aug 30 23:12:49 ok, it's getting late for me, see you tomorrow :) Aug 31 00:43:11 build #641 of sibyte is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/641 Aug 31 01:34:11 build #653 of avr32 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/653 Aug 31 02:37:33 build #718 of orion is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/718 Aug 31 02:58:49 while using SDK I got STAGING_DIR undefined warning, a search on wiki and the forum gave me a difference setting, is this relevant, or should it be staging_dir or staging_dir/toolchain-architecture_gcc-compilerver_uClibc-libcver/bin/ ? **** ENDING LOGGING AT Sun Aug 31 02:59:58 2014