Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

> > Just so you know, I have no intention of supporting this use case. In > fact, I'm planning to eventually stop using IST for #DB entirely, at > which point the kernel will crash terribly if this code is > single-stepped (except when using a hypervisor to do this single > stepping, which is a

Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

This lockless memory based synchronization in csd_lock_wait just doesn't work on all smp systems because not all of them properly implement these fancy memory fencing instructions. I've run into this before trying to do lockless queueing on a range of SMP systems. About the only thing guaranteed

Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

On 1/30/16, Andy Lutomirski wrote: > On Sat, Jan 30, 2016 at 9:53 AM, Jeff Merkey wrote: >> On 1/30/16, Andy Lutomirski wrote: >>> On Sat, Jan 30, 2016 at 12:41 AM, Jeff Merkey >>> wrote: Here is an MDB debugger trace of the code in question. please note that the flags being

Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

On Sat, Jan 30, 2016 at 9:53 AM, Jeff Merkey wrote: > On 1/30/16, Andy Lutomirski wrote: >> On Sat, Jan 30, 2016 at 12:41 AM, Jeff Merkey wrote: >>> Here is an MDB debugger trace of the code in question. please note >>> that the flags being compared don't match what's in r11 and the >>>

Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

On 1/30/16, Andy Lutomirski wrote: > On Sat, Jan 30, 2016 at 12:41 AM, Jeff Merkey wrote: >> Here is an MDB debugger trace of the code in question. please note >> that the flags being compared don't match what's in r11 and the >> comparison bits are wrong. >> >> (3)> >> >> Break at

Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

On Sat, Jan 30, 2016 at 12:41 AM, Jeff Merkey wrote: > Here is an MDB debugger trace of the code in question. please note > that the flags being compared don't match what's in r11 and the > comparison bits are wrong. > > (3)> > > Break at 0x81680022 due to - Proceed (single step) > RAX:

Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

Here is an MDB debugger trace of the code in question. please note that the flags being compared don't match what's in r11 and the comparison bits are wrong. (3)> Break at 0x81680022 due to - Proceed (single step) RAX: 0080 RBX: 0002 RCX: 7FC9877F2A30 RDX:

Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

On 1/25/16, Jeff Merkey wrote: > On 1/25/16, Jeff Merkey wrote: >> On 1/24/16, Jeff Merkey wrote: >>> On 1/24/16, Jeff Merkey wrote: If I single step with either kgdb, kgdb, or mdb kernel debuggers over a sysret instruction anywhere in the OS, the system hard hangs in

Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

Here is an MDB debugger trace of the code in question. please note that the flags being compared don't match what's in r11 and the comparison bits are wrong. (3)> Break at 0x81680022 due to - Proceed (single step) RAX: 0080 RBX: 0002 RCX: 7FC9877F2A30 RDX:

Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

On 1/25/16, Jeff Merkey wrote: > On 1/25/16, Jeff Merkey wrote: >> On 1/24/16, Jeff Merkey wrote: >>> On 1/24/16, Jeff Merkey wrote: If I single step with either kgdb, kgdb, or mdb kernel debuggers over

Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

On Sat, Jan 30, 2016 at 12:41 AM, Jeff Merkey wrote: > Here is an MDB debugger trace of the code in question. please note > that the flags being compared don't match what's in r11 and the > comparison bits are wrong. > > (3)> > > Break at 0x81680022 due to - Proceed

Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

This lockless memory based synchronization in csd_lock_wait just doesn't work on all smp systems because not all of them properly implement these fancy memory fencing instructions. I've run into this before trying to do lockless queueing on a range of SMP systems. About the only thing guaranteed

Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

On 1/30/16, Andy Lutomirski wrote: > On Sat, Jan 30, 2016 at 12:41 AM, Jeff Merkey wrote: >> Here is an MDB debugger trace of the code in question. please note >> that the flags being compared don't match what's in r11 and the >> comparison bits are

Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

On 1/30/16, Andy Lutomirski wrote: > On Sat, Jan 30, 2016 at 9:53 AM, Jeff Merkey wrote: >> On 1/30/16, Andy Lutomirski wrote: >>> On Sat, Jan 30, 2016 at 12:41 AM, Jeff Merkey >>> wrote: Here is an MDB

Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

> > Just so you know, I have no intention of supporting this use case. In > fact, I'm planning to eventually stop using IST for #DB entirely, at > which point the kernel will crash terribly if this code is > single-stepped (except when using a hypervisor to do this single > stepping, which is a

Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

On Sat, Jan 30, 2016 at 9:53 AM, Jeff Merkey wrote: > On 1/30/16, Andy Lutomirski wrote: >> On Sat, Jan 30, 2016 at 12:41 AM, Jeff Merkey wrote: >>> Here is an MDB debugger trace of the code in question. please note >>> that the

Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

On 1/25/16, Jeff Merkey wrote: > On 1/24/16, Jeff Merkey wrote: >> On 1/24/16, Jeff Merkey wrote: >>> If I single step with either kgdb, kgdb, or mdb kernel debuggers over >>> a sysret instruction anywhere in the OS, the system hard hangs in >>> smp_call_function_single after the debugger

Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

On 1/24/16, Jeff Merkey wrote: > On 1/24/16, Jeff Merkey wrote: >> If I single step with either kgdb, kgdb, or mdb kernel debuggers over >> a sysret instruction anywhere in the OS, the system hard hangs in >> smp_call_function_single after the debugger releases the system and it >> resumes

Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

On 1/25/16, Jeff Merkey wrote: > On 1/24/16, Jeff Merkey wrote: >> On 1/24/16, Jeff Merkey wrote: >>> If I single step with either kgdb, kgdb, or mdb kernel debuggers over >>> a sysret instruction anywhere in the OS, the system

Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

On 1/24/16, Jeff Merkey wrote: > On 1/24/16, Jeff Merkey wrote: >> If I single step with either kgdb, kgdb, or mdb kernel debuggers over >> a sysret instruction anywhere in the OS, the system hard hangs in >> smp_call_function_single after the debugger

Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

On 1/24/16, Jeff Merkey wrote: > If I single step with either kgdb, kgdb, or mdb kernel debuggers over > a sysret instruction anywhere in the OS, the system hard hangs in > smp_call_function_single after the debugger releases the system and it > resumes normal operation.The specific place

[BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

If I single step with either kgdb, kgdb, or mdb kernel debuggers over a sysret instruction anywhere in the OS, the system hard hangs in smp_call_function_single after the debugger releases the system and it resumes normal operation.The specific place the kernel hangs is in the loop below.

Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

On 1/24/16, Jeff Merkey wrote: > If I single step with either kgdb, kgdb, or mdb kernel debuggers over > a sysret instruction anywhere in the OS, the system hard hangs in > smp_call_function_single after the debugger releases the system and it > resumes normal operation.

[BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

If I single step with either kgdb, kgdb, or mdb kernel debuggers over a sysret instruction anywhere in the OS, the system hard hangs in smp_call_function_single after the debugger releases the system and it resumes normal operation.The specific place the kernel hangs is in the loop below.