Re: Lockup with "BUG: using smp_processor_id() in preemptible"

[Bryan Donlan <bdonlan@gmail.com>]

On Thu, Dec 31, 2009 at 12:16 PM, Leyendecker, Robert
<Robert.Leyendecker@lsi.com> wrote:

> Yes - from looking at trace and smp code it seems to occur during migration, however, there is a fair amount of asm woven in to this part and I have trouble following it and have no idea about root cause. With smp support I eventually hit this trap using brute force polling, epoll or async signals, regardless of application level affinity, irq priority, etc. Time to fault seems to very between a few minutes to several hours.
>
> I have encountered this exception using core duo with a network application. It does not occur on single core machines (I am also testing with SMP disabled and it also seems to resolve the issue). It seems very reproducible on my core duo, both 32 and 64 bit and using the latest stable kernel and rt patch.
>
> My app hammers the network interface with packets. I'm planning to boil it down into a couple of peer to peer test routines so that network processing latency can be accurately measured under rt patch for streaming applications. Rt patch seems to give excellent results that I cannot achieve using non-patch kernel (even with hand tuned affinity, IRQs, priorities, etc), so I'm hoping we can figure it out and fix it.
>
> For now, I plan to set everyone up with smp disabled in our test lab. Things seem stable with this setting.

Okay, good to know it's a known issue. I've captured a function_graph
trace, if it will help, of the flow leading up to the printk in
debug_smp_processor_id(): http://fushizen.net/~bd/trace.1.gz (occurs
on CPU 1 at the end of the trace; the printk is clearly visible)

The patch used to generate it is at
http://fushizen.net/~bd/smp-procid-trace-trap.patch