**** BEGIN LOGGING AT Sun Mar 04 02:59:59 2012 Mar 04 12:31:30 build #129 of rb532 is complete: Failure [failed compile_10] Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/129 Mar 04 13:10:02 juhosg * r30802 /trunk/target/linux/generic/config-3.2: linux/3.2: add missing NAND symbols Mar 04 13:10:04 juhosg * r30803 /trunk/target/linux/generic/config-3.3: linux/3.3: add missing config symbols Mar 04 13:10:06 juhosg * r30804 /trunk/target/linux/ppc40x/ (9 files in 2 dirs): ppc40x: preliminary support for 3.3 Mar 04 13:30:01 build #126 of ppc44x is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/126 Mar 04 15:23:37 jow * r30805 /trunk/package/base-files/ (Makefile files/etc/sysctl.conf): [package] base-files: enable conntrack accounting in sysctl. It used to be a compile time option which got deprecated Mar 04 16:24:13 jow * r30806 /trunk/package/uhttpd/ (Makefile src/uhttpd.c): [package] uhttpd: cope with variable number of spaces in header lines (#11079) Mar 04 16:25:15 jow * r30807 /branches/backfire/package/uhttpd/ (Makefile src/uhttpd.c): [backfire] uhttpd: merge r30806 Mar 04 16:39:34 juhosg * r30808 /trunk/target/linux/ramips/ (11 files in 9 dirs): Mar 04 16:39:34 ramips: board support for Asus RT-N10+ Mar 04 16:39:34 [juhosg: fix indentation in platform scripts, and remove debug Mar 04 16:39:34 messages from 06_set_iface_mac] Mar 04 16:39:34 Signed-off-by: Patrick van Staveren Mar 04 16:39:36 juhosg * r30809 /trunk/target/linux/ramips/ (10 files in 8 dirs): (log message trimmed) Mar 04 16:39:36 ramips: add support for unbranded XDX-RN502J board Mar 04 16:39:36 This patch adds support for routers using a PCB marked XDX-RN502J Mar 04 16:39:37 V2.0, such as some unbranded routers like this: Mar 04 16:39:37 http://www.mediafire.com/?8acv87h6snn9fj6 Mar 04 16:39:38 http://www.mediafire.com/?do7xonw7scor4kn Mar 04 16:39:38 http://www.mediafire.com/?1ad49zvx3e7jyix Mar 04 16:46:24 gabor - thanks for the commit, and for fixing my debug statements :) Mar 04 18:17:32 build #125 of x86 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/x86/builds/125 Mar 04 18:54:20 juhosg * r30810 /trunk/target/linux/generic/config-3.2: linux/3.2: add more NAND symbols Mar 04 18:54:22 juhosg * r30811 /trunk/target/linux/generic/config-3.3: linux/3.3: add more NAND symbols Mar 04 20:00:03 * swalker wonders how many of nico's build failure tickets are still valid Mar 04 20:38:32 good question. Mar 04 20:40:19 jow * r30812 /trunk/package/busybox/ (Makefile config/procps/Config.in): [package] busybox: enable ps wide flag by default Mar 04 21:07:03 jow_laptop: quick question... can we build and install modules.dep as part of the kernel compile/install? Mar 04 21:09:38 simply package depmod and do it on targetr Mar 04 21:16:45 then we'd also need opkg or whatever to rerun it, right? Mar 04 21:17:03 when installing additional kmod packages on the target. Mar 04 21:17:08 * nbd doesn't see the need for modules.dep or modinfo Mar 04 21:17:14 what do you want to do with it? Mar 04 21:17:29 see my last couple of emails. Mar 04 21:17:39 subjet? Mar 04 21:17:46 I'm trying to automate disassembling a stack trace... Mar 04 21:18:02 i think something like that should be done on the host, not the target Mar 04 21:18:24 on the host you also have unstripped binaries of kernel modules Mar 04 21:18:26 "Busybox modinfo and needing modules.dep" and "Alix 2D13 on latest trunk, traces in dmesg on bootup?" Mar 04 21:18:32 which makes it much easier to debug stuff Mar 04 21:18:38 well, at least part of it definitely needs to be done on the target. Mar 04 21:18:49 what part? Mar 04 21:19:10 you need the address where the module is loaded Mar 04 21:19:15 but for that you don't need modinfo Mar 04 21:19:18 you can get that from /proc/modules Mar 04 21:19:23 so the add-symbol-script needs to be script-generated. Mar 04 21:19:43 the load address comes from /proc/modules, and the path-to-object comes from modinfo. Mar 04 21:19:54 right. Mar 04 21:20:03 you only need the module name for the path Mar 04 21:20:16 how so? Mar 04 21:20:21 there's staging_dir/target-*/root/lib/modules/*/ Mar 04 21:20:33 maybe with some substitution of '_' vs '-' Mar 04 21:20:40 should be easily scriptable Mar 04 21:20:45 I still think its enough to change "some_module" to "find ... -name 'some[_\-]module.ko' Mar 04 21:20:47 but I want the path to the .o file in build_dir/linux-xx_yy/linux-n.n.n/ Mar 04 21:21:43 why? Mar 04 21:21:56 you can load the .ko file from staging_dir/target-*/root/... Mar 04 21:22:01 it is unstripped Mar 04 21:22:04 so it still has the debug info Mar 04 21:22:11 so a "list" can show the source. Mar 04 21:22:17 with absolute references to the source files Mar 04 21:22:27 though maybe i need to remove a paramter for that to work Mar 04 21:22:31 in a patch file Mar 04 21:23:10 it's a lot easier with modinfo. Mar 04 21:23:36 yeah, and it bloats up the target fs Mar 04 21:24:31 modinfo might also be useful for verifying that the manually set load-order in package/kernel/modules/*.mk/ Mar 04 21:24:48 in the $(call Autoload,$1...) is correct. Mar 04 21:25:11 you can probably reuse some kernel build system code to do the same thing on the host Mar 04 21:25:26 for 100 modules, modules.dep is fairly small. and as a text file with a lot of repetition, it compresses down well. Mar 04 21:25:45 either way, i'm not willing to bloat up images for all targets by default for a rare corner case Mar 04 21:26:32 you know, I have to say I understand the mania for constraining size on systems with limited resources... but having to bang square pegs through round holes on platforms that have adequate resources just seems like masochism. Mar 04 21:26:59 i don't consider it mania Mar 04 21:27:26 i just like things to be a thought through a bit more Mar 04 21:27:39 so make modules.dep be an optional target... default it 'y' only when CONFIG_BUSYBOX_CONFIG_MODINFO is selected. Mar 04 21:28:07 how about looking at it this way? Mar 04 21:28:50 the AR71xx and BRCM platforms have a lot of users and a lot of developers actively working on those platforms who know how to do things like getting stack traces in a round-about what. Mar 04 21:28:52 that's fine. Mar 04 21:29:16 here's how i typically debug stack traces Mar 04 21:29:36 so far the trace always contained function names for what i need (because of kallsyms) Mar 04 21:29:43 so i just run gdb on the module mentioned in the trace Mar 04 21:29:45 in the build dir Mar 04 21:29:46 but other platforms (like alix and net5501) have much smaller communities and sometimes we need things to be a little simpler so that less numerous developers and users can also make some measure of progress. Mar 04 21:29:52 then call l *function_name+ Mar 04 21:29:58 and voila, i see the source code Mar 04 21:30:06 no complex module loading sequence Mar 04 21:30:07 no modules.dep Mar 04 21:30:11 no messing around with load addresses Mar 04 21:30:12 just works Mar 04 21:30:16 Well, see Adam's messages. Mar 04 21:30:26 yeah, i saw that Mar 04 21:30:36 no one else has offered to help him out, so I've been trying to instruct him the only way I know how. Mar 04 21:30:50 i may have to start debugging this myself, since nobody else seems to be willing and capable to get to the bottom of this Mar 04 21:30:59 telling me after the fact that there's another way to do it isn't as helpful. Mar 04 21:31:07 it was possible to reproduce this in qemu, right? Mar 04 21:31:25 I'm trying to get to the bottom of it, but I'm being told that modules.dep is unbearable bloat. go figure. Mar 04 21:31:26 i didn't really follow the thread a lot, because i've been busy with other stuff Mar 04 21:31:43 i figured i'd just wait and see if the people posting in the thread would get it fixed Mar 04 21:31:59 and that's why I need modules.dep. Mar 04 21:32:23 i still think modules.dep is unnecessary Mar 04 21:38:30 it's not strictly necessary, but we're talking about a guy who doesn't even know gdb. Mar 04 21:39:25 and as you noticed, not a lot of other people offered to help, so maybe working with the people involved and the knowledge available is more important that coming up with the absolute smallest file size for every platform. Mar 04 21:39:26 yeah, so we're back to the extremely rare corner case Mar 04 21:39:36 probably the first and maybe even the last time something like that is necessary Mar 04 21:39:56 you're right. I should just burn all my x86 boxes, and replace them with AR71xx. hardwr.e Mar 04 21:40:13 now that's constructive Mar 04 21:40:15 ;) Mar 04 21:40:32 so, i don't remember all the emails of the thread, can the issue be reproduced in qemu? Mar 04 21:41:03 I don't know what else to say. I spent 2 years in a tools group at Cisco trying to make tools that were easier to use. Mar 04 21:41:18 I believe in conforming tools to people. not people to tools and environments. Mar 04 21:41:44 the thing is, for almost all regular kernel trace issues, the existing tools are already easy Mar 04 21:41:48 as i've explained above Mar 04 21:41:55 now we have a single case where that approach doesn't work Mar 04 21:42:06 i prefer to just deal with that directly Mar 04 21:42:18 rather than generalize from that single instance, which is unlikely to repeat Mar 04 21:42:25 I don't know if it can or not be reproduced. The Geode architecture is a little bizarre, because it has the VSA stuff leaving registers in particular states, and Qemu only emulates a generic platform. Mar 04 21:42:52 i'll read the traces again to see if i get an idea about it Mar 04 21:43:09 well, for some of us, Openwrt is the 'single case' that doesn't work like every other instance of linux. Mar 04 21:43:27 it's easy to see everything as a nail when all you do is walk around with a hammer all day. Mar 04 21:43:55 i think you're blowing things out of proportion Mar 04 21:44:11 I was thinking the same: modules.dep is a 20K file! Mar 04 21:44:30 + changes to generate and re-generate that + extra code in busybox Mar 04 21:44:37 my system has 2GB of flash, and I'm using 150MB of it. Mar 04 21:44:42 + useless work to be done on opkg installations Mar 04 21:45:19 btw. looking at the trace, i think that your whole approach might not help one bit for debugging this issue Mar 04 21:45:31 because i'm pretty sure the traces are not from module address space Mar 04 21:46:42 have you already suggested simply running gdb on the vmlinux image? Mar 04 21:47:03 well, maybe it won't, but I'm offering what help I can because no one else is and because I own that platform. Mar 04 21:47:14 yes. Mar 04 21:47:25 see the thread. Mar 04 21:48:21 now that i read more messages in the thread, i'm actually sure that including modules is unnecessary Mar 04 21:48:33 modules seem to be based around 0xd0000000 Mar 04 21:48:41 whereas the kernel lives in 0xc0000000 Mar 04 21:48:59 the trace only refers to 0xc0000000 Mar 04 21:49:51 i hope that you don't view my criticism of your suggestions as criticism of your efforts to improve the state of openwrt Mar 04 21:50:29 for me it's important to both keep the small embedded targets bloat-free, but also keep core stuff in sync even with platforms that have more space available Mar 04 21:51:19 where does busybox store it's helper .so's? Mar 04 21:51:42 I just looked on a system with modinfo built and another without it and /bin/busybox was exactly the same size. Mar 04 21:52:01 there are no helper .so files Mar 04 21:52:24 why are you still arguing for modules.dep, when i've just shown you how it's completely unnecessary? Mar 04 21:52:38 then it causes less than a disk-block's (or page alignment's) worth of bytes to support. Mar 04 21:52:46 also, in the thread i can't find the result of simply trying l *address with gdb on vmlinux Mar 04 21:53:17 I don't think it is in the kernel... because my alix addresses are much different. Mar 04 21:53:40 i haven't seen traces from you Mar 04 21:53:43 but maybe he built without wifi or pppoe support. Mar 04 21:53:45 are they in the thread as well? Mar 04 21:53:55 that's because I'm not getting traces. Mar 04 21:54:15 ok, then i have no idea wtf you're talking about Mar 04 21:54:26 I built my kernel from trunk just as he did, and looking at my addresses in /proc/modules it looks to me like his stack trace was in module space. Mar 04 21:54:41 updated openwrt/upstream, https://home.comcast.net/~sdwalker/uscan/index.html Mar 04 21:54:45 why are you still talking about module addresses? Mar 04 21:54:46 but he might be building a fatter kernel, I don't know. I'd need to see his .config and target.mk to be sure. Mar 04 21:55:09 wasn't the objective of the whole thing to debug the traces that adam was getting? Mar 04 21:55:29 because you said that you thought that the addresses were static kernel addresses, and I'm not convinced that's the case. Mar 04 21:56:30 you said "modules seem to be based around 0xd0000000" which seems less than 100% conclusive. Mar 04 21:56:45 so I'm not ruling anything out yet. Mar 04 21:57:29 i'm not ruling out modules at all, i just think it's better to test the more likely case first Mar 04 21:57:38 before changing lots of stuff that might be 100% unnecessary Mar 04 21:58:00 another indication is that with every single module load, the last trace address is exactly the same Mar 04 22:03:37 i just kicked off an alix2 build on a server Mar 04 22:03:44 will see if i can reproduce the issue Mar 04 22:06:38 on QEMU? Mar 04 22:06:51 yes Mar 04 22:07:17 the odd (and really annoying) thing was that when he built with kernel-symbols on, the problem went away. Mar 04 22:08:00 oh, and on QEMU, if PCI-ids aren't detected, certain modules will fail to load (since their probe routine will fail)... which means your load addresses won't be like his. Mar 04 22:08:33 I asked Adam to join us on IRC some time, but haven't heard back in a few days. Mar 04 22:09:19 saw Merkel getting beer spilled on her here, by the way... pretty much looks like the waiter did it on purpose. not a fan, I'm guessing. hoping she didn't tip him. :-) Mar 04 22:13:43 btw. in the kernel config i see CONFIG_PAGE_OFFSET set to 0xC0000000 Mar 04 22:14:00 so the addresses are absolutely within range of what is to be expected for the core image Mar 04 22:32:01 sent an email to adam Mar 04 23:05:17 copied to the list? Mar 04 23:05:44 of course Mar 04 23:37:31 philipp64|laptop: managed to reproduce adam's issue Mar 04 23:38:04 will build with debugging now, to track down the issue Mar 05 00:04:19 build #138 of cobalt is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/138 Mar 05 00:24:45 philipp64|laptop: seems that the bug is quite trivial Mar 05 00:24:51 no idea why it doesn't appear upstream though Mar 05 00:25:09 the x86 module loader code assumes that mod->init_size is non-zero Mar 05 00:25:24 but for modules that don't contain module_init(), mod->init_size can be zero Mar 05 00:25:28 so it does a vmalloc(0) Mar 05 00:25:34 which the kernel really doesn't like Mar 05 00:25:40 so it barfs up some stack traces Mar 05 00:26:30 maybe the more aggressive module stripping in openwrt made this visible Mar 05 00:30:38 interestingly enough, other architectures have a check in place to prevent such crap Mar 05 00:30:50 i should probably push that check to a common place Mar 05 00:35:03 yup, my fix works ;) Mar 05 00:35:14 that wasn't so hard Mar 05 00:43:05 nbd * r30813 /trunk/target/linux/generic/ (2 files in 2 dirs): kernel: fix vmalloc stack traces triggered by module with an empty init section (mostly happens on x86) Mar 05 00:43:11 philipp64|laptop: there, happy now? ;) Mar 05 01:00:37 build #103 of rdc is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/rdc/builds/103 Mar 05 01:21:22 nbd * r30814 /trunk/toolchain/gcc/patches/4.6-linaro/870-ppc_no_crtsavres.patch: gcc: do not emit references to _savegpr_* and _restgpr_* on powerpc, as they are tricky to deal with wrt. libgcc. they cannot be linked dynamically Mar 05 01:21:24 nbd * r30815 /trunk/toolchain/gcc/common.mk: gcc: now that the gpr save/restore issues are taken care of, remove the -Os/-O2 workaround that dealt with it earlier Mar 05 01:21:28 nbd * r30816 /trunk/target/linux/generic/ (8 files in 8 dirs): kernel: remove the crtsavres dependency, the patched gcc will no longer emit references to that code Mar 05 01:21:32 nbd * r30817 /trunk/target/linux/generic/patches-2.6.38/322-powerpc_unused_var.patch: kernel: fix powerpc unused-but-set variables Mar 05 02:43:25 build #101 of mpc52xx is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/101 Mar 05 02:57:11 jow_laptop, Hi. I just sent 7 new packages to 'OpenWrt Development List' and cc to you. Mar 05 02:58:26 jow_laptop, most of them has been under nanonote package repo for long time. I pick the simple stuff. no patches. no files. not for Nanonote. but useful for OpenWrt. :-) **** ENDING LOGGING AT Mon Mar 05 02:59:58 2012