* RE: Software Emulation Panic,
@ 2000-06-22 20:39 Lucinda Schafer
2000-06-22 22:33 ` Frank Rowand
0 siblings, 1 reply; 5+ messages in thread
From: Lucinda Schafer @ 2000-06-22 20:39 UTC (permalink / raw)
To: frowand; +Cc: linuxppc-embedded
The results of the backtrace are as follows :
C0016204 put_dirty_page
C0016A98 handle_mm_fault
C0009098 do_page_fault
C0002544 _switch
018A4490 ???
300E88A4 ???
0180C6D4 ???
0180C5D8 ???
01803250 ???
01802B64 ???
01801D80 ???
Which order are these called? I haven't been able to link all four together,
although I do know that do_page_fault calls handle_mm_fault, the scheduler
calls _switch, execve calls put_dirty_page via load_elf_binary. This all
happens during the rc.sysinit.
-----Original Message-----
From: Frank Rowand [mailto:frank_rowand@mvista.com]
Sent: Thursday, June 22, 2000 3:29 PM
To: Lucinda Schafer
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: Software Emulation Panic,
Lucinda Schafer wrote:
>
> When I get a kernel panic I see:
>
> NIP: 00001FFC XER: 8000FF7F LR: 00000988 REGS: c0e87c90 TRAP: 1000
> MSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
> TASK = c0e86000[7] 'rc.sysinit' mm->pgd c0e8b000 Last syscall: 67
> last math 00000000
> GPR00: 00000000 C0E87D40 C0E86000 C0E87D50 0189EE34 C0133404 C0E88278
> C0E8B000
> GPR08: C00DA634 00FBA9E1 00FBA9E1 00FBA9E1 3555F593 018A31D0 00000000
> 00000D08
> GPR16: 000000C1 01005000 0100A400 00300008 00001032 00E87D40 C00162F0
> 00009032
> GPR24: 0189EE34 C0E88278 C0615760 00FBA8A1 C0FBA000 C0E86000 C0F5F000
> C0132510
Look at the addresses that are of the form 0xCxxxxxxx in the backtrace, they
may give you a clue:
> Call backtrace:
> C0E87DF0 C0016204 C0016A98 C0009098 C0002544 018A4490 300E88A4
> 0180C6D4 0180C5D8 01803250 01802B64 01801D80
> Instruction DUMP:
>
> If the NIP = 00001FFC, then where is that? That is in the middle of
> "Trap_1f" according to the System.map.
>
> In the call backtrace, how do I know what addresses such as 018a4490 or
> 300e88a4 fall? System.map only has C000000++?
>
> Please be patient with me. I am still learning. I really need to figure
out
> what is going on here. I come from the world of 8051 assembly programmed
> into ROM. Memory management, task switching, and embedded operating
systems
> are new to me.
>
> Lucinda Schafer
> Staff Software Engineer
> Adaptive Micro-Ware, Inc.
>
-Frank
--
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Software Emulation Panic,
2000-06-22 20:39 Software Emulation Panic, Lucinda Schafer
@ 2000-06-22 22:33 ` Frank Rowand
0 siblings, 0 replies; 5+ messages in thread
From: Frank Rowand @ 2000-06-22 22:33 UTC (permalink / raw)
To: Lucinda Schafer; +Cc: frowand, linuxppc-embedded
Lucinda Schafer wrote:
>
> The results of the backtrace are as follows :
>
> C0016204 put_dirty_page
> C0016A98 handle_mm_fault
> C0009098 do_page_fault
> C0002544 _switch
> 018A4490 ???
> 300E88A4 ???
> 0180C6D4 ???
> 0180C5D8 ???
> 01803250 ???
> 01802B64 ???
> 01801D80 ???
>
> Which order are these called? I haven't been able to link all four together,
> although I do know that do_page_fault calls handle_mm_fault, the scheduler
> calls _switch, execve calls put_dirty_page via load_elf_binary. This all
> happens during the rc.sysinit.
You got the order right. According to this backtrace, _switch() called do_page_fault()
which called handle_mm_fault() which called put_dirty_page(). You left out the top of
the trace though, C0E87DF0. Is that a valid address (it often isn't)?
Some more clues:
The MSR is 00001000. Does this mean instruction translation is turned off (I don't recall
what processor this is on, so I can't look it up)? If so, then NIP: 00001FFC would be
the last instruction of Trap_1f. This is probably not a valid instruction, thus the
software emulation panic. In a kernel I have laying around (2.3.39 based, built for the
IBN 405GP processor) the instruction at the place is:
0xc0001ffc <Trap_1F+252>: .long 0x0
So the next question is how did you get to this location? A bad branch?
> -----Original Message-----
> From: Frank Rowand [mailto:frank_rowand@mvista.com]
> Sent: Thursday, June 22, 2000 3:29 PM
> To: Lucinda Schafer
> Cc: linuxppc-embedded@lists.linuxppc.org
> Subject: Re: Software Emulation Panic,
>
> Lucinda Schafer wrote:
> >
> > When I get a kernel panic I see:
> >
> > NIP: 00001FFC XER: 8000FF7F LR: 00000988 REGS: c0e87c90 TRAP: 1000
> > MSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
> > TASK = c0e86000[7] 'rc.sysinit' mm->pgd c0e8b000 Last syscall: 67
> > last math 00000000
> > GPR00: 00000000 C0E87D40 C0E86000 C0E87D50 0189EE34 C0133404 C0E88278
> > C0E8B000
> > GPR08: C00DA634 00FBA9E1 00FBA9E1 00FBA9E1 3555F593 018A31D0 00000000
> > 00000D08
> > GPR16: 000000C1 01005000 0100A400 00300008 00001032 00E87D40 C00162F0
> > 00009032
> > GPR24: 0189EE34 C0E88278 C0615760 00FBA8A1 C0FBA000 C0E86000 C0F5F000
> > C0132510
>
> Look at the addresses that are of the form 0xCxxxxxxx in the backtrace, they
> may give you a clue:
>
> > Call backtrace:
> > C0E87DF0 C0016204 C0016A98 C0009098 C0002544 018A4490 300E88A4
> > 0180C6D4 0180C5D8 01803250 01802B64 01801D80
> > Instruction DUMP:
> >
> > If the NIP = 00001FFC, then where is that? That is in the middle of
> > "Trap_1f" according to the System.map.
> >
> > In the call backtrace, how do I know what addresses such as 018a4490 or
> > 300e88a4 fall? System.map only has C000000++?
> >
> > Please be patient with me. I am still learning. I really need to figure
> out
> > what is going on here. I come from the world of 8051 assembly programmed
> > into ROM. Memory management, task switching, and embedded operating
> systems
> > are new to me.
> >
> > Lucinda Schafer
> > Staff Software Engineer
> > Adaptive Micro-Ware, Inc.
> >
>
> -Frank
> --
> Frank Rowand <frank_rowand@mvista.com>
> MontaVista Software, Inc
>
--
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Software Emulation Panic,
@ 2000-06-22 20:20 Lucinda Schafer
2000-06-22 20:29 ` Frank Rowand
2000-06-22 22:14 ` Dan Malek
0 siblings, 2 replies; 5+ messages in thread
From: Lucinda Schafer @ 2000-06-22 20:20 UTC (permalink / raw)
To: linuxppc-embedded
When I get a kernel panic I see:
NIP: 00001FFC XER: 8000FF7F LR: 00000988 REGS: c0e87c90 TRAP: 1000
MSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
TASK = c0e86000[7] 'rc.sysinit' mm->pgd c0e8b000 Last syscall: 67
last math 00000000
GPR00: 00000000 C0E87D40 C0E86000 C0E87D50 0189EE34 C0133404 C0E88278
C0E8B000
GPR08: C00DA634 00FBA9E1 00FBA9E1 00FBA9E1 3555F593 018A31D0 00000000
00000D08
GPR16: 000000C1 01005000 0100A400 00300008 00001032 00E87D40 C00162F0
00009032
GPR24: 0189EE34 C0E88278 C0615760 00FBA8A1 C0FBA000 C0E86000 C0F5F000
C0132510
Call backtrace:
C0E87DF0 C0016204 C0016A98 C0009098 C0002544 018A4490 300E88A4
0180C6D4 0180C5D8 01803250 01802B64 01801D80
Instruction DUMP:
If the NIP = 00001FFC, then where is that? That is in the middle of
"Trap_1f" according to the System.map.
In the call backtrace, how do I know what addresses such as 018a4490 or
300e88a4 fall? System.map only has C000000++?
Please be patient with me. I am still learning. I really need to figure out
what is going on here. I come from the world of 8051 assembly programmed
into ROM. Memory management, task switching, and embedded operating systems
are new to me.
Lucinda Schafer
Staff Software Engineer
Adaptive Micro-Ware, Inc.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Software Emulation Panic,
2000-06-22 20:20 Lucinda Schafer
@ 2000-06-22 20:29 ` Frank Rowand
2000-06-22 22:14 ` Dan Malek
1 sibling, 0 replies; 5+ messages in thread
From: Frank Rowand @ 2000-06-22 20:29 UTC (permalink / raw)
To: Lucinda Schafer; +Cc: linuxppc-embedded
Lucinda Schafer wrote:
>
> When I get a kernel panic I see:
>
> NIP: 00001FFC XER: 8000FF7F LR: 00000988 REGS: c0e87c90 TRAP: 1000
> MSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
> TASK = c0e86000[7] 'rc.sysinit' mm->pgd c0e8b000 Last syscall: 67
> last math 00000000
> GPR00: 00000000 C0E87D40 C0E86000 C0E87D50 0189EE34 C0133404 C0E88278
> C0E8B000
> GPR08: C00DA634 00FBA9E1 00FBA9E1 00FBA9E1 3555F593 018A31D0 00000000
> 00000D08
> GPR16: 000000C1 01005000 0100A400 00300008 00001032 00E87D40 C00162F0
> 00009032
> GPR24: 0189EE34 C0E88278 C0615760 00FBA8A1 C0FBA000 C0E86000 C0F5F000
> C0132510
Look at the addresses that are of the form 0xCxxxxxxx in the backtrace, they
may give you a clue:
> Call backtrace:
> C0E87DF0 C0016204 C0016A98 C0009098 C0002544 018A4490 300E88A4
> 0180C6D4 0180C5D8 01803250 01802B64 01801D80
> Instruction DUMP:
>
> If the NIP = 00001FFC, then where is that? That is in the middle of
> "Trap_1f" according to the System.map.
>
> In the call backtrace, how do I know what addresses such as 018a4490 or
> 300e88a4 fall? System.map only has C000000++?
>
> Please be patient with me. I am still learning. I really need to figure out
> what is going on here. I come from the world of 8051 assembly programmed
> into ROM. Memory management, task switching, and embedded operating systems
> are new to me.
>
> Lucinda Schafer
> Staff Software Engineer
> Adaptive Micro-Ware, Inc.
>
-Frank
--
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Software Emulation Panic,
2000-06-22 20:20 Lucinda Schafer
2000-06-22 20:29 ` Frank Rowand
@ 2000-06-22 22:14 ` Dan Malek
1 sibling, 0 replies; 5+ messages in thread
From: Dan Malek @ 2000-06-22 22:14 UTC (permalink / raw)
To: Lucinda Schafer; +Cc: linuxppc-embedded
Lucinda Schafer wrote:
>
> When I get a kernel panic I see:
>
> NIP: 00001FFC XER: 8000FF7F LR: 00000988 REGS: c0e87c90 TRAP: 1000
> MSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
Well, this one is pretty easy. PR, IR, DR all zero. So you were
executing in kernel space with the MMU disabled. This is standard
context phase 1 exception processing. Trap 0x1000 is an illegal
or unimplemented instruction.
The root of the problem is the kernel executed an illegal instruction
while exception processing. I know there isn't any valid code at
00001ffc, so you need to determine how it got there. Since the
kernel executes very little code in this state, you either have written
over some instructions, which isn't likely because the kernel is write
protected and you would get a different fault, or the memory subsystem
supplied some bogus bits during an instruction fetch, or while restoring
some processor context it read bad bits from memory.
I'd say, attach a logic analyzer, trigger on this trap, and determine
how it got those bits.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2000-06-22 22:33 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-06-22 20:39 Software Emulation Panic, Lucinda Schafer
2000-06-22 22:33 ` Frank Rowand
-- strict thread matches above, loose matches on Subject: below --
2000-06-22 20:20 Lucinda Schafer
2000-06-22 20:29 ` Frank Rowand
2000-06-22 22:14 ` Dan Malek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).