oops bringing up secondary cpus

[Dave Hansen]

On Thu, 2004-07-15 at 16:20, Anton Blanchard wrote:
> Ahh sorry I forgot to tell you about a trick we use. In real mode the
> top 2 bits are ignored, so looking at the DAR you are trying to access
> 0x2fff3bf90.

Aha!  That really clears it up.

> Now one reason we would take a 300 on a real address is if you tried to
> touch memory outside the RMO region. Since the address is above 4GB Im
> guessing this is your problem.
>
> Since r1 is the same as the the DAR it sounds like its to do with
> current_set being outside the RMO:
>
>         LOADADDR(r3,current_set)
>         sldi    r28,r24,3               /* get current_set[cpu#] */
>         ldx     r1,r3,r28

OK, but current_set is the task info for the idle process for the new
CPU, right?  It looks to me like it's allocated like any old task using
copy_process() in smp_create_idle().  This should use kmalloc() like any
other task, and that's certainly not guaranteed to be in the RMO.  Did
this change recently?  Do we need to lmb_alloc() the idle task struct
for the secondary CPUs?

-- Dave


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/