**** BEGIN LOGGING AT Fri Apr 08 02:59:58 2011 Apr 08 03:18:25 the poki bowl gave up surprisingly little fight. Apr 08 03:34:51 build #2 of uml is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/uml/builds/2 Apr 08 03:58:28 build #2 of orion is complete: Failure [failed compile_7] Build details are at http://tksite.gotdns.org:8010/builders/orion/builds/2 Apr 08 04:09:36 frogonwheels: it's on my todo list, but I'm not sure when I will actually get a chance to do it Apr 08 04:25:48 build #3 of x86 is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/x86/builds/3 Apr 08 05:11:59 build #2 of lantiq is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/lantiq/builds/2 Apr 08 06:00:58 build #3 of at91 is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/at91/builds/3 Apr 08 06:18:17 build #3 of ubicom32 is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/ubicom32/builds/3 Apr 08 08:25:07 build #2 of atheros is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/atheros/builds/2 Apr 08 10:54:15 How do I disable the OpenWRT's default setting that calls for $(DISABLE_NLS) option? Apr 08 10:55:59 Some software package I am working on to port into OpenWRT will complain with this error message (configure: error: unrecognized options: --disable-nls). Apr 08 11:10:38 just ignore the message Apr 08 11:14:33 mb__: I can't ignore the message because the compilation just terminated after the message. Apr 08 11:14:57 then its crappy software Apr 08 11:15:34 he he he. Perhaps. The package is mldokey (http://mldonkey.sourceforge.net/Main_Page) Apr 08 11:33:56 mazilo: why not just patch the configure script to ignore unrecognized options? Apr 08 11:34:32 KanjiMonster: That would be the other option I had in mind. Apr 08 11:35:03 KanjiMonster: I am hoping the $(DISABLE_NLS) can be turned off to see what other messages will follow. Apr 08 11:35:40 DISABLE_NLS:= Apr 08 11:35:41 ? Apr 08 12:19:15 nbd * r26532 /trunk/package/mac80211/patches/ (300-pending_work.patch 510-ath9k_intr_mitigation_tweak.patch): ath9k: improve the rx dma stop fix, add more debugging output in case the issue still occurs Apr 08 13:22:03 What is the differences in PKG_BUILD_DEPENDS vs DEPENDS ? Apr 08 13:22:36 one is build dependency, the other is build + opkg + menuconfig dependency Apr 08 13:22:52 I noticed no mentioned of SELECTS dependant package in 'make menuconfig' when using PKG_BUILD_DEPENDS. Apr 08 13:23:19 IC. So, if I use PKG_BUILD_DEPENDS, will the depedant packages be built? Apr 08 13:24:33 select is a dependency with + in front of it Apr 08 13:24:43 in DEPENDS Apr 08 13:24:53 if you put somethin in DEPENDS, you don't need a PKG_BUILD_DEPENDS for that Apr 08 13:25:58 IC. Do I need to use DPENDS if PKG_BUILD_DEPENDS is already there? Apr 08 13:26:43 well, depends on what you want to use it for Apr 08 13:26:54 as i said, PKG_BUILD_DEPENDS covers *only* build dependencies Apr 08 13:26:55 nothing else Apr 08 13:27:27 so if an opkg package should depend on another one being installed as well, then PKG_BUILD_DEPENDS should not be used for that and you need DEPENDS in the package Apr 08 13:30:40 Let's say, I have specified PKG_BUILD_DEPENDS:=libcares without DEPENDS in an X package. The compilation will first build libcares to satisfies the build dependency before building the X package. If I specified DEPENDS:=+libcares and no PKG_BUILD_DEPENDS, the compilation will also build libcares to satisfy the build dependency before building the X package, except it will also install libcares package in the firmware. right? Apr 08 13:32:39 yes Apr 08 13:33:18 KanjiMonster: Thanks. So, it is better to use DEPENDS if the built package requires the libraries to run. Apr 08 13:33:28 right Apr 08 13:34:13 KanjiMonster: Got it. Thanks. Apr 08 15:12:43 hauke * r26533 /trunk/target/linux/brcm47xx/Makefile: Apr 08 15:12:43 brcm47xx: upgrade to kernel 2.6.27.6. Apr 08 15:12:43 This should be save now. Apr 08 16:00:21 how should I test which gpio maps to what led to make the correct assignment when describing a new board? Apr 08 16:07:53 Oops. Just did an 'svn up' to r26533 and compiled compiled for my WGT634U. Now, both telnet and ssh return with a connection refused message eventhough no problems with Internet connection. :( Apr 08 16:09:45 Web GUI looks OK and is accessible so far. Apr 08 16:17:57 hauke * r26534 /trunk/package/mac80211/Makefile: Apr 08 16:17:57 mac80211: add Intel wireless drivers. Apr 08 16:17:57 This adds the Intel wireless drivers for their normal cards. Apr 08 16:17:57 Thank you framer99 for the patch, I extended it a little bit. Apr 08 16:17:57 This closes #7227 Apr 08 16:39:42 build #3 of brcm63xx is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/brcm63xx/builds/3 Apr 08 17:43:23 anyone venture a guess why this build failed? http://tksite.gotdns.org:8010/builders/x86/builds/3 Apr 08 17:49:13 build #2 of ppc40x is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/ppc40x/builds/2 Apr 08 17:50:55 nbd: so you'd use PKG_BUILD_DEPENDS for host tools and static libraries? Apr 08 17:51:16 yes Apr 08 17:51:39 jow_laptop: can you have another look at those two patchsets please? Apr 08 17:55:42 build #2 of ramips is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/ramips/builds/2 Apr 08 17:57:27 build #3 of s3c24xx is complete: Failure [failed compile_10] Build details are at http://tksite.gotdns.org:8010/builders/s3c24xx/builds/3 Apr 08 17:57:51 I looked at the build failure of the x86 image, but I can't tell why it's failing. Apr 08 18:13:45 the usual kernel bump(s) leading to missing symbol(s)? Apr 08 18:17:27 swalker: that failure doesn't happen for me, and I think I sent a list of missing symbol for x86 for 2.6.37 about a month ago. Apr 08 18:17:42 " COPS LocalTalk PC support (COPS) [N/m/?] (NEW) " => "command timed out: 1200 seconds without output, killing pid 24020" - yepp, missing symbol(s) Apr 08 18:18:16 philipp64|laptop: did you enable *all* modules? sometimes some missing symbols only become visible after certain subsystems get enabled Apr 08 18:20:47 otoh this looks like a symbol missing in the generic config Apr 08 18:24:40 philipp64|laptop: depends on DEV_APPLETALK && (ISA || EISA) - that why it doesn't show up for other archs except x86 Apr 08 18:42:28 build #2 of ar7 is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/ar7/builds/2 Apr 08 18:49:48 KanjiMonster: where are you looking? All I saw was TREE_RCU... Apr 08 18:50:55 philipp64|laptop: http://tksite.gotdns.org:8010/builders/x86/builds/3/steps/compile_4/logs/stdio <- at the bottom Apr 08 18:52:51 philipp64|laptop: enabling kmod-appletalk is probably enough to reproduce it ;) Apr 08 18:55:49 nbd * r26535 /branches/backfire/scripts/kconfig.pl: scripts/kconfig.pl: backport changes from trunk Apr 08 18:55:52 nbd * r26536 /branches/backfire/package/mac80211/ (28 files in 2 dirs): mac80211: update to trunk as of r26534 Apr 08 18:57:37 btw, just wanted to report that someone running a custom backfire build had lots of stuck beacon problems and crappy throughput, switched to ath5k and was much better. Apr 08 18:58:44 sounds good Apr 08 18:59:29 i'll look into ath5k support for AHB today Apr 08 18:59:51 i hope to hear more reports about ath5k stability, hopefully we can eliminate madwifi from the defaults soon Apr 08 19:00:11 build #2 of cobalt is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/cobalt/builds/2 Apr 08 19:13:59 build #2 of au1000 is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/au1000/builds/2 Apr 08 19:21:18 build #2 of ixp4xx is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/ixp4xx/builds/2 Apr 08 19:22:44 hauke * r26537 /trunk/package/broadcom-diag/src/diag.c: Apr 08 19:22:44 brcm47xx: add Netgear WNR834BV1 Apr 08 19:22:44 Thank you realopty for the patch. Apr 08 19:22:44 This closes #7702 Apr 08 19:25:28 KanjiMonster: it looks like patch 591 was never applied. Apr 08 19:26:00 that was 3 months ago. Apr 08 19:27:24 philipp64|laptop: I don't see any patch 591 Apr 08 19:27:31 nbd, can you do adhoc + ap with ath5k/ath9k ? Apr 08 19:28:17 build #2 of kirkwood is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/kirkwood/builds/2 Apr 08 19:28:23 russell--: no Apr 08 19:28:34 :-( Apr 08 19:28:40 even though it's a non-standard hack i'll probably add it to ath9k soon because many people are requesting it Apr 08 19:28:55 yeah, i need it for mesh silliness Apr 08 19:28:56 i don't know enough about the beacon code in ath5k to check if it's feasible though Apr 08 19:29:17 however with recent changes in ath9k and some cleanups from me, it has become easier to enable this Apr 08 19:33:13 btw, i've managed to printf-debug my way to identify pthread_cancel as the place iftop goes to die ... i think maybe i knew that before, but i've reconfirmed Apr 08 19:34:26 pthread_cancel is only one part to this Apr 08 19:34:30 but not the part we're looking for Apr 08 19:34:39 pthread_cancel kills a child thread Apr 08 19:34:45 but i think the abort() comes from the child thread itself Apr 08 19:34:59 triggered by pthread_cancel from the other one Apr 08 19:37:49 * russell-- just getting setup to start sprinkling more printfs Apr 08 19:42:07 build #2 of etrax is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/etrax/builds/2 Apr 08 19:56:47 KanjiMonster: http://patchwork.midlink.org/patch/591/ Apr 08 20:00:37 philipp64|laptop: the patch looks broken (and doesn't apply for me) Apr 08 20:03:27 I must have sent it inline instead of as an attachment... TB has been severely broken for the last couple of years. sigh. Apr 08 20:05:48 KanjiMonster: so what about: .config:3037:warning: override: TREE_RCU changes choice state Apr 08 20:06:05 does this need fixing? Apr 08 20:07:32 philipp64|laptop: I don't know - try looking at the part where the warning gets emitted Apr 08 20:19:59 KanjiMonster: fixed... apparently it's been there a while! http://patchwork.midlink.org/patch/877/ Apr 08 20:24:18 hauke * r26538 /packages/net/ddns-scripts/files/usr/lib/ddns/services: Apr 08 20:24:18 ddns-scripts: no-ip.com's update protocol has changed Apr 08 20:24:18 Thank you arokh and julian.calaby. Apr 08 20:24:18 This closes #9160 Apr 08 20:29:08 philipp64|laptop: looks okay, but the subject contradicts the content a bit ("for 2.6.37 and later" vs. modifying config-2.6.32 and .35) ;) Apr 08 20:37:11 well, I wrote that subject line, then realized that x86 has been stuck at 2.6.32 for a really long time, and hence it might not have been the 2.6.37 bump that broke. Apr 08 20:38:11 build #2 of sibyte is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/sibyte/builds/2 Apr 08 20:48:48 KanjiMonster: but feel free to commit it, even with a misleading subject line... :-) Apr 08 20:52:06 philipp64|laptop: you are missing the fact that I don't have any commit access to the core part ;-) (There's a reason why I'm sending patches instead of just committing it ;) Apr 08 20:52:18 [florian]: ping Apr 08 20:56:27 ah... nevermind. Apr 08 21:07:07 val = INTERNAL_SYSCALL (tgkill, err, 3, THREAD_GETMEM (THREAD_SELF, pid), pd->tid, SIGCANCEL); Apr 08 21:07:32 that's the last call in pthread_cancel.c before it goes boom Apr 08 21:12:59 if you want to trace what happens in the child thread, you need to start printf tracing the signal handler for SIGCANCEL Apr 08 21:29:24 build #2 of mpc52xx is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/mpc52xx/builds/2 Apr 08 21:31:54 can someone look at 871, 872, 877... who has commit rights for target/? thanks. Apr 08 21:32:13 * russell-- is looking at abort() calls in pthreads land atm Apr 08 21:50:37 xMff: ping Apr 08 21:53:29 hmm. that didn't work Apr 08 21:54:12 nbd * r26539 /trunk/package/kernel/modules/netdevices.mk: kernel: include firmware in the e100 package Apr 08 21:54:38 nbd: Felix, can you do a few trivial commits please? Apr 08 21:54:59 busy with other stuff right now Apr 08 21:55:29 I need to make friends with someone on the core development team on my continent. :-) Apr 08 21:58:42 hehe Apr 08 22:09:22 * russell-- found/instrumented sigcancel_handler Apr 08 22:09:30 compiling now Apr 08 22:12:27 nbd: I've been thinking about doing cleanup work for the x86 stuff, for instance making "generic" be more appropriate for a desktop PC, and coming up with subtargets for the alix and net4801 like I did for the net5501... but I don't want to do so without core commit rights because it would be an impossibly slow process otherwise. Apr 08 22:16:23 preliminary results suggest it's never called Apr 08 22:16:27 checking ... Apr 08 22:19:24 philipp64|laptop: what's wrong with developing in your own git branch? Apr 08 22:23:14 nbd: yeah, sigcancel_handler is never called Apr 08 22:24:35 hm, odd Apr 08 22:24:37 * nbd looks Apr 08 22:25:04 uClibc-0.9.32/libpthread/nptl/init.c Apr 08 22:32:33 * russell-- is doing fprintf(stderr,"uniquestring\n"); fflush(stderr); for debugging Apr 08 22:38:29 <_trine> yes Apr 08 22:43:10 _trine: ping Apr 08 22:43:29 <_trine> pong Apr 08 22:45:31 russell--: I could, but what would be the point of getting that deeply involved if I'm still going to be on the outside looking in? Apr 08 22:46:45 part of the payoff of that investment in the learning curve should conceivably be empowerment, right? Apr 08 22:46:51 that sounds kind of defeatist Apr 08 22:46:59 how so? Apr 08 22:47:02 distributed development++ Apr 08 22:47:18 kind of the whole point of git Apr 08 22:47:50 it makes sense more when the community size is hundreds of contributes with wildly divergent axis of interest... like Linux. Apr 08 22:47:54 we're not that big. Apr 08 22:48:02 *contirbutors Apr 08 22:48:05 grrrr. Apr 08 22:48:27 so develop your patches and publish them, you can be happy locally in the meantime Apr 08 22:48:59 don't let those mean core developers get in your way Apr 08 22:49:13 those mean bastards ;) Apr 08 22:49:49 it sounds simpler than it is. Apr 08 22:49:54 build #2 of avr32 is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/avr32/builds/2 Apr 08 22:50:12 patches that languish too long have to be updated periodically... creating unnecessary work for the contributor. Apr 08 22:50:57 what your suggesting works a lot better if patches submitted had a bounded lifetime before being accepted, but they don't. Apr 08 22:51:21 updating patches is easy, especially if they touch areas that rarely get updated Apr 08 22:51:27 you just need to have a proper process for it Apr 08 22:51:29 is anyone else touching ... yeah Apr 08 22:52:18 if you maintain your git tree, one way to keep it simple is to make your changes, constantly rebase against latest and occasionally post your full patch series Apr 08 22:52:51 that's how i do my work on linux-wireless Apr 08 22:53:00 my patches sometimes also take a while to be accepted there Apr 08 22:53:03 that's counter-intuitive. if getting a single patch integrated is non-deterministic, then getting a whole series in will be that much more difficult. Apr 08 22:53:10 so i just let them sit in my tree Apr 08 22:53:21 and i can actually easily track the acceptance process whenever i do git rebase Apr 08 22:53:26 no pulls? Apr 08 22:53:31 because patches that were accepted automatically get dropped Apr 08 22:53:40 sn9: i like linear history Apr 08 22:53:47 especially when working with a repo that is stored in svn Apr 08 22:54:06 keeping a rebased tree ensures that anybody can find relevant changes with minimum effort Apr 08 22:54:29 to each their own Apr 08 22:55:26 philipp64|laptop: i would think a whole series that accomplished something worthy would be more attractive than individual steps where the progression and destination weren't so obvious Apr 08 22:56:04 so a point fix that addresses a build breakage... that's just going to sit around? Apr 08 22:56:43 I'm just playing devil's advocate here. I contribute to upwards of 30 projects. Apr 08 22:56:47 you were talking about a reorganization, not bug fixes Apr 08 22:57:13 we had a long discussion about improving the patch acceptance process Apr 08 22:57:18 right, and I'm talking about how reorganization can lower the hurdles to people getting involved. Apr 08 22:57:29 yes, we did. Apr 08 22:57:35 gregers just hasn't posted the summary yet Apr 08 22:57:48 so the implementation of the resulting consensus hasn't begun yet Apr 08 22:58:09 i saw enough of it to post patches to openwrt-devel and not trac Apr 08 22:58:10 I seem to remember that it was concluded that at some point, the core team needed to be expanded, or what was considered "core" needed to be shrunken. Apr 08 22:58:26 no, the conclusion was splitting the work for accepting the patch Apr 08 22:58:33 having core developers review changes first Apr 08 22:58:51 and then patch team members testing, collecting and applying the changes Apr 08 22:59:06 so platform ownership will continue to be the exclusive purview of the core team? Apr 08 22:59:24 rather than handing out ownership of individual platforms to non-core developers? Apr 08 22:59:59 there is no clear distinction between core and non-core developers Apr 08 23:00:25 that doesn't really answer the question... Apr 08 23:00:34 though not to extend the discussion i think some of the frustration was time to get patches in, that were outside some of "patchteams" jurisdiction :) Apr 08 23:01:22 yes, and the proposed fix was to have the team maintain a patch queue both for packages and for core stuff Apr 08 23:01:26 based on review feedback from core devs Apr 08 23:01:34 correct Apr 08 23:01:38 as the number of platforms grows, should their be more owners in the platform space? Apr 08 23:01:51 and if this patch queue is online as a git tree, it can get flushed into svn easily by anybody with the appropriate commit access Apr 08 23:03:04 if we can get this implemented properly, then the whole process will reduce the load of the people that have commit access Apr 08 23:03:15 which results in fewer people actually needing it Apr 08 23:03:24 so that would be a "no" then. Apr 08 23:03:55 a yes or no answer to the question is meaningless Apr 08 23:04:02 because there is no strict ownership of specific modules in openwrt Apr 08 23:04:12 not when it comes to setting people's expectations. Apr 08 23:04:42 their could be ownership... there are group permissions on directories and sub-trees in SVN. Apr 08 23:04:48 *there Apr 08 23:04:58 yes, but often components overlap Apr 08 23:05:09 and micro-managing permissions is bad, imho Apr 08 23:05:20 because it creates the feeling that people should only touch stuff in their specific part Apr 08 23:05:23 which would require collaboration... but that's already a pre-existing condition. Apr 08 23:05:26 if we can eliminate the commit access bottleneck Apr 08 23:05:46 by making patch acceptance faster even without giving out more and more svn accounts Apr 08 23:05:55 then people can just do their productive work on any part of the code Apr 08 23:06:00 and that's a big "if"... I'm suggesting that a plan-B should be considered. Apr 08 23:06:10 and he who puts most useful work into a specific component will be perceived as 'owning' it Apr 08 23:06:41 well, Kaloz is currently considered as owning the x86 stuff, but I haven't heard from him in 5 weeks. Apr 08 23:06:42 if you have a good plan B, we'll consider it Apr 08 23:06:52 but for now we're happy to even have one plan that appears workable Apr 08 23:06:56 that's an improvement compared to before Apr 08 23:07:27 so if the plan that we made gets implemented, it would make it easier for you to push in x86 changes as well Apr 08 23:07:39 having an entire (and not insubstantial) component area owned by a single person will always be a bottleneck. Apr 08 23:07:47 and when that starts working, i'll push some more for getting you commit access Apr 08 23:07:59 i'm really not saying you shouldn't have commit access Apr 08 23:08:11 ah, good... I'm glad you cleared that up. :-) Apr 08 23:08:14 but right now we have to fix our development process first Apr 08 23:08:40 okay, can nbd get back to solving my problem now? :-) Apr 08 23:08:46 like the Space Shuttle missions, it would be nice if everyone "cross trained" to be able to replace another mission member. Apr 08 23:09:01 just in case Jo gets sucked out an airlock, for instance. :-) Apr 08 23:09:06 russell--: i'm digging through the code, but running out of ideas Apr 08 23:09:46 someone on #uclibc made noises like there was a limited bit-field size for signals Apr 08 23:09:52 xMff: don't walk under any pianos or step in front of any buses. Apr 08 23:09:57 like, only 32 bits or something Apr 08 23:10:21 * russell-- didn't quite follow Apr 08 23:10:23 yeah, that's for normal signals, but sigcancel is an RT signal Apr 08 23:10:27 it's supposed to be handled differently Apr 08 23:10:29 iirc Apr 08 23:10:30 ah Apr 08 23:10:40 i've been comparing glibc and uclibc code and haven't found a significant difference yet Apr 08 23:10:55 someone else said something about signals numbering from one Apr 08 23:11:12 in which case 32 would be in the second word Apr 08 23:11:25 or not or something Apr 08 23:11:36 i.e. an off-by-one error or something Apr 08 23:12:49 but all that sigaction does is run a syscall Apr 08 23:12:59 can you give me a full strace again? Apr 08 23:14:04 http://personaltelco.net/~russell/strace-iftop.log Apr 08 23:16:02 Why my WGT634U spits out this error message (WGT634U user.info sysinit: mount: mounting /dev/sda1 on /tmp/overlay-disabled failed: No such device) as shown here (http://pastebin.com/n62cj90c) on lines #178 and #179 when trying to boot off of an external USB partition? Apr 08 23:27:05 russell--: please try this: edit libpthread/nptl/init.c Apr 08 23:27:08 look for this line: Apr 08 23:27:08 (void) __libc_sigaction (SIGCANCEL, &sa, NULL); Apr 08 23:27:19 okay Apr 08 23:27:20 right after the declaration of struct sigaction sa Apr 08 23:27:26 put a memset(&sa, 0, sizeof(sa)); Apr 08 23:27:37 okay Apr 08 23:28:06 after that i'd like a new strace log in a different location Apr 08 23:28:07 for comparison Apr 08 23:28:56 sure Apr 08 23:32:49 building Apr 08 23:33:33 you think reinstalling libpthread is sufficient to test? Apr 08 23:34:06 yes Apr 08 23:34:09 okay Apr 08 23:40:19 actually, i have a different theory Apr 08 23:40:25 i just looked at iftop Apr 08 23:40:32 maybe it's not an uclibc bug Apr 08 23:40:58 so iftop sets up a signal handler for SIGINT Apr 08 23:41:09 but it does so *before* pthread_create Apr 08 23:41:26 so you hit ctrl+c and now this happens: Apr 08 23:41:29 http://personaltelco.net/~russell/strace-iftop3.log Apr 08 23:41:38 the finish() function is called in *both* threads Apr 08 23:41:43 one calls SIGIOT for the other Apr 08 23:41:55 one was running main, the other one was running a select loop Apr 08 23:42:05 the select loop gets interrupted, jumps into the signal handler Apr 08 23:42:12 but SIGINT came before SIGCANCEL Apr 08 23:42:24 and now it's calling tgkill() on itself Apr 08 23:42:27 which kills it Apr 08 23:42:34 at least that matches my re-reading of the strace Apr 08 23:42:40 hmm Apr 08 23:43:02 try moving the sigaction call after the pthread_create in the iftop source Apr 08 23:43:08 see if that makes a difference Apr 08 23:43:26 okay Apr 08 23:43:30 the memset made no difference by the way Apr 08 23:43:35 yeah Apr 08 23:49:06 oh, but, i usually just press 'q', so SIGINT handler isn't invoked Apr 08 23:49:40 hm Apr 08 23:52:00 yeah, still aborts anyway Apr 09 00:00:13 weird, if i grep -ri in uClibc-0.9.32 for "unknown signal" i get binary-file hits but no source files Apr 09 00:13:54 i still can't reproduce the issue Apr 09 00:14:26 just tried it on a fresh build Apr 09 00:14:59 you're using the default compilers and everything, right? Apr 09 00:15:02 on what target? Apr 09 00:15:05 ar71xx Apr 09 00:15:23 hmm. i have only tried it on brcm47xx and atheros Apr 09 00:15:42 but, yeah, default everything at least initially Apr 09 00:16:06 can you show me the output of ./scripts/diffconfig.sh? Apr 09 00:18:13 http://www.personaltelco.net/~russell/diffconfig.log Apr 09 00:19:04 what's a Makefile that has an embedded /config (instead of sourcing a Config.in file)? Apr 09 00:19:12 i'm a few days behind HEAD at this point Apr 09 00:19:34 r26466 Apr 09 00:19:46 yeah, nothing relevant changed since Apr 09 00:19:57 the atheros test was more recent Apr 09 00:20:17 any command line arguments to iftop? Apr 09 00:20:28 i use iftop -i br-lan Apr 09 00:20:38 then type q Apr 09 00:20:48 you might need to do it a few times Apr 09 00:21:03 my atheros test worked normally the first two times, then failed thereafter Apr 09 00:21:13 ah Apr 09 00:21:15 i found a way to reproduce it Apr 09 00:21:21 if i keep my system busy, it happens Apr 09 00:21:49 ++ Apr 09 00:23:41 it was all working fine until around r25800 Apr 09 00:24:07 then we had the symbol resolution problem, and when that was resolved i was getting the abort Apr 09 00:40:50 philipp64|laptop: where are you located? Apr 09 00:40:59 normally Boise, ID. Apr 09 00:41:10 whois says you are in portland now Apr 09 00:41:13 right now I'm in Portland, OR doing work for Intel. Apr 09 00:41:16 nice Apr 09 00:41:22 * russell-- is in NE Apr 09 00:41:28 NE portland that is Apr 09 00:41:58 you should come help me climb on roofs and fix networks! Apr 09 00:42:14 we should grab a beer sometime at the Lucky Labrador. Apr 09 00:42:26 which one? Apr 09 00:42:37 there's more than one? Apr 09 00:42:47 there are 4, all of them are personaltelco nodes, btw Apr 09 00:42:57 that's new. the one I know of is on SE Hawthorne somewhere... Apr 09 00:43:08 yeah, that was first Apr 09 00:43:24 that's all that existed here when I last lived here (2005). Apr 09 00:43:36 there's one in multnomah village, one in NW and the newest is in N portland on killingsworth Apr 09 00:43:36 where do you work? Apr 09 00:43:42 at home! ;-) Apr 09 00:44:04 I tried that, but the pay wasn't very good and my boss was an a-hole... Apr 09 00:44:09 oh, wait... that was me. Apr 09 00:44:22 i'm a consultant for a scientific researcher dude, also president of personaltelco (volunteer) Apr 09 00:44:24 so I work for "the man" instead. Apr 09 00:44:33 cool Apr 09 00:45:00 how long are you in town? Apr 09 00:45:06 now you're making me google "personaltelco"... Apr 09 00:45:22 it varies on how much work I need to get done on-site. Apr 09 00:45:22 the CWN in portland Apr 09 00:45:52 I'll probably go to Boise tomorrow and come back middle of next week, if the next phase of work at Intel is funded. Apr 09 01:11:34 russell--: the debug code you added was not signal handler safe Apr 09 01:11:45 by calling a random syscall directly i could confirm that sigcancel_handler is in fact called Apr 09 01:11:47 heh Apr 09 01:11:58 (it showed up in strace when the issue occurred) Apr 09 01:15:41 are you still seeing the abort without debugging code? Apr 09 01:19:59 yes Apr 09 01:20:10 i'm currently using fcntl(__LINE__, 0) as a debug statement ;) Apr 09 01:21:33 _Unwind_ForcedUnwind is killing it Apr 09 01:22:57 i recall seeing that pop up wrt the unresolved symbol somehow Apr 09 01:24:23 it looks like it's trying to find some symbols Apr 09 01:24:28 and if it doesn't find them, it calls abort() Apr 09 01:25:48 the dummy fcntl call is surprisingly useful as a debug statement ;) Apr 09 01:26:10 * russell-- makes a note Apr 09 01:29:59 ok, i'm pretty sure the abort comes from within libgcc Apr 09 01:30:54 nbd++ Apr 09 01:33:45 i think i may have a potential fix Apr 09 01:34:00 go to libpthread/nptl Apr 09 01:34:01 edit unwind.c Apr 09 01:34:11 there's a line Apr 09 01:34:12 #ifdef HAVE_FORCED_UNWIND Apr 09 01:34:16 replace that with #if 0 Apr 09 01:35:15 okay Apr 09 01:35:31 with that change i can no longer reproduce the issue here Apr 09 01:39:58 building ... Apr 09 01:43:04 is there more than one? Apr 09 01:43:27 i got a build failure, cleaning up my patch slightly, retrying Apr 09 01:43:44 oh, right Apr 09 01:43:46 there is more than one Apr 09 01:43:53 the second one is the right one Apr 09 01:44:00 i'm currently testing a build with that define globally disabled Apr 09 01:44:07 to see if that works as well Apr 09 01:46:27 I see we have a Goldfish (Android Emulator) as a Target System. Is this for QEMU that can be run off of an AMD platform? Apr 09 01:47:02 yes Apr 09 01:47:18 russell--: removing that define also seems to work Apr 09 01:47:43 okay, i'm building again with the two-fix patch Apr 09 01:48:22 nbd: Cool. Apr 09 01:48:40 nbd: can you review 878 when you get a minute? Apr 09 01:49:26 philipp64|laptop: looks weird to me, why not just make a separate package for those tools Apr 09 01:50:30 I was just trying to follow the NTFS-3G example. Apr 09 01:51:56 ntfs-3g doesn't seem to be conditionally including extra stuff in its packages Apr 09 01:56:58 for what it's worth, "atm-tools" isn't generic tools at all, but support for "CLIP" (classic LAN IP over ATM encapsulation). the name is a bit of a misnomer. Apr 09 01:57:55 fee. Apr 09 01:57:57 oops Apr 09 01:58:00 feel free to clean it up Apr 09 02:22:27 respun as 879. Apr 09 02:28:30 hmm.... any other committers around, before it gets too late? Apr 09 02:30:40 nbd, i'm still seeing it Apr 09 02:31:01 * russell-- is going to recompile iftop without my debugging crap Apr 09 02:35:39 hmm. /me seems to have some lingering debugging crap ... **** ENDING LOGGING AT Sat Apr 09 02:59:57 2011