Kevin,
Outstanding, sometimes it's better to be lucky than good.
Anoop,
Maybe we can get lucky again.
If you can isolate the .33 works/.37 works_not bug to a specific pair of
versions,
I'll be happy to do another diff.
Hope you'll have had a good Christmas as well.
We've had snow in Alabama since Christmas eve!
Regards,
Stuart
-----Original Message-----
From: Kevin D. Kissell [mailto:kevink@paralogos.com]
Sent: Friday, December 24, 2010 5:34 PM
To: Anoop P A
Cc: STUART VENTERS; Anoop P.A.; linux-mips@linux-mips.org
Subject: Re: SMTC support status in latest git head.
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!
Regards,
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 2.6.37.11) 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
> b/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)
>
>
>> /K.
>>
>> On 12/24/10 6:39 AM, Anoop P A wrote:
>>> Hi Kevin, Stuart ,
>>>
>>> Woohooo You guys spotted !.
>>>
>>> http://git.linux-mips.org/?p=linux.git;a=commit;h=d5ec6e3c seems to be
>>> the culprit
>>>
>>> Once I restored previous version of stackframe.h 2.6.33-stable started
>>> booting !.
>>>
>>> Thanks,
>>> Anoop
>>>
>>> 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.
>>>>
>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>
|