Re: SMTC support status in latest git head.

["Kevin D. Kissell" <kevink@paralogos.com>]

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.
>
>