Re: SMTC support status in latest git head.

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

Getting back to my previous comment, the value reported for
TC0's TCStatus register in the MT register dump can't be right.
There are bits that are literally the same flip-flops between
TCStatus and the containing VPE's Status register, and those
bits are turning up different.  If the reporting is wrong, then
one of the underlying assumptions of the dump code must
have been broken.  Taking a quick look at it - which is all the
time I have for it today - I note with alarm that the TCStatus
value reported for the TC currently executing comes from the
"flags" variable used in the local_irq_save(flags) statement
at the beginning of the dump code.  That historically worked,
because local_irq_save(x) propagated not only the interrupt
enable bit (bit 0) in x, but the entire value of Status - or TCStatus
in the case of SMTC.  It certainly looks as if that's no longer true.
I'm pretty sure that the dump function isn't the only place where
the knowledge of local_irq_save()'s implementation was exploited
by SMTC code.  So you look for changes to the local_irq_save()
macro definitions between 2.6.32 and 2.6.33.

The fact that you're blowing up on a DSP after you force an
exit from the timer calibration loop might also be attributable
to TCStatus is getting trashed, accidentally clearing access
rights to the DSP ASE state.

Honestly, just how many lines changed under arch/mips
(and include/asm-mips, if it was still outside arch/mips)
between 2.6.32 and 2.6.33?  There simply can't be that
many to review.

             Regards,

             Kevin K.

On 12/16/10 05:03, Anoop P A wrote:
> On Wed, 2010-12-15 at 11:58 -0800, Kevin D. Kissell wrote:
>> On 12/15/10 11:18, Anoop P A wrote:
>>>> management algorithms I described
>>> Even with command line maxtcs=1 and maxvpes=1 I am seeing same hung. The
>>> register dump is copied below.
>> I guess what jumps out at me is that VPE0.EPC doesn't look to have
>> changed since the very initial boot vector, as if we'd never successfully
>> taken an exception or interrupt of any kind, prior to the NMI (I'm assuming
>> you're getting that MT state dump by breaking in with an NMI).
>> I'm puzzled that TC0.TCStatus is being reported as 0, when it should
>> have a bunch of bits in common with VPE0.Status.  And I'm particularly
>> intrigued by the fact that you seem to have an interrupt bit set in Cause
>> which is enabled in Status, with IE set and EXL/ERL clear, yet you don't
>> seem to be getting interrupts.
>>
>> Do you have access to some kind of EJTAG probe for your system?
> Unfortunately I don't have access to a working EJTAG at the moment.
>
>>> I have tested few stable tags in git and isolated the code brake.
>>>
>>> 2.6.24-stable + patch[1] = SMTC boot success
>>> 2.6.29-stable + patch[1] = SMTC boot success
>>> 2.6.31-stable + patch[1] = SMTC boot success
>>> 2.6.32-stable + patch[1] = SMTC boot success
>>> 2.6.33-stable		 = SMTC boot failed
>>> 2.6.35-stable 		 = SMTC boot failed
>>>
>>> So it looks like SMTC support got broke between 2.6.32 and 2.6.33 .
>> That's a pretty good job of isolating the problem, and the fact
>> that it happens even with no TC or VPE concurrency means it's
>> not a failure of the SMTC logic per se, but that someone changed
>> some code that's common to SMTC and "normal"/SMP operation
>> in a way that breaks the more constrained assumptions of SMTC.
>>
> I have tried digging diff between 2.6.32 and 2.6.33 but I couldn't spot
> any likely causes.
>
> I forgot to mention that I can boot newer kernels both in VSMP and UP
> mode.
>
> The other thing I have tried is booting kernel with pre-set lpj ( Just
> to test how far I can go), which lead me to a dsp exception (spurious ?)
>
> Let me know if you have any thoughts .
>
> Thanks,
> Anoop
>
> ################# log #############
>
> Linux version 2.6.33.7-pmc (paanoop1@paanoop1-desktop) (gcc version
> 4.5.1 (GCC) ) #27 SMP PREEMPT Thu Dec 16 17:49:46 IST 2010
> DSPRAM0: PA=1c100000,Size=00008000,enabled
> UART clock set to 50000000
> CPU revision is: 00019548 (MIPS 34Kc)
> Determined physical RAM map:
>   memory: 00001000 @ 00000000 (reserved)
>   memory: 000ff000 @ 00001000 (usable)
>   memory: 00271000 @ 00100000 (reserved)
>   memory: 0fc5a200 @ 00371000 (usable)
> Wasting 32 bytes for tracking 1 unused pages
> Zone PFN ranges:
>    Normal   0x00000000 ->  0x0000ffcb
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
>      0: 0x00000000 ->  0x0000ffcb
> 6 available secondary CPU TC(s)
> PERCPU: Embedded 7 pages/cpu @81203000 s4896 r8192 d15584 u65536
> pcpu-alloc: s4896 r8192 d15584 u65536 alloc=16*4096
> pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages:
> 64971
> Kernel command line: console=ttyS0,57600 lpj=796672
> PID hash table entries: 1024 (order: 0, 4096 bytes)
> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
> Primary data cache 64kB, 4-way, PIPT, no aliases, linesize 32 bytes
> Writing ErrCtl register=00000000
> Readback ErrCtl register=00000000
> Memory: 255548k/259428k available (1861k kernel code, 3504k reserved,
> 400k data, 156k init, 0k highmem)
> Hierarchical RCU implementation.
> NR_IRQS:128
> Clock rate set to 600000000
> console [ttyS0] enabled
> Calibrating delay loop (skipped) preset value.. 398.33 BogoMIPS
> (lpj=796672)
> Mount-cache hash table entries: 512
> Cpu 0
> $ 0   : 00000000 10102000 00000010 00000003
> $ 4   : 00000003 00000000 00000000 8f82f758
> $ 8   : 00000000 00000000 00000000 00000000
> $12   : 00000000 00000007 8f82301c 00000000
> $16   : 8f82f758 00800b00 8035d3c0 8f830000
> $20   : 80329df8 00000000 8035d3c0 80360000
> $24   : 00000000 00000001
> $28   : 80328000 80329ce0 8f82f868 8010d018
> Hi    : 0000004c
> Lo    : 3831f4b4
> epc   : 8010d054 copy_thread+0x88/0x348
>      Not tainted
> ra    : 8010d018 copy_thread+0x4c/0x348
> Status: 10102000    KERNEL
> Cause : 50804068
> PrId  : 00019548 (MIPS 34Kc)
> Kernel panic - not syncing: Unexpected DSP exception
>
>