OK. I will check it. BTW following patch is responsible for irq change. http://git.linux-mips.org/?p=linux.git;a=commitdiff;h=df9ee29270c11dba7d0fe0b83ce47a4d8e8d2101 Thanks Anoop ________________________________________ From: Kevin D. Kissell [mailto:kevink@xxxxxxxxxxxxx] Sent: Wednesday, December 22, 2010 12:23 AM To: Anoop P A Cc: STUART VENTERS; linux-mips@xxxxxxxxxxxxxx; Anoop P.A. Subject: Re: SMTC support status in latest git head. OK, I see why the MT register dump isn't giving us useful information. It's not clear that it's at the root of your functional problems, though. Apparently, somebody decided that it was unwholesome to propagate anything other than the previous interrupt enable state in the flags variable passed between irq_save() and irq_restore(). I agree philosophically, but it does break the MT register dump function. And I'm quite sure that there were other bits of SMTC code that knew that it was a TCStatus value, at least in the earliest versions of the code. I'm not a gitweb power user, but I haven't been able to figure out how to determine when the "andi \\result 0x400" on or about line 138 of irqflags.h (at least that's where it is in the head of tree) was checked-in. If it's at the boundary between working and non-working versions for SMTC, it might be the cause of the problems, but it may well not be responsible for anything other than the problem with reporting the value in the MT register dump - which really ought to be fixed. I'm in a small village in France for the holidays with no git/build system at my disposal, but I think that if you were to tweak mips-mt.c at line 103 to change the tcstatval = flags; /* And pre-dump TCStatus is flags */ to something more like /* Pre-dump TCStatus Interrupt Inhibit bit is in flags variable */ tcstatval = (read_c0_tcstatus() & ~0x400) | flags; should fix the dump. Regards, Kevin K. On 12/20/10 2:44 AM, Anoop P A wrote: Hi Kevin, Please find disassembly for mips_mt_reg_dump Thanks Anoop Disassembly of section .text: 00000000 <mips_mt_regdump>: 0: 27bdffb8 addiu sp,sp,-72 4: 00802821 move a1,a0 8: afbf0044 sw ra,68(sp) c: afbe0040 sw s8,64(sp) 10: afb7003c sw s7,60(sp) 14: afb60038 sw s6,56(sp) 18: afb50034 sw s5,52(sp) 1c: afb40030 sw s4,48(sp) 20: afb3002c sw s3,44(sp) 24: afb20028 sw s2,40(sp) 28: afb10024 sw s1,36(sp) 2c: afb00020 sw s0,32(sp) 30: 40141001 mfc0 s4,c0_tcstatus 34: 36810400 ori at,s4,0x400 38: 40811001 mtc0 at,c0_tcstatus 3c: 32940400 andi s4,s4,0x400 40: 000000c0 ehb 44: 41610001 dvpe at 48: 0020a821 move s5,at 4c: 000000c0 ehb 50: 3c020000 lui v0,0x0 54: 24420060 addiu v0,v0,96 58: 00400408 jr.hb v0 5c: 00000000 nop 60: 3c040000 lui a0,0x0 64: 24840000 addiu a0,a0,0 68: 0c000000 jal 0 <mips_mt_regdump> 6c: afa50010 sw a1,16(sp) 70: 3c040000 lui a0,0x0 74: 0c000000 jal 0 <mips_mt_regdump> 78: 24840000 addiu a0,a0,0 7c: 8fa50010 lw a1,16(sp) 80: 3c040000 lui a0,0x0 84: 0c000000 jal 0 <mips_mt_regdump> 88: 24840000 addiu a0,a0,0 8c: 3c040000 lui a0,0x0 90: 24840000 addiu a0,a0,0 94: 0c000000 jal 0 <mips_mt_regdump> 98: 02a02821 move a1,s5 9c: 40110002 mfc0 s1,c0_mvpconf0 a0: 3c040000 lui a0,0x0 a4: 02202821 move a1,s1 a8: 0c000000 jal 0 <mips_mt_regdump> ac: 24840000 addiu a0,a0,0 b0: 3c040000 lui a0,0x0 b4: 0c000000 jal 0 <mips_mt_regdump> b8: 24840000 addiu a0,a0,0 bc: 7e331a80 ext s3,s1,0xa,0x4 c0: 3c090000 lui t1,0x0 c4: 323100ff andi s1,s1,0xff c8: 3c080000 lui t0,0x0 cc: 3c030000 lui v1,0x0 d0: 3c1e0000 lui s8,0x0 d4: 3c170000 lui s7,0x0 d8: 3c160000 lui s6,0x0 dc: 3c0a0000 lui t2,0x0 e0: 26730001 addiu s3,s3,1 e4: 26310001 addiu s1,s1,1 e8: 00008021 move s0,zero ec: 2412ff00 li s2,-256 f0: 25290000 addiu t1,t1,0 f4: 25080000 addiu t0,t0,0 f8: 24630000 addiu v1,v1,0 fc: 27de0000 addiu s8,s8,0 100: 26f70000 addiu s7,s7,0 104: 26d60000 addiu s6,s6,0 108: 254a0000 addiu t2,t2,0 10c: 00001021 move v0,zero 110: 40040801 mfc0 a0,c0_vpecontrol 114: 00922024 and a0,a0,s2 118: 00442025 or a0,v0,a0 11c: 40840801 mtc0 a0,c0_vpecontrol 120: 000000c0 ehb 124: 41020802 mftc0 at,c0_tcbind 128: 00202021 move a0,at 12c: 24420001 addiu v0,v0,1 130: 3084000f andi a0,a0,0xf 134: 12040031 beq s0,a0,1fc <mips_mt_regdump+0x1fc> 138: 0051282a slt a1,v0,s1 13c: 14a0fff4 bnez a1,110 <mips_mt_regdump+0x110> 140: 00000000 nop 144: 26100001 addiu s0,s0,1 148: 0213102a slt v0,s0,s3 14c: 1440fff0 bnez v0,110 <mips_mt_regdump+0x110> 150: 00001021 move v0,zero 154: 3c040000 lui a0,0x0 158: 24840000 addiu a0,a0,0 15c: 3c1e0000 lui s8,0x0 160: 3c170000 lui s7,0x0 164: 3c160000 lui s6,0x0 168: 3c130000 lui s3,0x0 16c: 0c000000 jal 0 <mips_mt_regdump> 170: 3c120000 lui s2,0x0 174: 00008021 move s0,zero 178: 27de0000 addiu s8,s8,0 17c: 26f70000 addiu s7,s7,0 180: 26d60000 addiu s6,s6,0 184: 26730000 addiu s3,s3,0 188: 26520000 addiu s2,s2,0 18c: 40020801 mfc0 v0,c0_vpecontrol 190: 2403ff00 li v1,-256 194: 00431024 and v0,v0,v1 198: 02021025 or v0,s0,v0 19c: 40820801 mtc0 v0,c0_vpecontrol 1a0: 000000c0 ehb 1a4: 41020802 mftc0 at,c0_tcbind 1a8: 00201821 move v1,at 1ac: 40021002 mfc0 v0,c0_tcbind 1b0: 1062003f beq v1,v0,2b0 <mips_mt_regdump+0x2b0> 1b4: 00000000 nop 1b8: 41020804 mftc0 at,c0_tchalt 1bc: 00201821 move v1,at 1c0: 24020001 li v0,1 1c4: 00400821 move at,v0 1c8: 41811004 mttc0 at,c0_tchalt 1cc: 41020801 mftc0 at,c0_tcstatus 1d0: 00203021 move a2,at 1d4: 3c040000 lui a0,0x0 1d8: 02002821 move a1,s0 1dc: 24840000 addiu a0,a0,0 1e0: afa3001c sw v1,28(sp) 1e4: 0c000000 jal 0 <mips_mt_regdump> 1e8: afa60010 sw a2,16(sp) 1ec: 8fa60010 lw a2,16(sp) 1f0: 8fa3001c lw v1,28(sp) 1f4: 080000b2 j 2c8 <mips_mt_regdump+0x2c8> 1f8: 00c02821 move a1,a2 1fc: 01202021 move a0,t1 200: 02002821 move a1,s0 204: afa3001c sw v1,28(sp) 208: afa80014 sw t0,20(sp) 20c: afa90010 sw t1,16(sp) 210: 0c000000 jal 0 <mips_mt_regdump> 214: afaa0018 sw t2,24(sp) 218: 41010801 mftc0 at,c0_vpecontrol 21c: 00202821 move a1,at 220: 8fa80014 lw t0,20(sp) 224: 0c000000 jal 0 <mips_mt_regdump> 228: 01002021 move a0,t0 22c: 41010802 mftc0 at,c0_vpeconf0 230: 00202821 move a1,at 234: 8fa3001c lw v1,28(sp) 238: 0c000000 jal 0 <mips_mt_regdump> 23c: 00602021 move a0,v1 240: 410c0800 mftc0 at,c0_status 244: 00203021 move a2,at 248: 03c02021 move a0,s8 24c: 0c000000 jal 0 <mips_mt_regdump> 250: 02002821 move a1,s0 254: 410e0800 mftc0 at,c0_epc 258: 00203021 move a2,at 25c: 410e0800 mftc0 at,c0_epc 260: 00203821 move a3,at 264: 02e02021 move a0,s7 268: 0c000000 jal 0 <mips_mt_regdump> 26c: 02002821 move a1,s0 270: 410d0800 mftc0 at,c0_cause 274: 00203021 move a2,at 278: 02c02021 move a0,s6 27c: 0c000000 jal 0 <mips_mt_regdump> 280: 02002821 move a1,s0 284: 41100807 mftc0 at,$16,7 288: 00203021 move a2,at 28c: 8faa0018 lw t2,24(sp) 290: 02002821 move a1,s0 294: 0c000000 jal 0 <mips_mt_regdump> 298: 01402021 move a0,t2 29c: 8fa3001c lw v1,28(sp) 2a0: 8fa80014 lw t0,20(sp) 2a4: 8fa90010 lw t1,16(sp) 2a8: 08000051 j 144 <mips_mt_regdump+0x144> 2ac: 8faa0018 lw t2,24(sp) 2b0: 3c040000 lui a0,0x0 2b4: 02002821 move a1,s0 2b8: 0c000000 jal 0 <mips_mt_regdump> 2bc: 24840000 addiu a0,a0,0 2c0: 00001821 move v1,zero 2c4: 02802821 move a1,s4 2c8: 03c02021 move a0,s8 2cc: 0c000000 jal 0 <mips_mt_regdump> 2d0: afa3001c sw v1,28(sp) 2d4: 41020802 mftc0 at,c0_tcbind 2d8: 00202821 move a1,at 2dc: 0c000000 jal 0 <mips_mt_regdump> 2e0: 02e02021 move a0,s7 2e4: 41020803 mftc0 at,c0_tcrestart 2e8: 00202821 move a1,at 2ec: 41020803 mftc0 at,c0_tcrestart 2f0: 00203021 move a2,at 2f4: 0c000000 jal 0 <mips_mt_regdump> 2f8: 02c02021 move a0,s6 2fc: 8fa3001c lw v1,28(sp) 300: 02602021 move a0,s3 304: 0c000000 jal 0 <mips_mt_regdump> 308: 00602821 move a1,v1 30c: 41020805 mftc0 at,c0_tccontext 310: 00202821 move a1,at 314: 0c000000 jal 0 <mips_mt_regdump> 318: 02402021 move a0,s2 31c: 8fa3001c lw v1,28(sp) 320: 14600003 bnez v1,330 <mips_mt_regdump+0x330> 324: 00001021 move v0,zero 328: 00400821 move at,v0 32c: 41811004 mttc0 at,c0_tchalt 330: 26100001 addiu s0,s0,1 334: 0211102a slt v0,s0,s1 338: 1440ff94 bnez v0,18c <mips_mt_regdump+0x18c> 33c: 00000000 nop 340: 0c000000 jal 0 <mips_mt_regdump> 344: 32b50001 andi s5,s5,0x1 348: 3c040000 lui a0,0x0 34c: 0c000000 jal 0 <mips_mt_regdump> 350: 24840000 addiu a0,a0,0 354: 12a00004 beqz s5,368 <mips_mt_regdump+0x368> 358: 32820400 andi v0,s4,0x400 35c: 41600021 evpe 360: 000000c0 ehb 364: 32820400 andi v0,s4,0x400 368: 14400003 bnez v0,378 <mips_mt_regdump+0x378> 36c: 00000000 nop 370: 0c000000 jal 0 <mips_mt_regdump> 374: 00000000 nop 378: 40011001 mfc0 at,c0_tcstatus 37c: 32940400 andi s4,s4,0x400 380: 34210400 ori at,at,0x400 384: 38210400 xori at,at,0x400 388: 0281a025 or s4,s4,at 38c: 40941001 mtc0 s4,c0_tcstatus 390: 000000c0 ehb 394: 8fbf0044 lw ra,68(sp) 398: 8fbe0040 lw s8,64(sp) 39c: 8fb7003c lw s7,60(sp) 3a0: 8fb60038 lw s6,56(sp) 3a4: 8fb50034 lw s5,52(sp) 3a8: 8fb40030 lw s4,48(sp) 3ac: 8fb3002c lw s3,44(sp) 3b0: 8fb20028 lw s2,40(sp) 3b4: 8fb10024 lw s1,36(sp) 3b8: 8fb00020 lw s0,32(sp) 3bc: 03e00008 jr ra 3c0: 27bd0048 addiu sp,sp,72 On Sat, Dec 18, 2010 at 3:05 AM, Kevin D. Kissell <kevink@xxxxxxxxxxxxx> wrote: So, Anoop, if you get a minute for this any time in the next day or so (after which I'll have very limited net access until next year), could you please do an <mumble>-mips<mumble>-objdump --disassemble of your kernel image (or even just the mips-mt.o module) from a failing kernel build and post the disassembly of mips_mt_regdump()? The confirmation or refutation of the theory about local_irq_save() no longer being built correctly for SMTC would be within the first few instructions... /K. On 12/16/10 11:58, Kevin D. Kissell wrote: Ralf tells me that this message got blocked by the LMO server due to HTML content. So here it is again, textier. On 12/16/10 11:24, Kevin D. Kissell wrote: On 12/16/10 07:37, STUART VENTERS wrote: Two other possible clues: The EVP is clear in the MVPControl register. Does this say that only VPE0, T0 gets to run? That's correct. In the maxtcs=1/maxvpes=1 boot state, it wouldn't matter. It's just possible that setting EVP is conditional on more than one VPE being used, but that's not the way I remember it. Also the EXCPT bits in VPEControl for VPE1 indicate a Gating Storage Exception dispatch. But that seems to conflict the EVP bit above. I don't have a copy of the ASE spec handy to see whether those bits have a defined power-on value, but particularly if maxvpes=1 was set at boot time, I would expect VPE1's registers to be in a partly random power-up state. Perhaps these are an artifact of getting to a good state to dump things out. As per my previous mail, I looked at the MT register dump source, and it really does pull values directly out of registers and doesn't depend on having a sane kernel stack frame. The exceptions to that rule are the reported values for TCStatus of the executing TC, which is based on the perhaps-now-broken assumption that local_irq_save(flags) stores the *entire* pre-invocation value of the TCStatus register in the flags variable, and MVPcontrol, which is based on the assumption that dvpe() returns the pre-invocation value of MVPcontrol. Break those assumptions, and you'll get inconsistent state dumps like this, and very possibly incorrect execution. Particularly if what was done was that effectively replaces the SMTC-specific implementation of local_irq_save()/local_irq_restore() with something that uses the generic MIPS32R2 atomic interrupt enable/disable instructions. That would have been a *very* bad idea... Regards, Kevin K.
