Jump to ID:
QNX Operating System

Project Home

Documents

Discussions

Wiki

Project Info
Forum Topic - Looking for docs on decoding kernel panic dump: (13 Items)
   
 
 
Looking for docs on decoding kernel panic dump  
Hi:

I have a panic dump from procnto and would like to decode some of the information. Is there a howto or doc that 
describes some of the fields?

Also are the memory addresses being referenced physical or virtual memory addresses?

Thanks
robert

BTW here is the dump

Shutdown[0,0] S/C/F=11/1/11 C/D=0004b954/000a474c state(d0)= now lock exit
QNX Version 6.3.2 Release 2006/03/16-14:18:11EST
[0]PID-TID=1-4? P/T FL=00019001/04020000 "proc/boot/procnto-400"
[0]ASPACE PID=278562 PF=00000000 "proc/boot/ps"
ppcbe context[03ff5d3c]:
0000: 00000040 03fbdcd0 000a9ba8 03fe57dc 7c005a14 03fe57dc 00000000 00000002
0020: 00000000 00000040 0006d000 00000004 24000000 000ab610 00000000 00000000
0040: 00000000 00000000 00000000 00000000 00000000 00000000 03fffc60 00000000
0060: 03fffa98 00000000 00000000 fe36d000 03cc7bd8 03fe57d4 03fe57dc 03e9b760
0080: 00000000 00066728 00029030 0009840c 44000000 00000000 00000000 00000000
00a0: 00000000
instruction[0009840c]:
89 24 00 00 38 84 00 01 7d 20 07 74 2c 00 00 00 99 23 00 00 39 63 00 01 4d 82
stack[03fbdcd0]:
0000: 03fbdda0 00066700 00000000 fe36d000 00000000 00008000 01080732 00000000
0020: 00000000 00000000 00000000 00000000 00000000 00000000 03fffc60 03e9b760
0040: 03e9b760 03cff090 00000002 03cc7bd8 03fbdd40 0005eeac 00000000 fe456000
0060: 039c8000 00700000 00004000 03fe5ce4 03fbdd50 0006698c 03fffc60 03e9b260

Re: Looking for docs on decoding kernel panic dump  
Robert D'Attilio wrote:
> Hi:
> 
> I have a panic dump from procnto and would like to decode some of the information. Is there a howto or doc that 
describes some of the fields?

http://www.qnx.com/developers/docs/6.4.0/neutrino/technotes/proc_dump.html

Regards,

Ryan Mansfield
Re: Looking for docs on decoding kernel panic dump  
RE: Looking for docs on decoding kernel panic dump  
Thanks guys.

Any idea if the memory addresses being referred to are physical
addresses or virtual?

-----Original Message-----
From: Joel Pilon [mailto:community-noreply@qnx.com] 
Sent: Thursday, April 30, 2009 4:19 PM
To: ostech-core_os
Subject: Re: Looking for docs on decoding kernel panic dump

This is a good place to start:

http://www.qnx.com/developers/docs/6.4.0/neutrino/technotes/proc_dump.ht
ml

_______________________________________________
OSTech
http://community.qnx.com/sf/go/post28480
Re: Looking for docs on decoding kernel panic dump  
They addresses are virtual, but the ppc kernel has 1-1 mappings setup,
so they mirror the physical.

When you get a dump, add a [+keeplinked] attribute to your procnto-400 - mkifs will then
leave a procnto-400.sym binary, which you can the load into ntoppc-gdb and examine the memory
addresses.

Colin

Robert D'Attilio wrote:
> Thanks guys.
> 
> Any idea if the memory addresses being referred to are physical
> addresses or virtual?
> 
> -----Original Message-----
> From: Joel Pilon [mailto:community-noreply@qnx.com] 
> Sent: Thursday, April 30, 2009 4:19 PM
> To: ostech-core_os
> Subject: Re: Looking for docs on decoding kernel panic dump
> 
> This is a good place to start:
> 
> http://www.qnx.com/developers/docs/6.4.0/neutrino/technotes/proc_dump.ht
> ml
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post28480
> 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post28481
> 

-- 
cburgess@qnx.com
RE: Looking for docs on decoding kernel panic dump  
They are virtual addresses.

Addresses in the kernel space will match symbols in your procnto.sym
file (generated if you [+keeplinked] in your build file) so you can look
around with gdb.  Looks like there's lots of those in the information
you've got -- on PPC, kernel addresses are in the first 256M.

Addresses outside the kernel space are more difficult -- you need to
know what address space they belong to and use gdb on that program.
Probably not an issue here.

Addresses in kernel interrupt code are most difficult, as you don't have
any symbolic information to figure them out...

In this case, it looks like a procnto thread was running, servicing a
request made by proc/boot/ps (from the PID and ASPACE PID lines).  The
S/C/F codes indicate a segfault.  The state (d0 = now lock exit) are an
artifact of a fault in a procnto thread.

Aside from that I can't contribute much without digging into the .sym
file.

> -----Original Message-----
> From: Robert D'Attilio [mailto:community-noreply@qnx.com] 
> Sent: Thursday, April 30, 2009 4:27 PM
> To: ostech-core_os
> Subject: RE: Looking for docs on decoding kernel panic dump
> 
> Thanks guys.
> 
> Any idea if the memory addresses being referred to are 
> physical addresses or virtual?
> 
> -----Original Message-----
> From: Joel Pilon [mailto:community-noreply@qnx.com]
> Sent: Thursday, April 30, 2009 4:19 PM
> To: ostech-core_os
> Subject: Re: Looking for docs on decoding kernel panic dump
> 
> This is a good place to start:
> 
> http://www.qnx.com/developers/docs/6.4.0/neutrino/technotes/pr
> oc_dump.ht
> ml
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post28480
> 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post28481
> 
> 
Re: Looking for docs on decoding kernel panic dump  
BTW - if you have a procnto-400, but not procnto-400.sym, all is not lost...

The crash dump tells you the relocated address of main

Shutdown[0,0] S/C/F=11/1/11 C/D=0004b954/000a474c state(d0)= now lock exit
                                 ^        ^
                                 &main     &actives

and the original binary gives the unrelocated address...

(632) cburgess@titirangi100:~$ ntoppc-nm $QNX_TARGET/ppcbe/boot/sys/procnto-400 | grep main
00038b24 T _main
00045afc T kernel_main
00005954 T main
00001064 G main_attrp
00000aa8 g mapped_remaining.88
000373d4 T timer_remaining

so...

0x4b954 - 0x5954 = 0x46000

and finally

ntoppc-ld -T $QNX_TARGET/ppcbe/lib/nto.link -Ttext 0x46000 -o procnto-400.sym $QNX_TARGET/ppcbe/boot/sys/procnto-400

ntoppc-gdb procnto-400.sym
GNU gdb 6.7 qnx-nto update 6 (rev. 109)
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=powerpc-unknown-nto-qnx6.3.2"...
(gdb) x/i 0x9840c
0x9840c <strcpy>:	lbz     r9,0(r4)
(gdb) x/w 0x9840c
0x9840c <strcpy>:	0x89240000
(gdb)

and we can confirm the instruction stream is the same..

instruction[0009840c]:
89 24 00 00 38 84 00 01 7d 20 07 74 2c 00 00 00 99 23 00 00 39 63 00 01 4d 82

Cheers!

Colin

Douglas Bailey wrote:
> They are virtual addresses.
> 
> Addresses in the kernel space will match symbols in your procnto.sym
> file (generated if you [+keeplinked] in your build file) so you can look
> around with gdb.  Looks like there's lots of those in the information
> you've got -- on PPC, kernel addresses are in the first 256M.
> 
> Addresses outside the kernel space are more difficult -- you need to
> know what address space they belong to and use gdb on that program.
> Probably not an issue here.
> 
> Addresses in kernel interrupt code are most difficult, as you don't have
> any symbolic information to figure them out...
> 
> In this case, it looks like a procnto thread was running, servicing a
> request made by proc/boot/ps (from the PID and ASPACE PID lines).  The
> S/C/F codes indicate a segfault.  The state (d0 = now lock exit) are an
> artifact of a fault in a procnto thread.
> 
> Aside from that I can't contribute much without digging into the .sym
> file.
> 
>> -----Original Message-----
>> From: Robert D'Attilio [mailto:community-noreply@qnx.com] 
>> Sent: Thursday, April 30, 2009 4:27 PM
>> To: ostech-core_os
>> Subject: RE: Looking for docs on decoding kernel panic dump
>>
>> Thanks guys.
>>
>> Any idea if the memory addresses being referred to are 
>> physical addresses or virtual?
>>
>> -----Original Message-----
>> From: Joel Pilon [mailto:community-noreply@qnx.com]
>> Sent: Thursday, April 30, 2009 4:19 PM
>> To: ostech-core_os
>> Subject: Re: Looking for docs on decoding kernel panic dump
>>
>> This is a good place to start:
>>
>> http://www.qnx.com/developers/docs/6.4.0/neutrino/technotes/pr
>> oc_dump.ht
>> ml
>>
>> _______________________________________________
>> OSTech
>> http://community.qnx.com/sf/go/post28480
>>
>>
>> _______________________________________________
>> OSTech
>> http://community.qnx.com/sf/go/post28481
>>
>>
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post28483
> 

-- 
cburgess@qnx.com
Re: Looking for docs on decoding kernel panic dump  
It appears to be crashing trying to strcpy a process' debug_name variable.

If you look at the instruction at 0x9840c, it's in strcpy, and it's doing

lbz r9,0(r4)

now, r4 is 0x7c005a14, is just plain wrong...

Now the 64million dollar question - can you reproduce this? :-)

Robert D'Attilio wrote:
> Hi:
> 
> I have a panic dump from procnto and would like to decode some of the information. Is there a howto or doc that 
describes some of the fields?
> 
> Also are the memory addresses being referenced physical or virtual memory addresses?
> 
> Thanks
> robert
> 
> BTW here is the dump
> 
> Shutdown[0,0] S/C/F=11/1/11 C/D=0004b954/000a474c state(d0)= now lock exit
> QNX Version 6.3.2 Release 2006/03/16-14:18:11EST
> [0]PID-TID=1-4? P/T FL=00019001/04020000 "proc/boot/procnto-400"
> [0]ASPACE PID=278562 PF=00000000 "proc/boot/ps"
> ppcbe context[03ff5d3c]:
> 0000: 00000040 03fbdcd0 000a9ba8 03fe57dc 7c005a14 03fe57dc 00000000 00000002
> 0020: 00000000 00000040 0006d000 00000004 24000000 000ab610 00000000 00000000
> 0040: 00000000 00000000 00000000 00000000 00000000 00000000 03fffc60 00000000
> 0060: 03fffa98 00000000 00000000 fe36d000 03cc7bd8 03fe57d4 03fe57dc 03e9b760
> 0080: 00000000 00066728 00029030 0009840c 44000000 00000000 00000000 00000000
> 00a0: 00000000
> instruction[0009840c]:
> 89 24 00 00 38 84 00 01 7d 20 07 74 2c 00 00 00 99 23 00 00 39 63 00 01 4d 82
> stack[03fbdcd0]:
> 0000: 03fbdda0 00066700 00000000 fe36d000 00000000 00008000 01080732 00000000
> 0020: 00000000 00000000 00000000 00000000 00000000 00000000 03fffc60 03e9b760
> 0040: 03e9b760 03cff090 00000002 03cc7bd8 03fbdd40 0005eeac 00000000 fe456000
> 0060: 039c8000 00700000 00004000 03fe5ce4 03fbdd50 0006698c 03fffc60 03e9b260
> 
> 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post28478
> 

-- 
cburgess@qnx.com
RE: Looking for docs on decoding kernel panic dump  
Colin:

Many thanks for your analysis!

Some background: I am investigating what I think is a hardware problem
(bad RAM?) on a new product in development. This particular card will
periodically have different processes core with either a signal 4,
illegal instruction error or a signal 11, segmentation fault along with
a corrupted stack. I've also been able to capture some of these kernel
panics now that I've re-enabled the serial port and disabled the
watchdog. The kernel panics are not always in the same place either. So
far the problem is isolated to this one card out of about 12 that have
been undergoing extensive verification testing for a couple of months. 

I am hoping to use the kernel dumps to point to a region of RAM that
should be probed with some sort of RAM test. So far, the basic data bus
walking ones/zeros test and address lines tests haven't turned up
anything.

A couple of questions though about your analysis as working at this
level (and with QNX) is still pretty new for me and interesting:

1) How do you know that 0x7c005a14 is an invalid address?
2) The stack dump, is that the kernel's stack or the application's?
3) In a subsequent posting, you did the following:

ntoppc-ld -T $QNX_TARGET/ppcbe/lib/nto.link -Ttext 0x46000 -o
procnto-400.sym $QNX_TARGET/ppcbe/boot/sys/procnto-400

What exactly were you trying to do here? Was this how YOU were able to
determine that the failure was in strcpy() - the above relinks the
kernel to my relocation address and then you used the .sym to reverse
engineer the instruction address?

Sorry for all the questions...but I thought it was pretty cool that you
could pull out that kind of info from what looks like nonsense :)

robert


-----Original Message-----
From: Colin Burgess [mailto:community-noreply@qnx.com] 
Sent: Thursday, April 30, 2009 4:55 PM
To: ostech-core_os
Subject: Re: Looking for docs on decoding kernel panic dump

It appears to be crashing trying to strcpy a process' debug_name
variable.

If you look at the instruction at 0x9840c, it's in strcpy, and it's
doing

lbz r9,0(r4)

now, r4 is 0x7c005a14, is just plain wrong...

Now the 64million dollar question - can you reproduce this? :-)

Robert D'Attilio wrote:
> Hi:
> 
> I have a panic dump from procnto and would like to decode some of the
information. Is there a howto or doc that describes some of the fields?
> 
> Also are the memory addresses being referenced physical or virtual
memory addresses?
> 
> Thanks
> robert
> 
> BTW here is the dump
> 
> Shutdown[0,0] S/C/F=11/1/11 C/D=0004b954/000a474c state(d0)= now lock
exit
> QNX Version 6.3.2 Release 2006/03/16-14:18:11EST
> [0]PID-TID=1-4? P/T FL=00019001/04020000 "proc/boot/procnto-400"
> [0]ASPACE PID=278562 PF=00000000 "proc/boot/ps"
> ppcbe context[03ff5d3c]:
> 0000: 00000040 03fbdcd0 000a9ba8 03fe57dc 7c005a14 03fe57dc 00000000
00000002
> 0020: 00000000 00000040 0006d000 00000004 24000000 000ab610 00000000
00000000
> 0040: 00000000 00000000 00000000 00000000 00000000 00000000 03fffc60
00000000
> 0060: 03fffa98 00000000 00000000 fe36d000 03cc7bd8 03fe57d4 03fe57dc
03e9b760
> 0080: 00000000 00066728 00029030 0009840c 44000000 00000000 00000000
00000000
> 00a0: 00000000
> instruction[0009840c]:
> 89 24 00 00 38 84 00 01 7d 20 07 74 2c 00 00 00 99 23 00 00 39 63 00
01 4d 82
> stack[03fbdcd0]:
> 0000: 03fbdda0 00066700 00000000 fe36d000 00000000 00008000 01080732
00000000
> 0020: 00000000 00000000 00000000 00000000 00000000 00000000 03fffc60
03e9b760
> 0040: 03e9b760 03cff090 00000002 03cc7bd8 03fbdd40 0005eeac 00000000
fe456000
> 0060: 039c8000 00700000 00004000 03fe5ce4 03fbdd50 0006698c 03fffc60
03e9b260
> 
> 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post28478
> 

--...
Re: Looking for docs on decoding kernel panic dump  
Robert D'Attilio wrote:
> Colin:
> 
> Many thanks for your analysis!
> 
> Some background: I am investigating what I think is a hardware problem
> (bad RAM?) on a new product in development. This particular card will
> periodically have different processes core with either a signal 4,
> illegal instruction error or a signal 11, segmentation fault along with
> a corrupted stack. I've also been able to capture some of these kernel
> panics now that I've re-enabled the serial port and disabled the
> watchdog. The kernel panics are not always in the same place either. So
> far the problem is isolated to this one card out of about 12 that have
> been undergoing extensive verification testing for a couple of months. 
> 
> I am hoping to use the kernel dumps to point to a region of RAM that
> should be probed with some sort of RAM test. So far, the basic data bus
> walking ones/zeros test and address lines tests haven't turned up
> anything.

Well the first thing I would check is the power.  I've seen plenty of boards
where the power was just barely in the spec'd margins, and fluctuations in the
supply could lead to memory corruption.  We spent a long time chasing one particular
corruption only to find out that it was as simple as that.  And yes, because
it was marginal it varied board by board.  It often would only fail under  heavy load
too (with peripherals sucking the power I guess).

> A couple of questions though about your analysis as working at this
> level (and with QNX) is still pretty new for me and interesting:
> 
> 1) How do you know that 0x7c005a14 is an invalid address?

The virtual address space is divided by kernel and user spaces.  The kernel lives (on PPC)
from 0-1G, usermode addresses are higher.  Hence a usermode address for a procnto variable
is not normal.

Note that it is normal for the kernel to access usermode vaddrs, but they must be verified
first, and in this case it was a kernel allocated variable.

> 2) The stack dump, is that the kernel's stack or the application's?

It's always the kernel stack.

> 3) In a subsequent posting, you did the following:
> 
> ntoppc-ld -T $QNX_TARGET/ppcbe/lib/nto.link -Ttext 0x46000 -o
> procnto-400.sym $QNX_TARGET/ppcbe/boot/sys/procnto-400
> 
> What exactly were you trying to do here? Was this how YOU were able to
> determine that the failure was in strcpy() - the above relinks the
> kernel to my relocation address and then you used the .sym to reverse
> engineer the instruction address?

The procnto-400 binary we ship is actually an object file.  When you run mkifs (try it with -vv) it
actually runs a linker to relocate the startup and the procnto to the appropriate addresses for your
image.

The [+keeplinked] attribute tells mkifs to leave the relocated symbol file around.  It's very useful for
this sort of debugging.

Once I had the relocated symbols I could simply load the .sym file into gdb and check the instruction where
the kernel faulted.

The register context (described in usr/include/ppc/context.h) gave me the registers.

> Sorry for all the questions...but I thought it was pretty cool that you
> could pull out that kind of info from what looks like nonsense :)

It does appear to be a bit of black magic from the outside, doesn't it?  And I assure you, it IS.  Now, I've
got to go drain the blood of a mouse.. :-)

Colin

> robert
> 
> 
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com] 
> Sent: Thursday, April 30, 2009 4:55 PM
> To: ostech-core_os
> Subject: Re: Looking for docs on decoding kernel panic dump
> 
> It appears to be crashing trying to strcpy a process' debug_name
> variable.
> 
> If you look at the instruction at 0x9840c, it's in strcpy, and it's
> doing
> 
> lbz r9,0(r4)
>...
View Full Message
RE: Looking for docs on decoding kernel panic dump  
>> 3) In a subsequent posting, you did the following:
>> 
>> ntoppc-ld -T $QNX_TARGET/ppcbe/lib/nto.link -Ttext 0x46000 -o
>> procnto-400.sym $QNX_TARGET/ppcbe/boot/sys/procnto-400
>> 
>> What exactly were you trying to do here? Was this how YOU were able
to
>> determine that the failure was in strcpy() - the above relinks the
>> kernel to my relocation address and then you used the .sym to reverse
>> engineer the instruction address?

>The procnto-400 binary we ship is actually an object file.  When you
run  >mkifs (try it with -vv) it
>actually runs a linker to relocate the startup and the procnto to the
>appropriate addresses for your
>image.

Last question\comment on this topic to save sacrificing any more mice :)

So just for fun I tried re-running the mkifs with -vv as you suggested
and looked at the output and see the following:

  Offset   Size    Entry   Ramoff Target=Host
   30000    100     ----      --- Startup-header
   30100  10008    30200      --- startup-ppc.sym
   40108     5c     ----      --- Image-header
   40164   42f8     ----      --- Image-directory
...
   45000  61000    6d8cc      --- proc/boot/procnto-400=procnto-400.sym

I was expecting the offset for procnto to be 0x46000 as you had
calculated and used in your link command above and not 0x45000 as
reported by mkifs. Why the discrepancy? 
Re: Looking for docs on decoding kernel panic dump  
If you look at the produced elf file...

cburgess@titirangi100:~$ ntoppc-readelf -l procnto-400.sym

Elf file type is EXEC (Executable file)
Entry point 0x6d8cc
There are 3 program headers, starting at offset 52

Program Headers:
   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
   LOAD           0x001000 0x00046000 0x00046000 0x5bba8 0x5bba8 R E 0x1000
   LOAD           0x05d000 0x000a2000 0x000a2000 0x02b1c 0x03150 RW  0x1000
   NOTE           0x000000 0x00000000 0x00000000 0x00000 0x00000     0x4

  Section to Segment mapping:
   Segment Sections...
    00     .text .rodata
    01     .data .got .sdata .sbss .bss
    02

you will see that the PT_LOAD starts at offse 0x1000 into the ELF file.  So the begining of
procnto-400.sym is at offset 0x45000 but the actual instructions are at 0x46000

No mice died in the production of this message...

Robert D'Attilio wrote:
>>> 3) In a subsequent posting, you did the following:
>>>
>>> ntoppc-ld -T $QNX_TARGET/ppcbe/lib/nto.link -Ttext 0x46000 -o
>>> procnto-400.sym $QNX_TARGET/ppcbe/boot/sys/procnto-400
>>>
>>> What exactly were you trying to do here? Was this how YOU were able
> to
>>> determine that the failure was in strcpy() - the above relinks the
>>> kernel to my relocation address and then you used the .sym to reverse
>>> engineer the instruction address?
> 
>> The procnto-400 binary we ship is actually an object file.  When you
> run  >mkifs (try it with -vv) it
>> actually runs a linker to relocate the startup and the procnto to the
>> appropriate addresses for your
>> image.
> 
> Last question\comment on this topic to save sacrificing any more mice :)
> 
> So just for fun I tried re-running the mkifs with -vv as you suggested
> and looked at the output and see the following:
> 
>   Offset   Size    Entry   Ramoff Target=Host
>    30000    100     ----      --- Startup-header
>    30100  10008    30200      --- startup-ppc.sym
>    40108     5c     ----      --- Image-header
>    40164   42f8     ----      --- Image-directory
> ...
>    45000  61000    6d8cc      --- proc/boot/procnto-400=procnto-400.sym
> 
> I was expecting the offset for procnto to be 0x46000 as you had
> calculated and used in your link command above and not 0x45000 as
> reported by mkifs. Why the discrepancy? 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post28524
> 

-- 
cburgess@qnx.com
Re: Looking for docs on decoding kernel panic dump  
qsymoops -f ./dump.txt -s $QNX_TARGET/ppcbe/boot/sys/procnto-400

with procnto I get this:
=========================================
ppcbe context[03ff5d3c]:
 Platform:ppc        endian:big
=========================================
QNX Version 6.3.2 Release 2006/03/16-14:18:11
 QNX Version:6.3.2 Release timestamp:2006/03/16-14:18:11EST.
=========================================
Shutdown[0,0]
 Shutdown run on cpu 0, kernel cpu:0
=========================================
S/C/F=11/1/11
 Signal    :11  SIGSEGV   	segmentation violation
 Code      :1   SEGV_MAPERR	Address not mapped
 Fault code:11  FLTPAGE   	Recoverable page fault (no associated sig)
=========================================
C/D=0004b954/000a474c
 Location of the kernel's code(main):0x4b954   	data(actives[]):0xa474c
=========================================
state(d0)= now lock exit
state(d0)= now lock exit
  Explanation of state of the kernel:
   * now -- in the kernel
   * lock -- nonpreemptible
   * exit -- leaving kernel
   * specret -- special return processing
   * any number -- the interrupt nesting level.
 =========================================
 P/T FL=00019001/04020000 "proc/boot/procnto-400"


  Process flags:0x19001.
   0x00000001: _NTO_PF_NOCLDSTOP 
   0x00001000: _NTO_PF_CHECK_INTR Only set by interrupt_attach_*
   0x00008000: _NTO_PF_RING0 Ring0 access(only process manager process)
   0x00010000: _NTO_PF_SLEADER 
    +========
   0x00019001
  Thread flags :0x04020000.
   0x00020000: _NTO_TF_DETACHED 
   0x04000000: _NTO_TF_ALLOCED_STACK 
    +========
   0x04020000
  Process      :proc/boot/procnto-400".
=========================================
PF=00000000 "proc/boot/ps"
 The process "proc/boot/ps"" 
 Flags: 0x0 for the ASPACE PID, its address space was active.
   +========
  0x00000000
=========================================
ppcbe context[03ff5d3c]:
 Platform:ppcbe     	 Stored register map address:3ff5d3c
    r0:0x00000040     r1:0x03fbdcd0     r2:0x000a9ba8     r3:0x03fe57dc 
    r4:0x7c005a14     r5:0x03fe57dc     r6:0x00000000     r7:0x00000002 
    r8:0x00000000     r9:0x00000040    r10:0x0006d000    r11:0x00000004 
   r12:0x24000000    r13:0x000ab610    r14:0x00000000    r15:0x00000000 
   r16:0x00000000    r17:0x00000000    r18:0x00000000    r19:0x00000000 
   r20:0x00000000    r21:0x00000000    r22:0x03fffc60    r23:0x00000000 
   r24:0x03fffa98    r25:0x00000000    r26:0x00000000    r27:0xfe36d000 
   r28:0x03cc7bd8    r29:0x03fe57d4    r30:0x03fe57dc    r31:0x03e9b760 
   ctr:0x00000000     lr:0x00066728    msr:0x00029030     pc:0x0009840c 
    cr:0x44000000    xer:0x00000000    ear:0x00000000  usprg0:0x00000000 
 vrsave:0x00000000 
=========================================
instruction[0009840c]:
 Current instruction address(pc):0x0009840c and machine code:
 89 24 00 00 38 84 00 01 7d 20 07 74 2c 00 00 00 99 23 00 00 39 63 00 01 4d 82

 Current ip(0x9840c) in image is address (0x5240c), it is in function: strcpy(0x5240c) [strcpy+0x0]

   523e4:	8d 23 00 01 	lbzu	r9,1(r3)
   523e8:	8c 04 00 01 	lbzu	r0,1(r4)
   523ec:	7c 09 00 00 	cmpw	r9,r0
   523f0:	41 82 ff e4 	beq+	523d4 <strcmp+0x10>
   523f4:	88 63 00 00 	lbz	r3,0(r3)
   523f8:	88 04 00 00 	lbz	r0,0(r4)
   523fc:	7c 60 18 10 	subfc	r3,r0,r3
   52400:	7c 63 19 10 	subfe	r3,r3,r3
   52404:	60 63 00 01 	ori	r3,r3,1
   52408:	4e 80 00 20 	blr

0005240c <strcpy>:
   5240c:	89 24 00 00 	lbz	r9,0(r4)
   52410:	38 84 00 01 	addi	r4,r4,1
   52414:	7d 20 07 74 	extsb	r0,r9
   52418:	2c 00 00 00 	cmpwi	r0,0
   5241c:	99 23 00 00 	stb	r9,0(r3)
   52420:	39 63 00 01 	addi	r11,r3,1
   52424:	4d 82 00 20 	beqlr	
   52428:	89 24 00 00 	lbz	r9,0(r4)
   5242c:	38 84 00 01 	addi	r4,r4,1
   52430:	7d 20 07 74 	extsb	r0,r9
   52434:	2c 00 00 00 	cmpwi	r0,0
   52438:	99 2b 00 00 	stb	r9,0(r11)
=========================================
stack[03fbdcd0]:
 Current stack...
View Full Message