Hello, I wrote:
>>>> I'm also getting this with RT patch applied on x86_64 SMP machine
>>>> (with low-latency desktop kernel) after hitting initial breakpoint:
>>>> BUG: at kernel/softirq.c:647 __tasklet_action()
>>>> Call Trace:
>>>> [<ffffffff8022e61a>] __tasklet_action+0xe7/0x138
>>>> [<ffffffff8022e693>] tasklet_action+0x28/0x2a
>>>> [<ffffffff8022e892>] ksoftirqd+0x149/0x1f3
>>>> [<ffffffff8022e749>] ksoftirqd+0x0/0x1f3
>>>> [<ffffffff8023d324>] kthread+0xdc/0x113
>>>> [<ffffffff8020adf8>] child_rip+0xa/0x12
>>>> [<ffffffff8023d44f>] kthread_create+0x6a/0x15c
>>>> [<ffffffff8023d248>] kthread+0x0/0x113
>>>> [<ffffffff8020adee>] child_rip+0x0/0x12
>>>> ---------------------------
>>>> | preempt count: 00000100 ]
>>>> | 0-level deep critical section nesting:
>>>> ----------------------------------------
> Ugh, this one was really nasty. The actual reason has turned to be
> that the KGDB's tasklet gets scheduled *before* per-CPU data gets
> replicated for each CPU, therefore it modifies the .data.percpu section
> itself. But the tasklet is actually run *after* the replication, so it
> gets into the tasklet lists on every CPU -- and so I get that BUG on
> every CPU! Any thoughts on how to avoid this nuisance? :-/
Looks like a design issue to me: KGDB (ab)uses tasklets before per-CPU
data gets replicated. This only happens on x86_64 SMP machines because those
don't have exception stack setup by the time initial breakpoint is hit. What
I don't understand yet is why these BUGs don't show up without the -rt patch...
WBR, Sergei
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Kgdb-bugreport mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
