**** BEGIN LOGGING AT Sat Jan 29 02:59:56 2011 Jan 29 03:40:07 build #63 of sibyte is complete: Failure [failed compile_13] Build details are at http://tksite.gotdns.org:8010/builders/sibyte/builds/63 Jan 29 04:05:24 build #58 of xburst is complete: Failure [failed compile_13] Build details are at http://tksite.gotdns.org:8010/builders/xburst/builds/58 Jan 29 04:38:16 xMff: yup, libusb is used by "lsusb". Jan 29 04:42:15 build #66 of ramips is complete: Failure [failed compile_13] Build details are at http://tksite.gotdns.org:8010/builders/ramips/builds/66 Jan 29 04:52:55 build #66 of rb532 is complete: Failure [failed shell_9 compile_13] Build details are at http://tksite.gotdns.org:8010/builders/rb532/builds/66 Jan 29 04:53:51 build #59 of ixp4xx is complete: Failure [failed compile_13] Build details are at http://tksite.gotdns.org:8010/builders/ixp4xx/builds/59 Jan 29 05:05:08 nbd: where does "diffconfig.sh" live? Jan 29 05:06:15 hmmm.... GCC 4.5.1-l doesn't seem to want to build. Jan 29 05:28:44 build #63 of ar7 is complete: Failure [failed compile_13] Build details are at http://tksite.gotdns.org:8010/builders/ar7/builds/63 Jan 29 05:32:37 build #74 of ubicom32 is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/ubicom32/builds/74 Jan 29 05:59:19 xMff: thanks for the commit. Jan 29 06:18:53 nbd: ah, never mind... just updated. Jan 29 08:38:18 loswillios: works here, worked for months.. Jan 29 08:46:55 Kaloz: it was config-check error, resulting from the switch to default to 4.5.1+l. nbd fixed it in r25203 Jan 29 08:53:25 loswillios: it worked for me regardless, so dunno why it was foobared for some people Jan 29 11:10:02 Kaloz: it was foobar'd for everybody that didn't enable toolchain options in menuconfig Jan 29 11:13:14 a tricky one indeed Jan 29 11:55:30 gmorning Jan 29 11:56:02 nbd: when you design your ubus api i think doing like the lua stack would be much better then the dbus api :-) Jan 29 11:59:32 in a way, my api for building structured data is similar Jan 29 12:00:02 you build structured data in pretty much the same way as generic netlink Jan 29 12:06:52 poelzi: here's some example code using the same message format (creating and parsing): http://nbd.name/gitweb.cgi?p=luci2/libubox.git;a=blob;f=examples/blobmsg-example.c;h=6eec16db81ee9e87827f9ba63525b0d8fa7b983a;hb=HEAD Jan 29 12:09:14 nbd: you use something like variant or do you not work with signatures at all ? Jan 29 12:09:29 i will use signatures as well, for validation Jan 29 12:09:38 but they're not necessary for reading or converting the message data Jan 29 12:10:32 so if i were to make an rpc interface that interfaces ubus with http requests containing json messages, it would not have to deal with signatures at all Jan 29 12:10:51 at least not if it's just a simple service without access control Jan 29 12:13:11 having struggeled the last days with dbus, i can say it's quite complex and the low level api hard to use Jan 29 12:13:29 yeah, i want to make the ubus low level api easy to use Jan 29 12:14:08 yes, looks like that. i return on one call a array of dicts and need 5 iteratiors for that :-) Jan 29 12:14:27 heh Jan 29 12:15:37 with the blob/blobmsg functions, everything operates directly on the output buffer, which it grows internally and which usually gets reused whenever you create a new message Jan 29 12:26:22 ahh, you are using a text protocol Jan 29 12:26:31 that makes many things easier Jan 29 12:39:19 mb * r25235 /packages/utils/calvaria/ (6 files in 3 dirs): Add calvaria. Tool to access Maemo CAL partition. Jan 29 12:39:41 mb * r25236 /trunk/target/linux/omap24xx/profiles/100-n810.mk: n810 profile: Add calvaria Jan 29 12:42:19 poelzi: it's not a text protocol Jan 29 12:42:50 then i missread the code when flying over it Jan 29 12:45:56 the 'blob' format is just a 4-byte data structure with id and length, followed by the raw value data padded to 4 bytes Jan 29 12:46:29 the 'blobmsg' format is an extension of that, where there's a namelen + name before the value data Jan 29 12:46:55 and where the id is not an arbitrary id, but the type of the data Jan 29 12:58:53 build #1 of lantiq is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/lantiq/builds/1 Jan 29 13:15:19 build #66 of ps3 is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/ps3/builds/66 Jan 29 13:45:44 jow * r25237 /trunk/package/base-files/files/lib/network/config.sh: [package] base-files: fix handling of dhcp "reqopts" option Jan 29 13:51:59 nbd * r25238 /trunk/package/mac80211/patches/560-cfg80211_max_power.patch: cfg80211: do not overwrite the hardware max power setting in the regulatory code, fixes reported tx power values Jan 29 14:50:47 build #60 of kirkwood is complete: Failure [failed shell compile_6] Build details are at http://tksite.gotdns.org:8010/builders/kirkwood/builds/60 Jan 29 14:59:43 build #81 of brcm63xx is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/brcm63xx/builds/81 Jan 29 15:30:44 is the lantiq target the same as ifxmips? Jan 29 15:39:28 maligor: blogic is merging the targets Jan 29 15:40:20 noticed it has usb support in it too Jan 29 15:41:54 I guess I'll try and see what happens, since I rather need usb Jan 29 16:14:24 build #76 of brcm47xx is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/brcm47xx/builds/76 Jan 29 16:20:29 build #68 of pxcab is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/pxcab/builds/68 Jan 29 16:23:40 bummer, serial doesn't come up on the lantiq target Jan 29 16:47:45 build #76 of s3c24xx is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/s3c24xx/builds/76 Jan 29 16:57:07 build #62 of uml is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/uml/builds/62 Jan 29 17:06:36 build #63 of x86 is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/x86/builds/63 Jan 29 17:06:41 jow * r25239 /trunk/package/base-files/files/lib/network/config.sh: [package] base-files: fix a typo in processing of additional dhcp request opts Jan 29 18:13:10 hello, can anyone explain how openwrt (backfire) creates it's vmlinux.elf file? Jan 29 18:14:48 mb * r25240 /packages/utils/calvaria/ (4 files in 2 dirs): calvaria: Add p54spi EEPROM generator Jan 29 18:15:52 mb * r25241 /trunk/target/linux/omap24xx/base-files/etc/init.d/p54spi-eeprom: Add p54spi EEPROM initscript Jan 29 18:45:58 mb * r25242 /trunk/target/linux/omap24xx/base-files/ (4 files in 3 dirs): omap24xx: Move p54 eeprom init to preinit Jan 29 18:52:15 jow * r25243 /packages/libs/mysql/files/mysqld.init: [packages] mysql: properly handle quoted datadirs in initscript Jan 29 18:52:19 nbd or blogic: how does the libusb dependency fix look? Jan 29 19:39:05 loswillios: mind if I move the pulseaudio page out of the wiki root? Jan 29 19:39:18 its a bit displaced there Jan 29 19:40:59 thhp: its just taken from the linux build tree Jan 29 19:57:19 xMff: thanks, I figured it out ;-) It was the objcopy magic I was after Jan 29 20:26:44 <[florian]> Wipster: ping? Jan 29 21:06:40 [florian], pong Jan 29 21:07:51 <[florian]> Wipster: I have a bit lost track of what is missing for 88e6060 to work Jan 29 21:08:56 [florian], ah right Jan 29 21:10:00 <[florian]> Wipster: also, do you remember what was missing in 2.6.36 for everything to work? Jan 29 21:10:05 <[florian]> I plan on updating ar7 again Jan 29 21:10:55 [florian], well need to pad out the packet with two bytes because of the header the switch adds and then you need to call the mvswitch drivers recieve, and detecting the frame type needed to be moved Jan 29 21:11:25 <[florian]> Wipster: ok, but it is basically working right? Jan 29 21:13:23 [florian], there is an issue in the code path for mvswitch in .36 making it.... what was it, not freeing memory properly? Happens a after few seconds of activity my best guess is there is a leak somewhere possibly introduced by the padding and not freeing what it was padded too but I'm not sure Jan 29 21:13:44 <[florian]> looks like it, yes Jan 29 21:14:06 <[florian]> and this only happened in the mvswitch enabled codepath, right? Jan 29 21:14:11 correct Jan 29 21:15:08 I have been looking at ar7 the last few days, as the current trunk busts eth on my router Jan 29 21:16:44 am I correct in thinking that there isn't really a way to detect which phy on the mdio bus connects to which interface? Its just a 'here is a list of attached phy's have fun connecting'? Jan 29 21:17:53 <[florian]> unless the hardware designer made the phy address be in the same order as the port value, no :) Jan 29 21:18:34 <[florian]> we are already pretty lucky ar7 provides a "mdio alive" status register Jan 29 21:18:46 <[florian]> I have never seen that anywhere else Jan 29 21:18:55 ah small blessings then Jan 29 21:19:24 <[florian]> yeah :) Jan 29 21:19:30 <[florian]> saves you the probing Jan 29 21:21:56 I have been doing firing up the mdio bus in platform to check and setup the devices accordingly but then I thought, well hang on disabling ephy and mii remapping only affects low cpmac and doesn't need to be arch specific, if it detects a switch it should disable the phy in almost all cases. Correct me if I am wrong but isn't highcpmac MII only? Jan 29 21:22:39 <[florian]> the mdio bus is shared between the two Jan 29 21:22:54 <[florian]> I think that only highcpmac has an internal phy Jan 29 21:23:08 <[florian]> but lowcpmac could be connected to a switch or an external phy Jan 29 21:24:17 <[florian]> I do not think that highcpmac could ever be connected to a switch Jan 29 21:24:25 hmmm I was under the assumption cpmac low was MII (switch) or internal phy and high was MII only Jan 29 21:24:36 <[florian]> maybe I am wrong Jan 29 21:24:39 <[florian]> that could very well be the case Jan 29 21:26:45 hmmmm if only there was a bit more detailed spec floating about, I only have the product briefs Jan 29 21:26:53 vague at best Jan 29 21:28:28 but it does seem in most of the code they turn on one or the other, I guess titans need both as I have seen some products with both wired out. Jan 29 21:28:45 <[florian]> correct Jan 29 21:29:06 <[florian]> titan can fortunately be enabled at the platform level Jan 29 21:30:19 yeh, well if one of the titan ports is connected to the internal phy then its always going to be at the same phy, fun commences when you detect a switch.... which internal phy do you disable? heh Jan 29 21:30:37 <[florian]> there is only one internal phy Jan 29 21:30:51 <[florian]> which should logically reside at phy address 1 Jan 29 21:31:07 <[florian]> there is one thing we could check Jan 29 21:31:23 <[florian]> like for instance, whether an internal phy shows up on the mdio alive status register Jan 29 21:31:33 <[florian]> this should not be the case Jan 29 21:31:35 really? oh sorry I thought the RESET_BIT_EPHY and EPHY1 meant there where two Jan 29 21:31:35 <[florian]> I hope so Jan 29 21:32:09 <[florian]> these refer to the external PHY don't they? Jan 29 21:32:17 <[florian]> for an external phy, that can become a mess, yes Jan 29 21:33:05 well we do disable that bit, says to me that the internal comes online. External refering to the switches phy's Jan 29 21:33:37 <[florian]> actually both an external and a switch would look identical in the probing Jan 29 21:33:55 <[florian]> yeah, that makes sense Jan 29 21:34:54 well the internals doo show up on the mdio alive too and you can connect to them, which is how I was hoping to get around this blasted fixed phy bus problem. Jan 29 21:35:16 <[florian]> so we would need a driver for the internal phy Jan 29 21:35:21 <[florian]> very much like brcm63xx Jan 29 21:35:36 well I think the generic one might be sufficient Jan 29 21:35:52 <[florian]> you are right, that could do it Jan 29 21:36:07 <[florian]> so in the probing logic Jan 29 21:36:19 <[florian]> you would disable the internal phy, to see if there is something external, like a phy or switch Jan 29 21:36:22 might need a fixup for the case of an unsupported switch where the mii bits are not being properly set with the host.... un less the switch is kind enough to pass that on Jan 29 21:36:26 <[florian]> it nothing shows up, enable the internal phy? Jan 29 21:36:49 <[florian]> I think this is where the adm6996 comes in Jan 29 21:37:10 <[florian]> its "control" interface is not accessible, because you write settings to an eeprom, and that's how it configures stuff Jan 29 21:37:31 <[florian]> still, you would read the link status register as being valid Jan 29 21:37:56 yeh so the stack can be happy Jan 29 21:38:14 well you dont need to enable or disable anything to detect a switch on the mdio bus I know that Jan 29 21:38:16 <[florian]> yes, but that would be the fixed phy driver handling it Jan 29 21:38:48 <[florian]> such adm6996 switches should not themselves as being alive on the mdio bus Jan 29 21:38:55 <[florian]> +show Jan 29 21:39:28 so how about this Jan 29 21:41:41 for 7300 and 72/100 atleast: detect switch, if its found disable the internal PHY on cpmac low and be happy, if its not found keep the internal on and connect to it and fix up so it shows link up.. if it needs it which it might not switch might negotiate with it properly Jan 29 21:42:10 should work in the cases of the fritz box aswell as you connect direct to the internal Jan 29 21:43:01 if we ever had a 7300 with a switch on high and low we would be a bit stuck but I havn't seen anything like that.... Jan 29 21:43:25 <[florian]> I am not even sure this is possible hardware wise Jan 29 21:43:44 <[florian]> that looks pretty good to me Jan 29 21:44:09 <[florian]> I am trying to understand in which case would adm6996 fall Jan 29 21:44:41 <[florian]> I hope that the interla phy is going to show up with valid identifier registers so we can detect it Jan 29 21:44:55 <[florian]> and if we do not see it, just assume this is an adm6996 we cannot yet control Jan 29 21:45:48 <[florian]> I was thinking about modifying the switch driver to try all the remaning gpios in various configureations Jan 29 21:45:55 <[florian]> the kmod-switch-adm that is Jan 29 21:46:47 well yeh if we cant see a switch on the mdio so we assume none or adm6996, connect to the internal phy and see if the generic driver can run with it, the adm might negotiate a link, I dont have one to check the status bits Jan 29 21:47:06 <[florian]> I am not sure about that Jan 29 21:47:11 <[florian]> I think it would Jan 29 21:47:22 <[florian]> but you would not be able to read its id Jan 29 21:47:40 sorry which id? Jan 29 21:48:02 <[florian]> register 2&3 containing the phy identifier Jan 29 21:49:10 is that required for the generic driver to work? doesn't that only matter when you want to make your own driver? Jan 29 21:50:02 <[florian]> if they contain 0 or 0xffff, which afaik will, generic would not be able to drive such a phy Jan 29 21:50:12 <[florian]> which I think is a genuine assumption Jan 29 21:51:17 really? that seems strage to me that it would care what device its working on, just read the control bits and work hmm Jan 29 21:52:08 <[florian]> it's been a while since I did not see the code Jan 29 21:52:23 <[florian]> but in the case of adm6996, generic PHY was not picked up Jan 29 21:52:49 <[florian]> that's why we need to fallback to fixed phy Jan 29 21:53:13 when you say generic was bit picked up what do you mean, sorry? Jan 29 21:53:18 *not Jan 29 21:53:27 <[florian]> I mean, the generic phy driver Jan 29 21:53:47 <[florian]> which is the fallback when no specific PHY driver can be found Jan 29 21:53:56 <[florian]> but the ID registers are valid Jan 29 21:54:39 dont you initiate the generic by attempting to connect to the phy it doesn't have a driver for, not on scan time? Jan 29 21:55:16 <[florian]> it reads the identifier registers and lookup the phy in the matching table Jan 29 21:55:39 thats what I gleaned from the phy kernel docs anyway Jan 29 21:55:39 <[florian]> if no driver is found, it registers the generic driver for that phy Jan 29 21:56:55 hmmmm ok, do you happen to have a adm6996 there? Jan 29 21:57:07 <[florian]> fortunately, yes :) Jan 29 21:57:52 grand easy to test, could you give a go blindly trying to attach to PHY31 and see what happens? Jan 29 21:58:56 <[florian]> not right now, but sure I would do that Jan 29 21:59:17 <[florian]> I think that was the one being picked up anyway Jan 29 21:59:34 yeh ofcourse :) Jan 29 22:02:21 now how does one find a leak, and why does it pop up in .36 I did notice they introduced some helpers to the net stuff.... Jan 29 22:03:30 <[florian]> well, if you are stripping 2 bytes, and only freeing size - 2, that's where it comes from Jan 29 22:04:16 <[florian]> if the packet is valid Jan 29 22:04:21 <[florian]> it should be freed by uppoer layers Jan 29 22:05:57 <[florian]> skb_pull should be doing its job just fine Jan 29 22:06:53 florian * r25244 /trunk/package/kernel/modules/netdevices.mk: [package] kmod-via-velocity depends on kmod-crc-ccitt (#8730) Jan 29 22:06:56 florian * r25245 /trunk/package/udev/Makefile: [package] udev: install development libraries in staging dir (#8370) Jan 29 22:09:45 florian * r25246 /packages/net/ndyndns/ (5 files in 3 dirs): [package] update ndyndns to 2.1 (#8732) Jan 29 22:09:46 florian * r25247 /packages/libs/libevent2/ (. Makefile): [package] add libevent2 (#8702) Jan 29 22:09:49 florian * r25248 /packages/net/ (lighttpd/Makefile net-snmp/Makefile): [package] convert lighttpd and net-snmp to use autoconf_bool for ipv6 Jan 29 22:09:51 florian * r25249 /packages/net/ipsec-tools/Makefile: [package] ipsec-tools: enable ipv6 after r17009 (#8182) Jan 29 22:09:52 florian * r25250 /packages/multimedia/imagemagick/ (. Makefile): [package] add imagemagick (#8430) Jan 29 22:23:34 <[florian]> Wipster: I do not really know when I will be able to test the cpmac patches, so when you have something for me to review/test, just drop me an email Jan 29 22:24:35 ok do you want .36 patches or to get current trunk working before? Jan 29 22:25:08 <[florian]> whichever is the simpler for you Jan 29 22:25:13 <[florian]> I will do the forward porting if needed Jan 29 22:30:34 ok sure Jan 29 22:40:51 ok, the r25238 is building correctly on orion Jan 29 22:43:49 when adding CONFIG_TEST_LIST_SORT to the config-default Jan 29 22:43:57 # CONFIG_TEST_LIST_SORT is not set Jan 29 23:11:03 [florian], what is the problem with the adm6996 switch? a while back I saw some mailing list stuff about an swconfig driver? Jan 29 23:43:39 i understand now why cifs doesnt include module dependencies for md5 and hmac modules Jan 29 23:44:01 ath9k module may be need to check for aes compiled in kernel Jan 29 23:44:14 =y Jan 29 23:44:39 instead of kmod-crypto-aes Jan 29 23:44:49 aes can also be in hardware Jan 29 23:44:55 crypto_mv_cesa Jan 29 23:45:07 or some other cpu crypto Jan 29 23:45:15 like via padlock Jan 30 00:57:11 jow * r25251 /packages/net/miniupnpd/ (Makefile files/miniupnpd.init): [packages] miniupnpd: add option to enable NAT-PMP (#8747) Jan 30 01:16:41 xMff: W.r.t my quick/dirty hack on subversion using libtool from alsa-lib-1.0.23 package, I understood your remarks that that is an incorrect approach. For me, this is just temporarily until OpenWRT fixes the subversion compilation, For now, the compiled binary works just fine on my Seagate DockStar (so far). Jan 30 01:25:47 swalker * r25252 /packages/multimedia/imagemagick/Makefile: [packages] imagemagick: remove carriage returns Jan 30 02:57:06 build #73 of ppc40x is complete: Failure [failed shell] Build details are at http://tksite.gotdns.org:8010/builders/ppc40x/builds/73 **** ENDING LOGGING AT Sun Jan 30 02:59:57 2011