> -----Original Message----- > From: Sergei Shtylyov [mailto:[EMAIL PROTECTED] > Sent: Saturday, June 09, 2007 2:34 PM > To: Wessel, Jason > Cc: [email protected]; [EMAIL PROTECTED] > Subject: Re: KGDB/RT integration woes > > 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...
Is this during the boot cycle or attaching afterwards? The tasklet at runtime should only be used to break in initially. It sounds like the problem might be else where though. The tasklet should run on a single CPU and that CPU will have an exception to put KGDB into the exception context where it should try to obtain control of all the other processors via an IPI. Perhaps the RT code you have patched the kernel with has not changed the lock semantics in the kernel/kgdb.c to lock down all the processors? Jason. ------------------------------------------------------------------------- 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
