Kamalesh Babulal writes: > I tried reproducing the problem and was successful with following trace > in which the pc is at 0x4570 as the above one
What did you do to trigger it? > c000000000004544 <unrecov_slb>: > c000000000004544: 71 8a 40 00 andi. r10,r12,16384 > c000000000004548: 7c 2a 0b 78 mr r10,r1 > c00000000000454c: 38 21 fd 10 addi r1,r1,-752 > c000000000004550: 41 82 00 08 beq- c000000000004558 > <unrecov_slb+0x14> > c000000000004554: e8 2d 01 a8 ld r1,424(r13) > c000000000004558: 2c a1 00 00 cmpdi cr1,r1,0 > c00000000000455c: 40 84 00 08 bge- cr1,c000000000004564 > <unrecov_slb+0x20> > c000000000004560: 48 00 00 10 b c000000000004570 > <unrecov_slb+0x2c> > c000000000004564: 38 20 41 00 li r1,16640 > c000000000004568: b0 2d 01 c8 sth r1,456(r13) > c00000000000456c: 4b ff fb 18 b c000000000004084 <bad_stack> > c000000000004570: f9 21 01 a0 std r9,416(r1) So it's in the code that gets called on an unrecoverable SLB fault. That's bad, we should never get those. Does this happen with mainline too, or only with -rc8-mm1? I don't understand why we should start seeing this problem unless something has changed in arch/powerpc/kernel or arch/powerpc/mm (well I suppose a bug somewhere else could cause memory corruption which might be able to lead to this). Does it still happen if you take git-powerpc.patch out of the series? Paul. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
