You should be able to get a stack trace with gdb and the unstripped kernel, or else just do it by hand with:
.tmp_System.map in your build_dir/linux-x86_alix2/linux-3.2.2/ directory. Maybe someone else like Felix or Jo-Philipp can give better suggestions? -Philip On 2/27/12 5:53 PM, Adam Gensler wrote: > By symbolic addresses you mean building it with the symbol table? > > CONFIG_KERNEL_KALLSYMS=y > > Doing so corrects the problem, making it impossible to debug. If you > mean something else please let me know and I'll be happy to try it. > Being stuck on pre-30000 revisions in trunk on the x86 alix2 target is > not some place I'd like to stay. > > Thanks, > Adam > > On 2/27/12 1:44 AM, Philip Prindeville wrote: >> It might also be helpful to get symbolic addresses and not just hex >> addresses. >> >> >> On 2/25/12 10:48 AM, Adam Gensler wrote: >>> Does anyone else have any thoughts into this? Other suggestions I can >>> try? Seems someone else is seeing the same issue as I've found the >>> following output sitting on pastebin: >>> >>> http://pastebin.com/djNfNa3t >>> >>> These errors match the errors I'm seeing on my system exactly. >>> >>> I've since reverted to trunk@29844 with a patch kicking it up to the >>> 3.0.18 kernel and I don't see these errors. I went ahead and opened a >>> ticket on this for tracking purposes: >>> >>> alix2 - trace messages in dmesg on bootup >>> https://dev.openwrt.org/ticket/11020 >>> >>> Thanks, >>> Adam >>> >>> On 2/22/12 1:02 AM, Adam Gensler wrote: >>>> Just build another one, this time with the following: >>>> >>>> # target >>>> CONFIG_TARGET_x86=y >>>> CONFIG_TARGET_x86_alix2=y >>>> CONFIG_DEVEL=y >>>> CONFIG_TOOLCHAINOPTS=y >>>> CONFIG_KERNEL_KALLSYMS=y >>>> #CONFIG_KERNEL_DEBUG_KERNEL=y >>>> #CONFIG_KERNEL_DEBUG_INFO=y >>>> >>>> Boots fine, no traces showing up. >>>> >>>> Not sure what that means exactly. Buts it's 100% reproducible on three >>>> different alix boards with images from two different build machines. >>>> >>>> Adam >>>> >>>> On 2/22/12 12:50 AM, Philip Prindeville wrote: >>>>> Try leaving CONFIG_KERNEL_KALLSYMS and turn off CONFIG_KERNEL_DEBUG_* ... >>>>> >>>>> On 2/21/12 10:34 PM, Adam Gensler wrote: >>>>>> Hi Philip, >>>>>> >>>>>> I suspected that might have been the problem so I did another build real >>>>>> quick, but I removed your extra commands, and the problem returned in >>>>>> that build. >>>>>> >>>>>> So, I ran yet another build, this time, with the following options: >>>>>> >>>>>> # target >>>>>> CONFIG_TARGET_x86=y >>>>>> CONFIG_TARGET_x86_alix2=y >>>>>> CONFIG_DEVEL=y >>>>>> CONFIG_TOOLCHAINOPTS=y >>>>>> #CONFIG_KERNEL_KALLSYMS=y >>>>>> CONFIG_KERNEL_DEBUG_KERNEL=y >>>>>> CONFIG_KERNEL_DEBUG_INFO=y >>>>>> >>>>>> Note, I commented out the "CONFIG_KERNEL_KALLSYMS=y". The problems >>>>>> happens when that is disabled. If I turn that back on, >>>>>> "CONFIG_KERNEL_KALLSYMS=y", the trace messages disappear. >>>>>> >>>>>> Adam >>>>>> >>>>>> On 2/22/12 12:30 AM, Philip Prindeville wrote: >>>>>>> Actually, that shouldn't have fixed your problem! (Unless >>>>>>> Heisenberg's Principle comes into effect.) >>>>>>> >>>>>>> It was supposed to give us a useful stack trace, however. >>>>>>> >>>>>>> You might have had a corrupt build. >>>>>>> >>>>>>> Can you try it on several boxes and see if it's reproducible? >>>>>>> >>>>>>> -Philip >>>>>>> >>>>>>> >>>>>>> On 2/21/12 10:10 PM, Adam Gensler wrote: >>>>>>>> Hi Philip, >>>>>>>> >>>>>>>> I rebuilt an image with those additional options added. It resolved >>>>>>>> the >>>>>>>> call traces I was seeing in dmesg. None of them show up now. I'll >>>>>>>> admit, >>>>>>>> I'm not super familiar with the inner-workings of kernel building. Can >>>>>>>> you provide some insight into why this seems to have resolved the >>>>>>>> issue? >>>>>>>> >>>>>>>> Attached is the dmesg output from the new image, just in case. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Adam >>>>>>>> >>>>>>>> >>>>>>>> On 2/21/12 10:31 PM, Philip Prindeville wrote: >>>>>>>>> On 2/21/12 8:15 PM, Adam Gensler wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I have a handful of Alix 2D13 platforms I've been running trunk >>>>>>>>>> images >>>>>>>>>> on for a while now. I noticed that it was recently kicked up to >>>>>>>>>> kernel >>>>>>>>>> 3.2.2. When it boots up now there's a number of traces from insmod. >>>>>>>>>> Attached is the complete output of the boot sequence. >>>>>>>>>> >>>>>>>>>> The image was built clean, in a clean pull of trunk, using the >>>>>>>>>> default >>>>>>>>>> alix2 target. I've seen this on multiple alix boards, on images >>>>>>>>>> built on >>>>>>>>>> two completely separate build servers so I don't think its >>>>>>>>>> related to >>>>>>>>>> how I'm building the image. >>>>>>>>>> >>>>>>>>>> Any suggestions on how to troubleshoot this? >>>>>>>>>> >>>>>>>>>> Thanks in advance, >>>>>>>>>> Adam >>>>>>>>> >>>>>>>>> Please do the following: >>>>>>>>> >>>>>>>>> % mkdir ~/.openwrt >>>>>>>>> % cat>> ~/.openwrt/defconfig >>>>>>>>> CONFIG_DEVEL=y >>>>>>>>> CONFIG_TOOLCHAINOPTS=y >>>>>>>>> CONFIG_KERNEL_KALLSYMS=y >>>>>>>>> CONFIG_KERNEL_DEBUG_KERNEL=y >>>>>>>>> CONFIG_KERNEL_DEBUG_INFO=y >>>>>>>>> ^D >>>>>>>>> % rm -rf tmp .config >>>>>>>>> % make defconfig >>>>>>>>> % make target/linux/{clean,compile} world V=99 >>>>>>>>> % >>>>>>>>> >>>>>>>>> and try it again. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Philip _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
