This is the stack trace. Registers: GPR00: 00069030 C01F3000 C01F1080 00000000 00048000 C0639F48 C01F1080 FFFFFC18 GPR08: C02203FC 00000020 C0638000 C01F31B0 42FEE022 1056A7F8 00FE502A 00000000 GPR16: 00000000 FFC44232 00000000 00000000 FFC441EC 00080000 00010000 0000000A GPR24: 00000000 0007CD80 00000CE0 00000000 00000000 C02B0000 00000000 C02B0000 NIP; c0005da4 _<_nmask_and_or_msr+0x18/0x20 [kernel]> Trace; c0025328 _ Trace; c0004f4c _ Trace; c0004f74 _ Trace; c00012b0 _ Trace; c02a45a4 _ Trace; c0000250 _ On 9/20/06, Benjamin Herrenschmidt wrote: > > On Tue, 2006-09-19 at 18:16 -0700, Manoj Sharma wrote: > > Hi, > > > > We use linux kernel 2.4.20 on ppc405 and the system hangs once > > in a while when isync gets called in this function: > > > > _GLOBAL(_nmask_and_or_msr) > > mfmsr r0 /* Get current msr */ > > andc r0,r0,r3 /* And off the bits set in r3 (first > > parm) */` > > or r0,r0,r4 /* Or on the bits in r4 (second parm) */ > > sync /* Some chip revs have problems here... */ > > isync > > mtmsr r0 /* Update machine state */ > > isync > > blr /* Done */ > > > > 2.5 onwards, I find that "sync; isync" has been replaced by a > > macro SYNC (defined only for 601). I don't find it in any > > changelog and reason for the change. > > > > Can someone give some information on this change? > > Regardless of the change... on 2.4, _nmask_and_or_msr() was used for a > number of things. We would need to know where it was called from with > what values as arguments to have an idea of what's going wrong. It's > probably not dying on the isync, but rather on the following mtmsr due > to a problem with the values passed in.... > > Ben. > > > >