[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-smp
Subject:    Kernel SMP Init Questions
From:       "Sol Kavy" <skavy () ubicom ! com>
Date:       2009-02-23 2:35:13
Message-ID: CB2DD11991B27C4F99935E6229450D3204017242 () STORK ! scenix ! com
[Download RAW message or body]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]