[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: Fri, 24 Dec 2010 15:34:18 -0800
Cc: STUART VENTERS <>, "Anoop P.A." <>,
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=h4675lkYmZ/Scntbz1255AsLG43RXH3tt9vjS8jME3aFnyx9kJnm/aGP3jhjz1RqFtMgSemlHc16QENZbg3ZvKv/A5NkwsUchxwvb5GsF+H7mK33BqpO+Uy7XG1R6nEH;
In-reply-to: <1293206536.27661.63.camel@paanoop1-desktop>
Original-recipient: rfc822;
References: <> <> <1293201545.27661.55.camel@paanoop1-desktop> <> <1293206536.27661.63.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
Ah, well, at least we have a stackframe.h fix that preserves David's performance tweak for the deeper pipelined processors. In looking for this, I did notice that someone did some modification to the SMTC clock tick logic that I was skeptical had ever been tested. If you've still got that kernel binary handy, you might check to see if it boots with maxtcs=1 maxvpes=1, maxtcs=2 maxvpes=1, and/or maxtcs=2 maxvpes=2.

Oh, yes, and Merry Christmas one and all!


            Kevin K.

On 12/24/10 8:02 AM, Anoop P A wrote:
On Fri, 2010-12-24 at 06:53 -0800, Kevin D. Kissell wrote:
Excellent!  Now, does the attached patch (relative to also
fix things, while preserving the other fixes and performance enhancements?

I have tested that patch with 2.6.37 branch it well passes calibration
loop but hangs after switching to mips closource

TC 6 going on-line as CPU 6
Brought up 7 CPUs
bio: create slab<bio-0>  at 0
SCSI subsystem initialized
Switching to clocksource MIPS

I Presume this is a different issue as restoring older file didn't help
much to get rid of this hang.

diff --git a/arch/mips/include/asm/stackframe.h
index 58730c5..7fc9f10 100644
--- a/arch/mips/include/asm/stackframe.h
+++ b/arch/mips/include/asm/stackframe.h
@@ -195,9 +195,9 @@
                 * to cover the pipeline delay.
                .set    mips32
-               mfc0    v1, CP0_TCSTATUS
+               mfc0    v0, CP0_TCSTATUS
                .set    mips0
-               LONG_S  v1, PT_TCSTATUS(sp)
+               LONG_S  v0, PT_TCSTATUS(sp)
  #endif /* CONFIG_MIPS_MT_SMTC */
                LONG_S  $4, PT_R4(sp)
                LONG_S  $5, PT_R5(sp)


On 12/24/10 6:39 AM, Anoop P A wrote:
Hi Kevin, Stuart ,

Woohooo You guys spotted !.;a=commit;h=d5ec6e3c seems to be
the culprit

Once I restored previous version of stackframe.h 2.6.33-stable started
booting !.


On Fri, 2010-12-24 at 04:32 -0800, Kevin D. Kissell wrote:
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.


               Kevin K.

On 12/23/10 1:09 PM, STUART VENTERS wrote:

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 


     SAVE_SOME SAVE_TEMP get/set_saved_sp




Enclosed are the two subsets of files for a more expert look.

I'll try to look in more detail after Christmas.



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