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
_______________________________________________
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
