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
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to