Messages in this thread | | | Date | Sat, 08 Nov 1997 23:56:19 +0100 | From | Andre Derrick Balsa <> | Subject | Re: Pentium DEATH in user-mode |
| |
Hi Erik,
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 ========================================================
| |