**** BEGIN LOGGING AT Mon Jun 14 02:59:57 2010 Jun 14 04:00:26 build #72 of avr32 is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/avr32/builds/72 Jun 14 04:12:29 build #71 of brcm63xx is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/brcm63xx/builds/71 Jun 14 04:18:39 build #68 of brcm47xx is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/brcm47xx/builds/68 Jun 14 06:01:22 build #66 of sibyte is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/sibyte/builds/66 Jun 14 07:01:28 claudio * r21792 /packages/libs/zaptel-1.4.x/Makefile: [package] zaptel: fix typo introduced in r21786 Jun 14 07:40:31 build #61 of cobalt is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/cobalt/builds/61 Jun 14 08:04:11 hello Jun 14 09:16:28 build #59 of gemini is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/gemini/builds/59 Jun 14 10:03:08 nbd * r21793 /trunk/target/linux/brcm47xx/ (4 files in 4 dirs): brcm47xx: add some exports to be used by the new wl driver Jun 14 11:00:36 nbd * r21794 /trunk/ (115 files in 28 dirs): rename broadcom-wl to broadcom-wl-old Jun 14 13:23:11 build #59 of mpc52xx is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/mpc52xx/builds/59 Jun 14 14:44:31 acoul * r21795 /trunk/include/netfilter.mk: include/netfilter.mk: add 2.6.35 kernel support Jun 14 14:51:54 acoul * r21796 /trunk/include/netfilter.mk: include/netfilter.mk fix typo on r21795 Jun 14 14:59:38 acoul * r21797 /trunk/target/linux/ixp4xx/ (9 files in 2 dirs): ixp4xx: add kernel 2.6.35 preliminary support Jun 14 15:28:00 is there somewhere I can read about the ht_capab list options for ath9k? Jun 14 15:28:33 yes, the hostapd source ;( Jun 14 15:28:34 ;) Jun 14 15:28:53 lol, thats what I was you would say Jun 14 15:29:13 nbd: by the way, the latest ath9k does seem much more stable for me Jun 14 15:29:26 yeah, other people are reporting the same Jun 14 15:29:48 i think i took care of most of the important bugs now Jun 14 15:30:03 nice job Jun 14 15:30:14 so what do you want to know about the capabilities? what they mean? or do you want a list of options that exist? Jun 14 15:31:33 what they mean, what is valid for my router (wndr3700), so I can try out channel bonding etc Jun 14 15:31:50 ht20 vs ht40 is configured with a separate variable Jun 14 15:31:53 htmode Jun 14 15:31:58 accepts HT20, HT40- or HT40+ Jun 14 15:32:05 other than that, you can leave the capabilities alone Jun 14 15:32:11 all supported capabilities are enabled by the default config Jun 14 15:32:24 ok, that is helpful Jun 14 15:32:44 and when do I use ht40- vs ht40+? Jun 14 15:33:06 ht40+ means extension channel is above the primary channel Jun 14 15:33:10 with ht40- it's below Jun 14 15:33:40 ok, thanks for the info Jun 14 15:47:08 nbd * r21798 /trunk/target/linux/generic-2.6/patches-2.6.30/942-ssb_add_dma_dev.patch: backport the ssb dma device change to 2.6.30 as well Jun 14 15:53:43 nbd: it seems my transfer speed has been cut in half, now peak at 6MB/s but stable, before it was ~12MB/s but unstable. Is this expected with the stability fixes? Or perhaps I have missed something... Jun 14 15:56:48 no, the stability fixes should not have caused any throughput decrease Jun 14 15:56:58 i get ~10 mbytes/s Jun 14 15:57:08 were you using ht40 at some point? Jun 14 15:57:10 or are you using it now? Jun 14 15:58:53 brb Jun 14 15:58:56 before I had added: list 'ht_capab' 'HT40+' to the 5ghz radio, iirc that is all I changed Jun 14 15:59:19 ht40 can sometimes decrease your throughput Jun 14 15:59:33 and sometimes hostapd refuses to enable it, if it detects an overlap with another ht40 ap Jun 14 15:59:39 try ht20 to see what speed you get Jun 14 15:59:50 ok Jun 14 16:01:59 fwiw, the client was reporting 270Mbit or 300Mbit raw rate... Jun 14 16:03:01 with HT20, raw rate is 117Mbit or 130Mbit, and transfer rate is still ~6mbit Jun 14 16:04:33 cpu is 65% idle Jun 14 16:06:56 ht_capab listed options (these were the default): SHORT-GI-40, TX-STBC, RX-STBC1, DSSS_CCK-40 Jun 14 16:14:04 nbd: it seems to be working fine, somehow I messed up the speed test before... Jun 14 16:14:28 I'm getting 11MB/s connecting to a different machine Jun 14 17:26:41 jow * r21799 /trunk/package/iptables/ (Makefile patches/030-no-libnfnetlink.patch): Jun 14 17:26:41 [package] iptables: Jun 14 17:26:41 - supress detection of libnfnetlink and force configure to not use it Jun 14 17:26:41 - fix staging install of libxtables, libiptc and libipq libraries Jun 14 18:01:13 claudio * r21800 /trunk/target/linux/generic-2.6/ (12 files in 5 dirs): [kernel] Add the generic PWM api from Bill Gatliff (experimental). Ignore the leds trigger part at the moment Jun 14 18:34:26 nbd * r21801 /trunk/package/mac80211/Makefile: mac80211: fix compile on systems that do not have /bin/true Jun 14 18:35:47 nbd * r21802 /branches/backfire/target/linux/generic-2.6/ (2 files in 2 dirs): [backfire] backport the ssb dma device change from trunk Jun 14 18:35:49 nbd * r21803 /branches/backfire/package/mac80211/ (27 files in 2 dirs): [backfire] backport mac80211 updates from trunk Jun 14 18:58:51 <[Fate]> has anyone seen juhosg lately? Jun 14 19:39:06 florian * r21804 /trunk/target/linux/generic-2.6/ (4 files in 4 dirs): [kernel] reinstate netdev LED trigger dependency against CONFIG_NET Jun 14 19:42:21 [florian]: ping Jun 14 19:48:55 <[florian]> KanjiMonster: pong Jun 14 19:50:34 [florian]: I am currently trying to add support for my bcm6348-board (telecom speedport w500v), and looking at the code, have the following problem: according to the board name, its claims to be a "96348GW", but most parameters are wrong (seems t-com was lazy ... ) Jun 14 19:51:17 any ideas how to "fix" this without braking other *gw boards? Jun 14 20:02:33 <[florian]> KanjiMonster: you can add a fixup for your board to change the board name Jun 14 20:02:47 juhosg * r21805 /trunk/target/linux/ar71xx/files/arch/mips/ar71xx/prom.c: ar71xx: avoid duplicated 'board' parameter in kernel command line Jun 14 20:03:31 <[florian]> KanjiMonster: just like the nb4 does Jun 14 20:03:45 sounds good, I'll take a look at it Jun 14 20:36:42 [florian]: hrm, this seems to depend on the boardname somewhere else in the cfe, which it isn't on the w500v :-/ (at least a strings on the cfe didn't show anything remotely usable) Jun 14 20:37:19 <[florian]> KanjiMonster: ah, then it's going to be harder, because we still want the board to be autodetect Jun 14 20:37:22 <[florian]> +ed Jun 14 20:37:56 you guys could do ar71xx style cmdline patching and use the mips machine stuff Jun 14 20:38:14 <[florian]> yeah Jun 14 20:38:15 then you don't have to rely on potentially unreliable runtime detection Jun 14 20:48:48 nbd: but this still depends on the board identifying itself somehow (the printed commandline at boot is 'root=/dev/mtdblock2 rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200', but I don't know whether this is the cfe commandline) Jun 14 20:51:19 ah, I see, this is just the configured commandline Jun 14 21:47:23 florian * r21806 /trunk/tools/firmware-utils/ (Makefile src/bcmalgo.c src/bcmalgo.h src/hcsmakeimage.c): [tools] add hcsmakeimage, for cable modems/routers based on bcm33xx Jun 14 21:48:59 florian * r21807 /trunk/package/util-linux-ng/Makefile: [package] add package for script from util-linux-ng (#7416) Jun 14 21:49:05 florian * r21808 /trunk/tools/firmware-utils/ (Makefile src/bcmalgo.c src/bcmalgo.h src/hcsmakeimage.c): Revert r21806 there are no users of it yet Jun 14 22:35:45 <[Fate]> how do I translate the offsets/sizes between the generated flash image file (in this case, a tp-link .bin file) and the mtd partition layout? Jun 14 22:36:07 <[Fate]> ie. if I modify the rootfs start in the flash image file, how do I know by how much the mtd layout needs to be changed, too? Jun 14 22:37:14 doesn't the mtd maps use absolute offsets? Jun 14 22:42:43 <[Fate]> yes it does Jun 14 22:49:43 <[Fate]> but, well, I already get "gunzipping errors" on the ap when I move the rootfs offset Jun 14 22:53:17 [florian]: the only "fixup id" I can currently think of is the mac address - if its a tecom address and a 96348gw, then assume its a speedport (but I don't know if this would catch other boards it shouldn't) Jun 14 23:26:00 Nope. That would catch IG6000 too Jun 14 23:26:40 damn Tecom Jun 14 23:50:20 I'm not sure Tecom has anything differentiates an e.g. IG6000 from a speedport Jun 14 23:50:33 that we can probe on boto Jun 14 23:50:34 bot Jun 14 23:50:36 boot Jun 14 23:51:28 Can we use the imagetag information? I think the imagetag is different for different Tecom devices Jun 14 23:55:55 cshore: I don't know, what do I look for and where? I'm quite new to the bcm63xx stuff Jun 15 00:03:03 KanjiMonster: The imagetag definitions are in bcm_tag.h under target/linux/brcm63xx/files/ and are loaded where the mtd partitions are in memory. (That is the bcm_tag appears at 0x1000 offset from the beginning of the start of the mtd partitions (i.e. after the CFE) Jun 15 00:03:50 KanjiMonster: the values in the imagetag are determined by tools/firmware-tools/src/imagetag.c Jun 15 00:03:55 sorry Jun 15 00:04:19 ah I see Jun 15 00:04:24 KanjiMonster: I mean target/linux/brcm63xx/images/Makefile Jun 15 00:05:14 so that means that the board gets hardcoded into the image? Jun 15 00:05:23 KanjiMonster: yes Jun 15 00:06:18 KanjiMonster: and if Tecom doesn't actually have different values for the different devices, we can put something in one of the reserved areas for OpenWRT purposes Jun 15 00:07:24 sounds good Jun 15 00:07:55 but not today, it's already 2 am here - I need sleep ;-) Jun 15 00:08:09 ok Jun 15 00:09:07 therefore: good night **** ENDING LOGGING AT Tue Jun 15 02:59:57 2010