Hang with isync

Liu Dave-r63238 DaveLiu at freescale.com
Thu Sep 21 16:27:14 EST 2006

First, you must make sure if it really happen at watchdog timer
if it is, you need select one suitable way to fix it.
Second, I don't believe the sync-isync instructions make it happen.
you can try the 2.6, I don't know if 2.6 kernel can resolve your


	Dave, watchdog timeout is around one second and no cpu activity
for that long is something wrong. Is it ok to disable it to hide the
problem lying somewhere else? Do you think it can be because of
sync-isync instructions and moving to 2.6 might resolve it?

	On 9/20/06, Liu Dave-r63238 <DaveLiu at freescale.com> wrote: 


		No MSR is 00029030 and user mode bit is not set here.
		I had missed it in the prev mail:
		NIP: C0005DA4 XER: 20000000 LR: C0004FE4 SP: C01F3000
REGS: c01eff30 TRAP: 1020    Not tainted 
		MSR: 00029030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 
		TASK = c01f1080[0] 'swapper' Last syscall: 120
		last math 00000000 last altivec 00000000
		PLB0: bear= 0x08000000 acr=   0xbb000000 besr=
		Dave>I notice that MSR and TRAP, MSR is 00029030- the
critical interrupt enable.
		Dave>TRAP is 1020. --WatchDog timer exception is
		Dave>You can disable the MSR[CE] bit to no critical
exception or disable the WD timer


			On 9/20/06, Linas Vepstas <linas at austin.ibm.com
> wrote: 

				On Thu, Sep 21, 2006 at 08:38:13AM
+1000, Benjamin Herrenschmidt wrote:
				> On Wed, 2006-09-20 at 15:31 -0700,
Manoj Sharma wrote: 
				> > This is the stack trace.
				> >
				> > Registers:
				> > GPR00: 00069030 
				This is the MSR and it has the user-mode
bit set, which is surely wrong.
				This is not how one gets to user space. 
				The MSR had this or'ed into it, which is
setting the user-mode bit.
				Surely that's wrong. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20060921/da684ec9/attachment.htm>

More information about the Linuxppc-dev mailing list