[lkml]   [1997]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Pentium DEATH in user-mode
    Hi Erik,

    Erik wrote:

    > In article <> you wrote:
    > > Doesn't stop Cyrix 166 MMX's
    > There seems to be a different sequence that affects Cyrixes though.
    > See <>. 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

    I don't understand German, so that made it a little harder to check this

    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};
    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

    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.


    Andrew D. Balsa
    Home Page:

     \ /
      Last update: 2005-03-22 13:40    [W:0.021 / U:2.276 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site