So I worked out I was using the wrong addresses and should have used the ones
at the bottom in the [].
Below is the output from the crash and subsequent symbols
0x0005bc0c -- 0x0005bb88 + 0x0084 do_mount
0x00010027 -- 0x00010000 + 0x0027 _text
0x00010000 -- 0x00010000 + 0x0000 _text
0x0001725a -- 0x000171f8 + 0x0062 copy_process
0x0012abec -- 0x0012abec + 0x0000 fair_sched_class
0x00010027 -- 0x00010000 + 0x0027 _text
0x0001725a -- 0x000171f8 + 0x0062 copy_process
0x0012abec -- 0x0012abec + 0x0000 fair_sched_class
0x00010027 -- 0x00010000 + 0x0027 _text
0x00110000 -- 0x0010ff2e + 0x00d2 __inet_del_ifa
0x0001725a -- 0x000171f8 + 0x0062 copy_process
0x0012abec -- 0x0012abec + 0x0000 fair_sched_class
0x00010027 -- 0x00010000 + 0x0027 _text
0x00110000 -- 0x0010ff2e + 0x00d2 __inet_del_ifa
dBUG> go 0x10000
Linux version 2.6.29-uc0 (ghula...@ubuntu) (gcc version 4.2.4) #13 Tue Mar 2 190
uClinux/COLDFIRE(m5280/5282)
COLDFIRE port done by Greg Ungerer, g...@snapgear.com
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
Buroot (romfs filesystem) readonly on device 31:0.
Freeing unused kernel memory: 52k freed (0x157000 - 0x163000)
Access Error Exception 12: Error on data read
Stack from 00270014:
ffffffff 00000078 00000078 00000078 00000000 0012abec 00000400 00400000
00000001 00000000 00000000 00165a38 00165a38 00000001 0098963a c8bb3000
00000000 93393580 00000000 9469f024 00000000 93393580 00000000 00000000
00000000 0005bc0c 001659b8 00165a14 00000000 00270088 00270088 00000000
00000064 00000001 00000000 00000000 00000000 00010027 03da0014 82660015
80000015 80000014 ecbc0000 00000000 00000000 00000000 00000080 00008000
Call Trace with CONFIG_FRAME_POINTER disabled:
[0012abec] [0005bc0c] [00010027] [00010000] [0001725a]
[0012abec] [00010027] [0001725a] [0012abec] [00010027]
[00110000] [0001725a] [0012abec] [00010027] [00110000]
[0001725a] [0012abec] [00010027] [00110000] [0001725a]
On Mar 2, 2010, at 3:43 PM, Greg Hulands wrote:
> Thanks for the tip on backtrace. Very handy
>
> Is it common to have so many stacks frames to have 0x00000000 as the address?
> That seems a bit odd to me.
>
> x0026b02c -- 0x0016f878 + 0xfb7b4 _end
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000003 -- unknown address
> 0x00000000 -- unknown address
> 0x00000007 -- unknown address
> 0x00155000 -- 0x00155000 + 0x0000 set_reset_devices
> 0x00155000 -- 0x00155000 + 0x0000 set_reset_devices
> 0x00155000 -- 0x00155000 + 0x0000 set_reset_devices
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x00000000 -- unknown address
> 0x0026b160 -- 0x0016f878 + 0xfb8e8 _end
>
>
>
> On Mar 2, 2010, at 6:38 AM, Stern, Allon wrote:
>
>>
>> On Mar 2, 2010, at 12:02 AM, Greg Hulands wrote:
>>
>>> I tried to enable the Full Symbolic/Source Debugging support option in the
>>> kernel hacking section, but no new info was displayed in the crash. Is this
>>> only if I connect via gdb to get the symbolic stack?
>>
>>> I would actually like to work out why the normal init isn't working
>>> properly. Is someone able to give me the gist of what to do to track it
>>> down?
>>
>> One think you can look at, if you can't get symbolic traces, is look at the
>> System.map file which is generated along with your kernel. It shows you the
>> starting address for each function in the kernel.
>>
>> There is a handy perl script here: ftp://ftp.denx.de/pub/tools/backtrace
>>
>> which will take a System.map file, then reads standard input - you can paste
>> your backtrace into stdin, and it will look up the symbols for those
>> addresses and give it to you in a more human-readable fashion, with function
>> names and offsets.
>>
>> You can also take your kernel, run it through m68k-uclinux-objdump -S to get
>> a full disassembly of the kernel (redirect the output to a file). Then
>> peruse the file, and look for the offset where your failure occurred.
>>
>> Good luck!
>> -
>> allon
>>
>>
>> ------------------------------------------------------------------------------------------
>> Disclaimer
>> The information contained in this email is intended solely for the
>> use of the individual(s) to whom it is addressed. It may contain
>> proprietary, privileged or other sensitive data. If you believe you
>> have received this email in error, please do not share this email
>> with anyone but instead notify the sender immediately. In addition,
>> please delete this email and any attachments from your computer.
>>
>> _______________________________________________
>> uClinux-dev mailing list
>> uClinux-dev@uclinux.org
>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>> This message was resent by uclinux-dev@uclinux.org
>> To unsubscribe see:
>> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev@uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev@uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
