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
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
