Two questions: If you keep 29981 (and above) and set LINUX_VERSION back to 2.6.39.4 what happens?
If you build a x86/generic kernel with LINUX_VERSION=3.2.2 what happens? On 2/27/12 9:01 PM, Adam Gensler wrote: > Confirmed, this issue first appears when the kernel was bumped to 3.2.1 > in this change set: > https://dev.openwrt.org/changeset/29981/trunk > > 29980, which still uses 2.6.39.4 works fine. 29981, which moves to 3.2.1 > has the previously mentioned traces in dmesg on boot up. > > > On 2/27/12 7: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
