Sorry I misunderstood file. git blame shows that "andi" is around for quite
sometime .
49a89efb include/asm-mips/irqflags.h (Ralf Baechle 2007-10-11 23:46:15
+0100 128) __asm__(
df9ee292 arch/mips/include/asm/irqflags.h (David Howells 2010-10-07 14:08:55
+0100 129) " .macro arch_local_irq_save result
ff88f8a3 include/asm-mips/interrupt.h (Ralf Baechle 2005-07-12 14:54:31
+0000 130) " .set push
ff88f8a3 include/asm-mips/interrupt.h (Ralf Baechle 2005-07-12 14:54:31
+0000 131) " .set reorder
ff88f8a3 include/asm-mips/interrupt.h (Ralf Baechle 2005-07-12 14:54:31
+0000 132) " .set noat
41c594ab include/asm-mips/interrupt.h (Ralf Baechle 2006-04-05 09:45:45
+0100 133) #ifdef CONFIG_MIPS_MT_SMTC
41c594ab include/asm-mips/interrupt.h (Ralf Baechle 2006-04-05 09:45:45
+0100 134) " mfc0 \\result, $2, 1
41c594ab include/asm-mips/interrupt.h (Ralf Baechle 2006-04-05 09:45:45
+0100 135) " ori $1, \\result, 0x400
41c594ab include/asm-mips/interrupt.h (Ralf Baechle 2006-04-05 09:45:45
+0100 136) " .set noreorder
41c594ab include/asm-mips/interrupt.h (Ralf Baechle 2006-04-05 09:45:45
+0100 137) " mtc0 $1, $2, 1
41c594ab include/asm-mips/interrupt.h (Ralf Baechle 2006-04-05 09:45:45
+0100 138) " andi \\result, \\result, 0x400
41c594ab include/asm-mips/interrupt.h (Ralf Baechle 2006-04-05 09:45:45
+0100 139) #elif defined(CONFIG_CPU_MIPSR2)
ff88f8a3 include/asm-mips/interrupt.h (Ralf Baechle 2005-07-12 14:54:31
+0000 140) " di \\result
15265251 include/asm-mips/interrupt.h (Maxime Bizon 2005-12-20 06:32:19
+0100 141) " andi \\result, 1
ff88f8a3 include/asm-mips/interrupt.h (Ralf Baechle 2005-07-12 14:54:31
+0000 142) #else
ff88f8a3 include/asm-mips/interrupt.h (Ralf Baechle 2005-07-12 14:54:31
+0000 143) " mfc0 \\result, $12
c226f260 include/asm-mips/interrupt.h (Atsushi Nemoto 2006-02-03 01:34:01
+0900 144) " ori $1, \\result, 0x1f
c226f260 include/asm-mips/interrupt.h (Atsushi Nemoto 2006-02-03 01:34:01
+0900 145) " xori $1, 0x1f
ff88f8a3 include/asm-mips/interrupt.h (Ralf Baechle 2005-07-12 14:54:31
+0000 146) " .set noreorder
ff88f8a3 include/asm-mips/interrupt.h (Ralf Baechle 2005-07-12 14:54:31
+0000 147) " mtc0 $1, $12
ff88f8a3 include/asm-mips/interrupt.h (Ralf Baechle 2005-07-12 14:54:31
+0000 148) #endif
ff88f8a3 include/asm-mips/interrupt.h (Ralf Baechle 2005-07-12 14:54:31
+0000 149) " irq_disable_hazard
ff88f8a3 include/asm-mips/interrupt.h (Ralf Baechle 2005-07-12 14:54:31
+0000 150) " .set pop
ff88f8a3 include/asm-mips/interrupt.h (Ralf Baechle 2005-07-12 14:54:31
+0000 151) " .endm
^1da177e include/asm-mips/interrupt.h (Linus Torvalds 2005-04-16 15:20:36
-0700 152)
> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-
> mips.org] On Behalf Of Anoop P.A.
> Sent: Wednesday, December 22, 2010 1:37 AM
> To: Kevin D. Kissell; Anoop P A
> Cc: STUART VENTERS; linux-mips@linux-mips.org
> Subject: RE: SMTC support status in latest git head.
>
>
> OK. I will check it.
>
> BTW following patch is responsible for irq change.
>
> http://git.linux-
> mips.org/?p=linux.git;a=commitdiff;h=df9ee29270c11dba7d0fe0b83ce47a4d8e8d2
> 101
>
> Thanks
> Anoop
> ________________________________________
> From: Kevin D. Kissell [mailto:kevink@paralogos.com]
> Sent: Wednesday, December 22, 2010 12:23 AM
> To: Anoop P A
> Cc: STUART VENTERS; linux-mips@linux-mips.org; 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@paralogos.com>
> 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.
>
>
>
|