[Top] [All Lists]

Re: SMTC support status in latest git head.

To: Anoop P A <>
Subject: Re: SMTC support status in latest git head.
From: "Kevin D. Kissell" <>
Date: Wed, 22 Dec 2010 05:03:03 -0800
Cc: "Anoop P.A." <>, STUART VENTERS <>,
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default;; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Source:X-Source-Args:X-Source-Dir; b=JSGqu+v3HoFFzOnFa3Xs3F6Wv/9BVyVmBjAZ86ChBGSFtOru84MBWj4oV/vSwlKRhQONYtknFAtzCX5uJcs8HAv6yN0Z651yLUCL6qnBKKmMCymYkB8iOkoNkjjpSICT;
In-reply-to: <1293018675.27661.40.camel@paanoop1-desktop>
Original-recipient: rfc822;
References: <> <> <> <> <> <> <> <> <> <1293017702.27661.36.camel@paanoop1-desktop> <> <1293018675.27661.40.camel@paanoop1-desktop>
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20101207 Thunderbird/3.1.7
On 12/22/10 3:51 AM, Anoop P A wrote:
On Wed, 2010-12-22 at 03:37 -0800, Kevin D. Kissell wrote:
Thanks.  This is indeed strange.  The VPE0 Status and TC0 TCStatus/Cause
all indicate that interrupts are enabled and not inhibited at the per-TC
level, and the presumed timer interrupt, in the 0x4000 bit, is present
and not masked-off.  Logically, the system must be entering (and
exiting) the interrupt handler, yet the timer calibration isn't
completing.  That leaves more complex possible explanations for failure,
most of which would fall into two categories:

1)  The platform interrupt handler is failing to decode the event
properly as a timer event.
2)  Despite there being only one TC active, the calibration code is
waiting for some handshake from another "CPU"

To test the first, you might consider adding a kprintf() to the case of
a "spurious" timer-like interrupt being detected and ignored...
I have tried it . only one interrupt is coming and platform handler
detect it as timer interrupt and acknowledges properly . you can see a
time stamp change in the logs.
That's really strange. And your timer interrupt is definitely on the interrupt that corresponds to the 0x4000 mask?

I may have written the MT spec and the original SMTC code, but I don't have a copy of the spec, and it's been a few years, and I can't interpret the MVP and VPE control/config values. But I just don't see how the processor could not be taking more interrupts. Stuart did decode the global/VPE state enough to observe that global multithreaded execution wasn't enabled, which is indeed strange - it shouldn't matter for single-TC execution, but I don't recall there being any special-case in the SMTC initialization that bypassed that enable. That makes me suspect that maybe someone changed the initialization sequence in a way that bypasses one of the canonical initialization steps in a way that would break SMTC, but I don't know why that would result in the interrupt behavior you observe.

It might be yet another blind alley, but could you add/arm diagnostic output for each of the initialization functions in smtc.c?

Ah, yes, and one other thing. You should add a dump of ErrorEPC to the MT register dump. I did it for myself once upon a time when I was confronted with a similar mystery, but never filed a patch. If you're breaking in with NMI, that could help identify more precisely where it's locking up.

You really ought to try to borrow an EJTAG probe. It would save us both a lot of time. And my time to trouble-shoot this with you is limited.


            Kevin K.

<Prev in Thread] Current Thread [Next in Thread>