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.
