>
> 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 mu
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 t
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 compared
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
>>> compari
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 0x816
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: 0
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: 000
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
smp_call_f
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 relea
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 norma
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 the
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. Th
12 matches
Mail list logo
