**** BEGIN LOGGING AT Sun May 09 02:59:56 2010 May 09 03:55:52 build #55 of octeon is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/octeon/builds/55 May 09 09:07:58 arteq * r21407 /packages/net/nzbget/Makefile: [packages] nzbget update to 0.7.0 May 09 09:25:43 florian * r21408 /trunk/target/linux/ (4 files in 4 dirs): [kernel] make etrax samsung flash patch generic (#6552) May 09 12:51:01 [florian]: ping May 09 12:54:05 acoul: ping May 09 14:47:51 'afternoon May 09 14:48:25 cshore: hi there, are you around ? May 09 15:10:13 Mr_Smoke: here May 09 15:11:39 Mr_Smoke: ordering issue(s)? May 09 16:33:59 <[florian]> rtz2: pong May 09 16:34:02 <[florian]> rtz2: sorry for the delay May 09 16:35:24 [florian]: no problem May 09 16:35:54 [florian]: anyway, I wanted to do some libphy experiments and tried to compile a .32 kernel May 09 16:36:15 [florian]: to put it nicely, your sb patch doesn't work May 09 16:36:41 I get NULL pointer derefernces in 3 places May 09 16:37:26 [florian]: I kinda doubt it ever worked and one of the problems is not straight forward to fix May 09 16:37:36 [florian]: one moment, let me look it up May 09 16:37:58 <[florian]> rtz2: humm crap I see nothing obvious that could lead to a null pointer deref May 09 16:40:19 [florian]: the first problem is here: .driver_data = &rdc321x_wdt_pdata, May 09 16:41:02 [florian]: you write to driver_data, but the actual drivers try to access the rdc321x_wdt_pdata structure over platform_data May 09 16:41:28 <[florian]> rtz2: correct May 09 16:41:52 [florian]: the second problem is here and it's harder: return mfd_add_devices(&pdev->dev, -1, rdc321x_sb_cells, ARRAY_SIZE(rdc321x_sb_cells), NULL, 0); May 09 16:42:20 [florian]: NULL should actually be a pointer to the parent IORESOURCE_MEM May 09 16:42:40 for the client devices May 09 16:42:48 [florian]: problem is, you don't have a parent ioresource May 09 16:43:13 <[florian]> we could use the pci device parent ioresource May 09 16:43:17 <[florian]> that's possible May 09 16:43:35 as far as I can see, there isn't any May 09 16:43:49 that's because it's not an actual memory region, it's a bunch of registers in the config space of the pci bus May 09 16:43:52 not a memory region May 09 16:44:21 <[florian]> when I did the patch I did not have that issue, I am surprised we have this now May 09 16:44:30 [florian]: i'm pretty sure IORESOURCE_MEM is intended for real memory mapped resources May 09 16:45:25 [florian]: it's possible to fix this by creating some kind of pseudo resource, but it's kinda overkill and imho also kinda wrong May 09 16:45:31 <[florian]> indeed May 09 16:45:39 I have a patch, one moment May 09 16:46:03 [florian]: it simply uses the defines for the registers directly in the driver May 09 16:46:19 build #59 of brcm_2_4 is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/brcm_2_4/builds/59 May 09 16:46:37 <[florian]> humm actually, the idea to pass a resource to the other drivers was from the MFD maintainer May 09 16:46:42 <[florian]> I tested the initial version only May 09 16:47:10 <[florian]> which introduced accessors from the southbridge device, which should be used by the underlying drivers May 09 16:47:23 <[florian]> this is why I did not caught the null pointer deref in the second version of the patch May 09 16:48:04 [florian]: well, I think it's really overkill to abstract the register locations May 09 16:48:15 [florian]: it's not done anywhere else May 09 16:48:51 <[florian]> rtz2: well yes, but that was kind of suggested by the MFD people May 09 16:48:51 [florian]: http://openwrt.pastebin.com/rhXFvVw3 May 09 16:49:04 ... May 09 16:49:29 and what do they suggest we use as the parent resource? May 09 16:49:55 <[florian]> they did not suggest anything May 09 16:50:06 <[florian]> but I was not using it initially so this was not noticeable May 09 16:50:38 [florian]: well, this is how I would do it, but in the end, it's not my decision May 09 16:51:00 <[florian]> rtz2: your patch looks good, however I would not remove the platform_data stuff, rather use the existing one May 09 16:51:34 <[florian]> also, for minimum modifications, we could still make the register values be defined at init time May 09 16:52:30 [florian]: I used the parent of the platform_device to get the pointer to the south bridge, this isn't a good idea? May 09 16:52:36 [florian]: what do you mean? May 09 16:53:10 by "we could still make the register values be defined at init time" ? May 09 16:53:13 <[florian]> I mean for instance that you could do that instead of removing the variables: rdc321x_wdt_device.base_reg = RDC321X_WDT_CTRL; May 09 16:54:44 [florian]: well, maybe to keep the patch small (is it already commit into mainlie), but I don't like it as a permanent solution May 09 16:54:53 I mean, what's the point? May 09 16:55:06 <[florian]> it's cleaner, that's all May 09 16:55:12 <[florian]> more like the way of other drivers are made May 09 16:56:46 <[florian]> anyway that's really aestethic stuff, and not important May 09 16:57:13 <[florian]> I am working on other stuff right now, but I will commit your patch later in the evening May 09 16:57:43 [florian]: other drivers I know also access registers directly with a define instead of creating a new variable which basically is nothing more then an alias to a define May 09 16:57:45 ok May 09 16:58:19 [florian]: and there is another problem. did you have time to try gcc 4.5 with rdc? May 09 16:58:19 <[florian]> rtz2: well usually they hold a base address pointer and that's all May 09 16:58:25 <[florian]> no, I did not May 09 16:58:43 [florian]: well, the base pointer is in the southbridge May 09 16:58:48 <[florian]> yes May 09 16:59:07 [florian]: i did, and the results aren't pretty May 09 16:59:18 [florian]: sed crashs, but I could probably fix this May 09 16:59:32 [florian]: worse is the fact, that the network doesn't work May 09 17:00:01 I don't get any error message, but it doesn't transmit any data over the wire May 09 17:00:24 <[florian]> is the compiler trying to be smarter than it should? May 09 17:00:24 [florian]: I have no clue, where the problem is May 09 17:00:29 maybe May 09 17:00:37 I have absolutly no idea May 09 17:01:28 [florian]: I can't track this down May 09 17:01:28 <[florian]> that's not really encouraging :p May 09 17:02:23 [florian]: biggest problem is, that I can't netboot the device, does the bifferboard to the r8610 support it? May 09 17:02:52 <[florian]> yes they do May 09 17:02:52 or May 09 17:02:59 <[florian]> they have a "real" bootloader on them May 09 17:03:05 <[florian]> not some crappy redboot version May 09 17:03:32 [florian]: could you try to take a look at it? May 09 17:03:59 <[florian]> I guess yes, certainly May 09 17:04:15 [florian]: because I get flash errors again, and I don't want to reflash my device dozends of times May 09 17:04:25 ping Mr_Smoke May 09 17:04:43 [florian]: if the network works, I can fix the other problems by myself May 09 17:04:49 [florian]: ok, thanks May 09 17:20:48 [florian]: ahh crap, I gave you a wrong version May 09 17:23:11 of the patch May 09 17:23:30 <[florian]> rtz2: np, I think I will be able to fix it myself and like I intend it to minimize the changes :p May 09 17:24:43 [florian]: ok May 09 17:25:49 crap, looks like I made a slight rm mistake ... May 09 17:26:10 [florian]: when are you going to commit it (estimated)? May 09 17:26:36 <[florian]> rtz2: in about 2h, the time I need to finish a presentation May 09 17:27:02 [florian]: ok, no problem May 09 17:31:19 <[florian]> rtz2: not that your patch is not wrong, but when I push that stuff mainline I need to minimize the number of changes at a time May 09 17:31:33 <[florian]> rtz2: though I agree with you, most of the stuff is overkill May 09 17:32:22 [florian]: do you plan to create a second patch for that? May 09 17:33:06 <[florian]> rtz2: no, I will rework the existing one May 09 17:33:38 ok May 09 17:37:57 [florian]: if you are at it, could you also move the misc_register call in the wdt_probe to the end of the function? May 09 17:38:06 [florian]: otherwise, this could craete race conditions May 09 17:38:49 [florian]: wait, it already is May 09 17:38:56 [florian]: sorry, I got confused May 09 17:51:23 updated openwrt/upstream, http://home.comcast.net/~sdwalker/uscan/uscan.shtml May 09 18:03:59 swalker: how do generate that list? May 09 18:07:58 larsc: a slightly old copy of the scripts are at http://home.comcast.net/~sdwalker/uscan/uscan.tar.gz May 09 18:09:23 [florian]: ok, this is the complete patch I used: http://openwrt.pastebin.com/D3QLbrra May 09 18:09:38 [florian]: the patch is not minimal, but the resulting files are :) May 09 18:09:51 <[florian]> rtz2: how stable was acx-mac80211 when you tested it? May 09 18:09:57 <[florian]> rtz2: here, it is quite flaky May 09 18:10:11 <[florian]> rtz2: the dhcp client fails sending its select for the IP for instance May 09 18:10:18 <[florian]> acx: phy0: tx error 0x20, buf 13! (excessive Tx retries due to either distance too high or unable to Tx or Tx frame error - try changing 'iwconfig txpower XXX' or 'sens'itivity or 'retry') May 09 18:10:32 swalker: nice May 09 18:10:37 [florian]: I didn't use dhcp May 09 18:11:38 [florian]: but I did pipe data with nc over the network for about 40 mins without a problem May 09 18:11:55 [florian]: and had it running all in all for about 3h May 09 18:12:03 <[florian]> rtz2: might be due to my model May 09 18:12:03 [florian]: maybe you have a different phy May 09 18:12:07 <[florian]> rtz2: yep May 09 18:13:40 florian * r21409 /trunk/target/linux/ar7/patches-2.6.32/130-clocks_devices_init.patch: [ar7] rework 130-clocks_devices_init.patch to make it more robust May 09 18:13:45 florian * r21410 /trunk/target/linux/ar7/patches-2.6.32/ (3 files): [ar7] refresh kernel patches May 09 18:13:52 florian * r21411 /trunk/target/linux/generic-2.6/patches-2.6.32/ (19 files): [kernel] refresh 2.6.32 patches May 09 18:15:52 xMff: yup May 09 18:16:11 swalker: nice indeed. where can i send patches? :) May 09 18:22:13 larsc: I'll pm you an email address if you have any May 09 18:22:28 ok May 09 18:24:52 cshore: I was advised to get in touch with you .... there's this problem where backfire in failsafe mode won't bring eth0 up ... aparently pi_ifname fails to default to eth0 May 09 18:31:28 Mr_Smoke: try this: http://paste.tksite.gotdns.org/d1365d33c May 09 19:00:29 xMff: looks about right indeed, I'll try it later tonight if I can May 09 19:00:41 ok May 09 19:19:28 build #62 of brcm63xx is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/brcm63xx/builds/62 May 09 19:55:43 build #59 of brcm47xx is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/brcm47xx/builds/59 May 09 19:59:43 [florian]: you still here? May 09 19:59:58 [florian]: I found the problem with the network driver May 09 20:00:07 [florian]: it's not gcc 4.5 May 09 20:00:31 [florian]: it also happens with gcc4.1 on .32, not sure how i missed this May 09 20:01:02 [florian]: the network driver from .30 with gcc 4.5 and the rest of the kernel at .32 works fine May 09 20:40:45 xMff: oddly enough, the patch failed May 09 20:40:48 xMff: http://pastebin.com/mSvrN6ft May 09 20:41:00 I'll patch it by hand, although I'm not sure why it failed May 09 20:41:49 whitespace foo maybe May 09 20:42:10 Could be May 09 20:46:09 Building now May 09 21:17:21 build #51 of etrax is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/etrax/builds/51 May 09 22:24:15 mirko * r21412 /trunk/target/linux/xburst/ (modules.mk qi_lb60/target.mk): sound-soc-qi_lb60: rename package as underscores are not allowed by opkg May 09 23:04:04 build #51 of mpc52xx is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/mpc52xx/builds/51 May 10 00:54:39 build #57 of sibyte is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/sibyte/builds/57 May 10 00:55:27 craigc * r21413 /packages/net/multiwan/ (Makefile files/usr/bin/multiwan): May 10 00:55:28 [packages] multiwan: May 10 00:55:28 - Now makes use of statistic module/random for better equal multipath load balancing May 10 00:55:28 - Seperated mangle rules out for better connmark handling May 10 02:04:54 craigc * r21414 /packages/net/multiwan/ (Makefile files/usr/bin/multiwan): May 10 02:04:54 [packages] multiwan: Changed failover probabilities for May 10 02:04:54 MultiWanLoadBalancer May 10 02:38:26 build #51 of ifxmips is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/ifxmips/builds/51 **** ENDING LOGGING AT Mon May 10 02:59:57 2010