Re: SMTC support status in latest git head.

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

I used to do occasional tests and damage control patches for SMTC, but 
haven't had the time and resources for the past year or so.  The 
"Calibrating delay loop" hang is an absolutely classic hang in SMTC 
systems that stems from the interrupt management system not being 
properly set up.  Ralf alluded to the intra-TC timer propagation 
protocol, but your problem could just as easily (more easily, actually) 
have to do with enable mask management. In order to keep multiple 
threads from "convoying" into interrupt handlers chasing a single event, 
SMTC manipulates the interrupt enable mask at entry into an interrupt 
exception to ensure that only the initial TC goes after it.  The 
interrupt is unmasked once the interrupt handler has quenched the source 
and invoked the IRQ ack function.  Unfortunately, generic timer 
functions don't always do the canonical source quench performed by most 
device driver interrupt handlers. I tried to make all this 
self-contained in generic architecture-specific code, but at some point 
it ended up being cleaner and more efficient to have *some* hooks in 
platform specific timer code.  It was there for Malta in the kernel.org 
mainline once upon a time, and I *thought* we'd propagated working code 
for the initial PMC-Sierra 34K-based SoC's at least as far as 
linux-mips.org, but the source tree has been considerably reorganized - 
there was a time when some of the hooks were under 
arch/mips/mips-boards/generic, which no longer exists - and I'm not sure 
where to point you.  Git and grep are your friends.

The first order of business is to break into that hung timer calibration 
loop and dump the CP0 registers for the VPE and the TCs, in particular 
checking the interrupt enable mask in Status against the pending 
interrupts in the Cause register.   If you're seeing the timer 
interrupt's bit set in Cause, but clear in Status, you need to fix the 
SMTC interrupt mask hook for your platform timer.  If that's *not* it, 
check to see if you're building for "tickless" operation.  Tickless ends 
up being really important for SMTC, and I did get it working properly 
back in 2008, but I the SMTC-specific cevt-smtc.c code uses common 
functions in cevt-r4k.c, and I've seen some patches to cevt-r4k.c going 
by that I rather doubt were ever tested against an SMTC build/platform.  
There might have been breakage there, and configuring to use a fixed 
interval timer (say, 100Hz) would be a way to test that hypothesis.

             Regards,

             Kevin K.

On 12/08/10 05:48, Anoop P.A. wrote:
> Hi list,
>
> Any body is aware of SMTC support status in latest git sources?. I have tried testing SMTC kernel for malta in qemu / OVP without any success ( emulators not working for 34k).
>
> I am trying to bring up SMTC Linux support for an mips34K based soc ( MSP71xx family).
>
> While booting , kernel getting hung on calibrate loop delay. I am getting only one interrupt from timer. With similar smtc platform support file (  changed to map smp_ops structure)  2.6.24-stable branch kernel ( where latest timer structure introduced) boots fine.
>
> [    0.000000] Linux version 2.6.37-rc1-pmc-00197-g5bfd3ba-dirty (paanoop1@paanoop1-desktop) (gcc version 4.5.1 (GCC) ) #168 SMP PREEMPT Wed Dec 8 19:19:490
> [    0.000000] DSPRAM0: PA=1c100000,Size=00008000,enabled
> [    0.000000] UART clock set to 50000000
> [    0.000000] CPU revision is: 00019548 (MIPS 34Kc)
> [    0.000000] Determined physical RAM map:
> [    0.000000]  memory: 00001000 @ 00000000 (reserved)
> [    0.000000]  memory: 000ff000 @ 00001000 (usable)
> [    0.000000]  memory: 003f2000 @ 00100000 (reserved)
> [    0.000000]  memory: 0fad9200 @ 004f2000 (usable)
> [    0.000000] Wasting 32 bytes for tracking 1 unused pages
> [    0.000000] Zone PFN ranges:
> [    0.000000]   Normal   0x00000000 ->  0x0000ffcb
> [    0.000000] Movable zone start PFN for each node
> [    0.000000] early_node_map[1] active PFN ranges
> [    0.000000]     0: 0x00000000 ->  0x0000ffcb
> [    0.000000] 6 available secondary CPU TC(s)
> [    0.000000] PERCPU: Embedded 7 pages/cpu @81203000 s6464 r8192 d14016 u32768
> [    0.000000] pcpu-alloc: s6464 r8192 d14016 u32768 alloc=8*4096
> [    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6
> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 64971
> [    0.000000] Kernel command line: console=ttyS0,57600
> [    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
> [    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> [    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> [    0.000000] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
> [    0.000000] Primary data cache 64kB, 4-way, PIPT, no aliases, linesize 32 bytes
> [    0.000000] Writing ErrCtl register=00000000
> [    0.000000] Readback ErrCtl register=00000000
> [    0.000000] Memory: 254360k/257888k available (3081k kernel code, 3528k reserved, 653k data, 200k init, 0k highmem)
> [    0.000000] Preemptable hierarchical RCU implementation.
> [    0.000000] NR_IRQS:128
> [    0.000000] console [ttyS0] enabled
> [    0.000000] Clock rate set to 600000000
> [    0.000000] Calibrating delay loop...
>
> Any idea to debug the issue ?.
>
> Thanks,
> Anoop
>
>
>
>