On 06/05/2015 09:10, Ralf Baechle wrote:
> On Mon, Jun 01, 2015 at 05:09:34PM -0700, Leonid Yegoshin wrote:
>
> Leonid,
>
> to me the biggest technical problem with this patch is that the new Kconfig
> option is user visible. This is the kind of deeply technical options
> which exceeds the technical knowledge of most users, so it should probably
> be driven by a select.
>
> We probably also want to enquire how old CPUs from before the invention
> of the stype field are behaving. If those as I hope for all treat an
> stype != 0 as stype 0 we could simply drop the option. But we might
> simply be out of luck - dunno.
>
> Maciej,
>
> do you have an R4000 / R4600 / R5000 / R7000 / SiByte system at hand to
> test this? I think we don't need to test that SYNC actually works as
> intended but the simpler test that SYNC <stype != 0> is not causing a
> illegal instruction exception is sufficient, that is if something like
>
> int main(int argc, charg *argv[])
> {
> asm(" .set mips2 \n"
> " sync 0x10 \n"
> " sync 0x13 \n"
> " sync 0x04 \n"
> " .set mips 0 \n");
>
> return 0;
> }
>
> doesn't crash we should be ok.
>
> The kernel's SYNC emulation should already be ok. We ignore the stype
> field entirely and for a uniprocessor R2000/R3000 that should be just
> the right thing.
>
> Ralf
I tried just compiling this on my SGI O2, which has an RM7000 CPU, and it is
refusing to even compile (after fixing typos):
# gcc -O2 -pipe sync_test.c -o sync_test
{standard input}: Assembler messages:
{standard input}:19: Error: invalid operands `sync 0x10'
{standard input}:20: Error: invalid operands `sync 0x13'
{standard input}:21: Error: invalid operands `sync 0x04'
So a bit of searching landed me here:
http://stackoverflow.com/questions/3599564/gnu-assembler-for-mips-how-to-emit-sync-instructions
And I recoded the sync insns like this:
int main(int argc, char *argv[])
{
__asm__ volatile ( \
" .set mips2 \n"
" .word (0x0000000f | (0x10 << 6)) \n"
" .word (0x0000000f | (0x14 << 6)) \n"
" .word (0x0000000f | (0x04 << 6)) \n"
" .set mips0 \n"
);
return 0;
}
And the program compiles successfully and executes with no noticeable oddities
or errors. Nothing in dmesg, no crashes, booms, or disappearance of small
kittens. I did a quick disassembly to make sure all three got emitted:
004005e0 <main>:
4005e0: 27bdfff8 addiu sp,sp,-8
4005e4: afbe0004 sw s8,4(sp)
4005e8: 03a0f021 move s8,sp
4005ec: afc40008 sw a0,8(s8)
4005f0: afc5000c sw a1,12(s8)
> 4005f4: 0000040f sync.p
> 4005f8: 0000050f 0x50f
> 4005fc: 0000010f 0x10f
400600: 00001021 move v0,zero
Same effect on my Octane (IP30) w/ an R14000 CPU. Tested inside a uclibc-based
chroot, but no change. Executes successfully silently.
--
Joshua Kinard
Gentoo/MIPS
kumba@xxxxxxxxxx
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
"The past tempts us, the present confuses us, the future frightens us. And our
lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
