Andrew Morton wrote:
> Brian Gerst wrote:
> 
>>These patches convert some of the existing arrays based on NR_CPUS to
>>use the new per cpu code.
>>
> 
> 
> Brian, I tested this patch (rediffed against 2.5.13, below)
> on the quad Xeon and it failed.
> 
> The machine died when bringing up the secondary CPUs
> ("CPU#3 already started!" and "Unable to handle kernel...")
> 
> I backed out the sched.c part and the machine booted.  So
> I guess the secondary CPU bringup code uses the scheduler
> somehow.
> 
> And again, the numbers in /proc/meminfo are whacko:
> 
> LowFree:         94724 kB
> SwapTotal:     4000040 kB
> SwapFree:      3999700 kB
> Dirty:            7232 kB
> Writeback:    4294967264 kB
> 
> Which never happens with the open-coded per-cpu accumulators.
> After a normal boot I see:
> 
> LowFree:         95804 kB
> SwapTotal:     4000040 kB
> SwapFree:      3999940 kB
> Dirty:            1356 kB
> Writeback:           0 kB
> 
> 
> Now, it may be that some pages are being marked dirty before
> the per-cpu areas are set up, but there's no way in which
> any pages will have been marked for writeback by that time, so
> that "-32" value is definitely wrong.
> 
> 'fraid I have to do a whine-and-run on this problem, but
> it does still appear that there is something fishy with
> the percpu infrastructure.
>

Andrew, could you try this patch?  I suspect something in setup_arch() 
is touching the per cpu area before it gets copied for the other cpus. 
This patch makes certain the boot cpu area is setup ASAP.
-- 

						Brian Gerst