lkml.org 
[lkml]   [2014]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: frequent lockups in 3.18rc4
    From
    On Fri, Nov 14, 2014 at 2:55 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
    >
    > This stale entry is not relevant here because the thing is stuck in
    > generic_exec_single().

    That wasn't really my argument. The fact that "do_flush_tlb_all()" was
    left over on the stack frame implies that we're not doing the
    range-flush, and if it was some odd bug with a negative range or
    something like that (due to the fix in commit ce9ec37bddb6), I'd
    expect the lockup to be due to a hung do_kernel_range_flush() or
    something. But the range flushing never even happens.

    > So from smp_call_function_many() we end up via
    > smp_call_function_single() in generic_exec_single().
    >
    > So the only ways to get stuck there are:
    >
    > csd_lock(csd);
    > and
    > csd_lock_wait(csd);

    Judging by the code disassembly, it's the "csd_lock_wait(csd)" at the
    end. The disassembly looks like

    29: f3 90 pause
    2b:* f6 43 18 01 testb $0x1,0x18(%rbx) <-- trapping instruction
    2f: 75 f8 jne 0x29
    31: 31 c0 xor %eax,%eax

    and that "xor %eax,%eax" seems to be part of the "return 0"
    immediately afterwards.

    But that's not entirely conclusive, it's just a strong hint.

    It does sound like there might be some IPI issue. I just don't see
    *any* changes in this area since 3.17. Some unrelated APIC change? I
    don't see that either. As you noted, there are KVM changes, but
    apparently that isn't involved either.

    Linus


    \
     
     \ /
      Last update: 2014-11-15 03:41    [W:4.178 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site