Thank you, Stuart! I've spotted some definite breakage to SMTC between
those versions. In arch/mips/include/asm/stackframe.h, someone moved
the store of the Status register value in SAVE_SOME (line 169 or 204,
depending on the version) from two instructions after the mfc0 to a
point after the #ifdef for SMTC, presumably to get better pipelining of
the register access. Unfortunately, the v1 register is also used in the
SMTC-specific fragment to save TCStatus, so the Status value gets
clobbered before it gets stored. This will eventually result in the
Status register getting a TCStatus value, which has some bits on common,
but isn't identical and sooner or later Bad Things will happen.
I'm a little surprised this wasn't caught by visual inspection of the patch.
Possible solutions would include reverting the store of the CP0_STATUS
value to the block above the #ifdef, or, to retain whatever performance
advantage was obtained by moving the store downward, to use v0/$2
instead of v1/$3, as the staging register for the TCStatus value. I'd
lean toward the second option, but I'm not in a position to test and
submit a patch just now.
Regards,
Kevin K.
On 12/23/10 1:09 PM, STUART VENTERS wrote:
Kevin,
I'm not sure if it's useful,
but finally I got the time to look at the two kernel versions Anoop pointed out.
works 2.6.32-stable with patch 804
works_not 2.6.33-stable
greping for files with CONFIG_MIPS_MT_SMTC
and looking for timer interrupt related stuff found the following differences:
arch/mips/include/asm/irq.h
arch/mips/kernel/irq.c
do_IRQ
arch/mips/include/asm/stackframe.h
SAVE_SOME SAVE_TEMP get/set_saved_sp
arch/mips/include/asm/time.h
clocksource_set_clock
arch/mips/kernel/process.c
cpu_idle
arch/mips/kernel/smtc.c
__irq_entry
ipi_decode
SMTC_CLOCK_TICK
Enclosed are the two subsets of files for a more expert look.
I'll try to look in more detail after Christmas.
Cheers,
Stuart
