Erik wrote:
> In article <199711080849.VAA02265@karaka.chch.cri.nz> you wrote:
> > Doesn't stop Cyrix 166 MMX's
>
> There seems to be a different sequence that affects Cyrixes though.
>
> See <http://www.heise.de/ct/art_ab97/9713030/>. If you don't
> understand German you will probably want to skip down to the
> assembler code at the bottom of the article.
>
> I don't have a Cyrix, so I can't test it, but it seems to me
> that the 'sti' must be unnecessary and impossible on Linux in
> user mode. Apparently the effect of the loop is to stop the
> handling of interrupts.
>
> - --
> Erik Corry erik@arbat.com
I don't understand German, so that made it a little harder to check this
information.
Here are the *bad* news:
========================
You *can* deadlock a 6x86 in user mode with the sequence or a small
variations on the sequence proposed in the article.
Here is the source of a small user-space program that will lock your
Cyrix in a loop:
static unsigned char c[4] = {0x36, 0x78, 0x38, 0x36};
main()
{
asm ("movl $c, %ebx\n\t"
"again: xchgl (%ebx), %eax\n\t"
"movl %eax, %edx\n\t"
"jmp again\n\t");
}
I am sorry if it's not as elegant as Richard Johnson's example.
Compiling and running as a simple user the above program will lock my
6x86L box. I didn't try it on the 6x86MX (I will report later on the
6x86MX).
Explanation (my guess, I may be completely wrong):
==================================================
The exchange instruction (xchgl above) on the 6x86 will lock the cpu bus
and effectively disable interrupts during its execution. It seems that
the combination of speculative execution and register renaming plus the
intelligent pipelines in the 6x86 will prevent interrupt servicing
during the execution of the movl and jmp instructions. Consequently
interrupts never get serviced and the processor is effectively locked in
a loop that runs in its cache line.
And here are the good news:
===========================
Setting the NO_LOCK bit in CCR1 will prevent the deadlock caused by the
above code sequence. Here is a short call to set6x86 that does this:
set6x86 -p 0xc1 -s 0x10.
Page table accesses and interrupt acknowledge cycles will still be
executed in locked cycles, but the xchgl instruction will *not* generate
locked cycles anymore.
I don't know if setting the NO_LOCK bit will cause problems when running
Linux. I don't think so...
Comments are welcome.
Cheers,
========================================================
Andrew D. Balsa
Home Page: http://www.tux.org/~balsa
andrewbalsa@usa.net
========================================================