Linux Version: 2.6.28 Processor: Ubicom32 (new arch directory not yet submitted) Compiled: CONFIG_SMP (enabled), CONFIG_MMU (disabled) Can anyone explain where the per-cpu runqueues are supposed to be initialized? Our SMP bring-up is dying in __enqueue_rt_entity() because queue->prev is NULL. The list_add_tail() call at sched_rt.c:653 will dereference queue->prev which in my case is NULL. In fact, queue->next is also NULL. list_add_tail(&rt_se->run_list, queue); Porting Status: We have Linux running with a single mainline Linux thread. We have Linux running with Linux compiled for SMP but only running with one bit set in the cpu_possible_map. I am now trying to turn on a 2nd thread (cpu). The 2nd thread is launched and enters cpu_idle(). The first thread is completing the cpu_up() for this new secondary thread. The notification chains calls migration_call() which looks like it is trying to schedule a new task on the secondary thread; however, I fear that I have failed to initialize the run queues properly. I have checked the parisc/powerpc/x86 ports to see how they init things but I don't see anything besides the call to fork_idle(). I traced through fork_idle() but I don't see anywhere that it is initializing the per_cpu run queues. Nothing in the Documentation directory talks about this (that I can see). Not sure if this is related: We have our own per_cpu_setup_area() call. It is identical to the one in main.c; however, the one in main.c was called before smp_prepare_cpus() was called. This meant that I had not initialized cpu_possible_map. So I set the CONFIG_HAVE_SETUP_PER_CPU_AREA and do the copy of the per_cpu area as at the end of smp_prepare_cpus() function. My other alternative was to move the setting of the cpu_possible_map all the way to smp_setup_processor_id() but that did not seem appropriate to me. Is there a better way to handle this sequencing? Information about Ubicom32 Processors: Ubicom32 is a 32 bit micro-processor. The instruction set is designed to make memory-to-memory moves extremely efficient. The processor has <n> threads each of which has full access to the same address space. The pipeline is able to "choose" the next instruction to execute from any of the threads. Ultimately, we will be able to run Linux on any number of these threads (cpu(s) in Linux terms). The current processors do not have an MMU so we are running Linux configured with CONFIG_MMU (not set) and CONFIG_SMP (set). Stack Back Trace: #0 0x40413924 in __enqueue_rt_entity (rt_se=0x40edd0c0) at include/linux/list.h:48 #1 0x404144d4 in enqueue_rt_entity (rt_se=0x40edd0c0) at kernel/sched_rt.c:694 #2 0x404145b4 in enqueue_task_rt (rq=0x40ee76a8, p=0x40edd040, wakeup=1) at kernel/sched_rt.c:719 #3 0x404173e4 in enqueue_task (rq=0x40ee76a8, p=0x40edd040, wakeup=1) at kernel/sched.c:1678 #4 0x4041766c in activate_task (rq=0x40ee76a8, p=0x40edd040, wakeup=1) at kernel/sched.c:1749 #5 0x40418ba0 in try_to_wake_up (p=0x40edd040, state=15, sync=0) at kernel/sched.c:2315 #6 0x40418cc0 in wake_up_process (p=0x40edd040) at kernel/sched.c:2337 #7 0x409db7d4 in migration_call (nfb=0x409e0558, action=2, hcpu=0x2) at kernel/sched.c:6533 #8 0x40469e94 in notifier_call_chain (nl=0x409e0564, val=2, v=0x2, nr_to_call=-1, nr_calls=0x0) at kernel/notifier.c:85 #9 0x4046a2ec in __raw_notifier_call_chain (nh=0x409e0564, val=2, v=0x2, nr_to_call=-1, nr_calls=0x0) at kernel/notifier.c:383 #10 0x4046a324 in raw_notifier_call_chain (nh=0x409e0564, val=2, v=0x2) at kernel/notifier.c:390 #11 0x409dbca0 in _cpu_up (cpu=2, tasks_frozen=0) at kernel/cpu.c:356 #12 0x409dbdb8 in cpu_up (cpu=2) at kernel/cpu.c:387 #13 0x409b0788 in smp_init () at init/main.c:430 #14 0x40009b90 in ?? () -- To unsubscribe from this list: send the line "unsubscribe linux-smp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
