**** BEGIN LOGGING AT Tue Feb 21 02:59:58 2012
Feb 21 05:56:26 <builder_> build #97 of mpc52xx is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/97
Feb 21 06:40:26 <builder_> build #129 of pxcab is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/pxcab/builds/129
Feb 21 07:45:14 <philipp64|laptop> nbd: ping
Feb 21 09:56:54 <CIA-56> juhosg * r30669 /trunk/target/linux/ramips/ (3 files in 2 dirs): ramips: rename the spi driver
Feb 21 09:56:55 <CIA-56> juhosg * r30670 /trunk/target/linux/ramips/ (12 files in 7 dirs):
Feb 21 09:56:55 <CIA-56> ramips: move the ethernet driver into a separate directory
Feb 21 09:56:55 <CIA-56> Also clean up the Kconfig symbols.
Feb 21 10:14:42 <CIA-56> juhosg * r30671 /trunk/target/linux/ramips/files/drivers/net/ethernet/ramips/ (Kconfig Makefile): ramips: raeth: add missing Kconfig and Makefile
Feb 21 12:36:22 <builder_> build #99 of adm5120 is complete: Failure [failed compile_10]  Build details are at http://buildbot.openwrt.org:8010/builders/adm5120/builds/99
Feb 21 14:29:51 <merbanan> something in openwrt generates kernel/linux/include/config/auto.conf
Feb 21 14:30:02 <merbanan> how do I get it to not do that ?
Feb 21 14:31:10 <blogic> merbanan: i assume you mean build_dir/linux-.../linux-3.X/include/config/auto.conf ?
Feb 21 14:31:22 <merbanan> yes
Feb 21 14:31:34 <blogic> then why did you give a different path ? :)
Feb 21 14:31:35 <blogic> anyhow
Feb 21 14:31:56 <merbanan> I use an old kernel
Feb 21 14:32:02 <blogic> its a feature, you cant turn it off
Feb 21 14:32:08 <blogic> i am wearing shoes
Feb 21 14:32:30 <merbanan> what controls this feature
Feb 21 14:32:32 <blogic> auto.conf is auto generated and it the kernek build doing it i think so there is not really anything you can do about ti
Feb 21 14:32:32 <merbanan> ?
Feb 21 14:32:49 <blogic> which part of my answer was not clear ?
Feb 21 14:32:54 <blogic> i can elaborate that part
Feb 21 14:33:16 * blogic cannot type today
Feb 21 14:33:26 <merbanan> or what controls the content of that file
Feb 21 14:35:58 <merbanan> I am trying to build an identical kernel compared to another kernel
Feb 21 14:36:48 <merbanan> and the openwrt build system enables some features the other kernel doesn't have
Feb 21 14:37:13 <merbanan> the other kernel boots on my hardware while the openwrt generated kernel doesn't
Feb 21 14:52:29 <KanjiMonster> merbanan: the contents of the auto.conf is generated from the kernel's .config
Feb 21 14:53:41 <merbanan> KanjiMonster: how is the .config file generated ?
Feb 21 14:54:49 <merbanan> target/linux/generic-2.6/config-2.6.30 + ????
Feb 21 14:55:55 <KanjiMonster> + target/linux/<target>/config-(<version>|default) + symbols from enabled kmods + some menuconfig options
Feb 21 14:56:33 <KanjiMonster> merbanan: https://dev.openwrt.org/browser/trunk/include/kernel-defaults.mk#L80
Feb 21 15:44:58 <merbanan> KanjiMonster: thanks
Feb 21 15:46:17 <merbanan> yey it booted
Feb 21 16:36:46 <Chocks> nbd/jow_laptop: need advice.
Feb 21 16:38:22 <nbd> don't pee against the wind
Feb 21 16:38:30 <nbd> or did you have any more specific advice in mind?
Feb 21 16:38:31 <nbd> ;)
Feb 21 16:38:42 <Chocks> I have here the patches for Sercomm NA900/NA910/NA300.  The port was done by juhosg.  But based upon OpenWrt from about June.  2.6.37 and all that.
Feb 21 16:39:19 <Chocks> I've badgered Sercomm repeatedly about it being in their interests to get it all merged/updated etc, but they don't seem convinced
Feb 21 16:39:30 <nbd> i have no idea what kind of device that is
Feb 21 16:39:32 <nbd> or what platform it uses
Feb 21 16:39:36 <Chocks> rt3883
Feb 21 16:39:55 <Chocks> it's a 4+1 port router with Z-Wave on board.
Feb 21 16:40:05 <Chocks> the NA300 is a 1 port version.
Feb 21 16:40:13 <nbd> ok
Feb 21 16:40:28 <nbd> yeah, bugging sercomm about this is probably futile
Feb 21 16:41:03 <Chocks> however, this old version is becoming increasingly problematic.  old kernel, e/glibc stuff. etc, etc.   and juhos is pretty unresponsive these days.  So I need to just pushing his stuff to you guys.
Feb 21 16:41:15 <Chocks> user space is easy.  kernel is gonna be a bitch.
Feb 21 16:41:27 <Chocks> Any general commentary?
Feb 21 16:42:01 <nbd> well, juhosg added preliminary rt3883 support last week
Feb 21 16:42:24 <Chocks> right, the last thing I forgot to mention is that some of his changes he's been pushing.  I'd say, about 1/3 of them.
Feb 21 16:42:32 <Chocks> let me review what he did, since I wasn't aware of that
Feb 21 16:44:11 <[florian]> Chocks: how about you let juhosg manages rt3883 has he intends?
Feb 21 16:44:27 <Chocks> florian: it's far from clear that he intends that.
Feb 21 16:44:41 <[florian]> well just talk to him and you will see what are his plans
Feb 21 16:45:14 <Chocks> I already said he's unresponsive.  I've also requested him many times he bring it up to date.  perhaps he is, but I see no Sercomm stuff yet
Feb 21 16:45:31 <[florian]> did you mail him, query him on irc?
Feb 21 16:45:56 <Chocks> I've emailed him many times over the last 6 months.  he only responds sometimes, and not at all recently
Feb 21 16:46:29 <Chocks> I do have his last response, via Sercomm. And it *seems* clear in there his interest is limited.  who knows.  perhaps he likes to play his cards close and not commit.
Feb 21 16:47:06 <[florian]> maybe he is just busy and have other plans for getting these boards supported?
Feb 21 16:47:20 <Chocks> maybe.
Feb 21 16:47:28 <Chocks> nevertheless, I can't plan on "maybe"
Feb 21 16:47:53 <[florian]> if you have patches already, what's the difficulty in forward porting them to 3.2?
Feb 21 16:47:57 <Chocks> I'm not in a hobbyist "wait and see" position
Feb 21 16:48:36 <nbd> as long as juhosg isn't getting paid for this by you, bugging him repeatedly is probably a bad idea
Feb 21 16:48:38 <Chocks> the difficulty is fiddling patches.  I will do it if need be, it's just time consuming.  I just wanted advice on any particular approach.   I will start sumitting them soon
Feb 21 16:48:46 <nbd> he has a lot of things he's working on
Feb 21 16:48:52 <Chocks> nbd: noted
Feb 21 16:50:03 <nbd> i don't think it's about him playing his cards close. he usually commits stuff when he thinks it's ready
Feb 21 16:50:12 <Chocks> sure
Feb 21 16:50:14 <nbd> and seems to prefer not committing hackish stuff as a temporary solution
Feb 21 16:50:18 <nbd> and i think that's a good approach
Feb 21 16:50:24 <Chocks> I can agree with that.
Feb 21 16:50:34 <Chocks> but I don't know which stuff is in that kind of state
Feb 21 16:51:04 <Chocks> well, ok
Feb 21 16:51:09 <nbd> then you should either figure it out yourself or find somebody with time on their hands to do it for you
Feb 21 16:51:24 <nbd> i'm not really up to date on the status of various parts of the ramips port
Feb 21 16:51:27 <Chocks> let me look at his latest stuff, he seems to have bought in 3.2 general stuff for rt3883, which is really good.  Let me figure out what I can submit to you guys
Feb 21 16:51:33 <nbd> nor am i interested in starting development on it at this point
Feb 21 16:51:49 <Chocks> I wouldn't expect you to be, but I do appreciate your statement of position
Feb 21 16:56:03 <Chocks> I'm still in a bit of a contrary position.   from Gabor: "Although I did merge some of my changes back into the OpenWrt repository, but I
Feb 21 16:56:03 <Chocks> still have 400+ unmerged changes. Basically, if I would go to merge the NA9xx
Feb 21 16:56:03 <Chocks> support code, I would have to rebase those unmerged changes against the current
Feb 21 16:56:03 <Chocks> OpenWrt tree and I would have to re-test almost everything"  the context here is presumably work he's being paid for, so it's a bit different in general.  likewise, I'm being paid too, and have immediate requirements.
Feb 21 16:56:21 <Chocks> but the longer unmerged goes on, the more work and hassle and chance of error for me
Feb 21 16:57:04 <nbd> so?
Feb 21 16:57:12 <Chocks> so maybe nothing.
Feb 21 16:57:26 <Chocks> just sayin'
Feb 21 16:57:48 <nbd> ah, ok. i asked "so?" because i assumed you had a reason for saying it
Feb 21 16:57:51 <nbd> ;)
Feb 21 16:58:55 <Chocks> and in the meantime, I have the Buglocis port (at91).  That's must less of a logistical problem
Feb 21 16:58:59 <Chocks> much
Feb 21 17:16:30 <Chocks> moo
Feb 21 18:49:38 <CIA-69> jow * r30672 /trunk/package/iwinfo/src/iwinfo_wext_scan.c: [package] iwinfo: fix logic flaw in WPA OUI filtering, solves misdetecting various WPA2-PSK only networks as mixed mode
Feb 21 18:53:22 <builder_> build #94 of octeon is complete: Failure [failed compile_10]  Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/94
Feb 21 19:41:36 <russell--> seeing kernel config questions on net45xx build: BATTERY_BQ20Z75, SENSORS_K10TEMP, SENSORS_PKGTEMP, SENSORS_VIA_CPUTEMP
Feb 21 21:01:27 <builder_> build #121 of x86 is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/x86/builds/121
Feb 21 21:07:11 <CIA-69> hauke * r30673 /trunk/package/mac80211/Makefile: mac80211: b43: use firmware version 666.2 as default
Feb 21 21:17:36 <philipp64|laptop> jow_laptop: I'm seeing: http://fpaste.org/f6Z1/
Feb 21 21:18:24 <philipp64|laptop> I have CONFIG_FB_DDC=m in the list of KCONFIG values that a module I've selected ... yet the resulting .config still has "# CONFIG_FB_DDC is not set". what is overriding it?
Feb 21 21:22:04 <jow_laptop> maybe some fb module
Feb 21 21:24:31 <Epsylon3> config-default of the target tree ?
Feb 21 21:24:42 <Epsylon3> git grep -n CONFIG_FB_DDC
Feb 21 21:24:57 <philipp64|laptop> CONFIG_FB is a dependency of CONFIG_FB_DDC, but I'm setting both.
Feb 21 21:25:28 <philipp64|laptop> see http://fpaste.org/MUaU/
Feb 21 21:26:01 <Epsylon3> omap3 ?
Feb 21 21:26:29 <philipp64|laptop> if I put CONFIG_PACKAGE_kmod-fb-core=y then fb.ko gets built, but not fb-ddc.ko
Feb 21 21:26:40 <philipp64|laptop> this is for the alix3 for crow.
Feb 21 21:28:41 <Epsylon3> try to remove the line in target/linux/generic/config-xxx
Feb 21 21:28:48 <Epsylon3> # CONFIG_FB_DDC is not set
Feb 21 21:29:05 <Epsylon3> router doesnt have fb generaly :p
Feb 21 21:29:34 <philipp64|laptop> ok, but what's the order that the config-default files get applied?
Feb 21 21:29:50 <philipp64|laptop> why isn't that line trumped by the kmod- definitions?
Feb 21 21:30:12 <Epsylon3> i think linux config first (version)
Feb 21 21:30:20 <Epsylon3> then target/config-default overrides
Feb 21 21:30:36 <Epsylon3> target/xxx/config-default
Feb 21 21:31:00 <philipp64|laptop> and $(KCONFIG) ?
Feb 21 21:31:25 <Epsylon3> i dunno all of them :p
Feb 21 21:31:35 <danitool> how do I use memcmp to compare first 2 bytes of an addres with an hex  value (0xa55a) and not with a second address?
Feb 21 21:32:14 <danitool> something like this, but wrong:  if (!memcmp(art, 0xa55a, 2))
Feb 21 21:32:20 <philipp64|laptop> no.
Feb 21 21:32:36 <philipp64|laptop> const ushort myval = 0xa55a;
Feb 21 21:32:43 <Epsylon3> if (p & 0xffff000 == 0a55a)
Feb 21 21:32:49 <Epsylon3> 0
Feb 21 21:32:53 <philipp64|laptop> memcmp(ptr, &myval, sizeof(myval))
Feb 21 21:33:01 <Epsylon3> arf
Feb 21 21:33:10 <Epsylon3> if (p & 0xffff000 == 0xa55a0000)
Feb 21 21:33:16 <Epsylon3> well
Feb 21 21:33:17 <philipp64|laptop> no, he wants the value at the pointer... not the pointer itself.
Feb 21 21:33:37 <Epsylon3> i read "first 2 bytes of an address"
Feb 21 21:34:03 <philipp64|laptop> right, but I think the "and not with a second address" negated that.
Feb 21 21:34:25 <danitool> thanks for the info
Feb 21 21:34:32 <philipp64|laptop> i.e. that 0xa55a was the address at the location, and not the pointer to compare to.
Feb 21 21:35:11 <Epsylon3> well i return to my hostapd ics fixes :p
Feb 21 21:35:33 <philipp64|laptop> and I'll wait for any additional insight from jow_laptop. :-)
Feb 21 21:36:26 <philipp64|laptop> especially since taking CONFIG_FB_DDC out of target/linux/generic/config-3.2 didn't fix the problem.
Feb 21 22:26:48 <crow> philipp64|laptop thanks for you work on alix3
Feb 21 22:29:58 <philipp64|laptop> sure... as soon as I can get the FB_DDC problem fixed, it should be good to check-in.
Feb 21 23:07:33 <builder_> build #125 of rb532 is complete: Failure [failed compile_10]  Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/125
Feb 21 23:17:39 <CIA-69> acinonyx * r30674 /packages/net/quagga/ (10 files in 2 dirs): [packages] quagga: Drop support for Quagga 0.98.6
Feb 21 23:33:33 <CIA-69> nbd * r30675 /trunk/package/iptables/Makefile: iptables: do not link binaries with -rdynamic, plugins do not need any symbols from the main executable. saves some space
Feb 21 23:41:30 <Olipro> Acinonyx: it'd be nice if you'd add those memleak patches I pulled from upstream
Feb 21 23:42:47 <Olipro> danitool: if you're using a pointer, don't cast it to a short unless you know it exists on a good alignment
Feb 21 23:43:51 <Olipro> thus, if you don't, & the value at the pointer with the desired mask
Feb 21 23:44:03 <Olipro> i.e. *myptr & 0xFFFF
Feb 21 23:44:46 <nbd> if performance is not important, unaligned pointers work just fine ;)
Feb 21 23:44:55 <Olipro> depending on architecture
Feb 21 23:45:14 <nbd> yeah, but any sane modern architecture is able to fix things up
Feb 21 23:46:07 <Olipro> you're too trusting of GCC :D
Feb 21 23:46:19 <nbd> this has nothing to do with gcc
Feb 21 23:46:37 <nbd> unaligned access generates an exception
Feb 21 23:46:42 <nbd> the kernel looks at the faulting instruction
Feb 21 23:46:47 <nbd> emulates an unaligned load/store
Feb 21 23:46:50 <nbd> then jumps back to user space
Feb 21 23:46:53 <nbd> at least on mips
Feb 21 23:47:03 <nbd> where the cpu doesn't support unaligned access natively
Feb 21 23:47:17 <nbd> not good for performance
Feb 21 23:47:18 <nbd> but works ;)
Feb 22 00:21:09 <Epsylon3> newer arm are not more like this
Feb 22 00:21:24 <Epsylon3> the 4byte align access problem
Feb 22 00:21:49 <Epsylon3> "fixed" in v7 or v7a i think
Feb 22 00:43:03 <Olipro> ARM has supported unaligned access for a while
Feb 22 00:43:11 <Olipro> but you have to set a bit in CP0
Feb 22 00:43:42 <Olipro> I forget which, but you can look it up on infocenter.arm.com
Feb 22 00:49:25 <Olipro> er, CP15
Feb 22 01:02:08 <Epsylon3> since thumb maybe
Feb 22 01:19:20 <Olipro> thumb is an extension to ARM
Feb 22 01:19:42 <Olipro> it uses 16 bit instructions
Feb 22 01:19:49 <Olipro> it existed before unaligned accesses
Feb 22 02:18:03 <CIA-69> nbd * r30676 /trunk/package/ (3 files in 3 dirs): iptables: make it possible to dynamically configure built-in statically linked extensions, fold -mod-conntrack and -mod-nat into the default package. saves about 8k on an ar71xx default squashfs
Feb 22 02:20:05 <CIA-69> nbd * r30677 /packages/net/ (multiwan/Makefile wifidog/Makefile): multiwan,wifidog: adjust dependencies for removed iptables-mod-{conntrack,nat}
**** ENDING LOGGING AT Wed Feb 22 02:59:58 2012