> Is panic the only choice here? It seems unfriendly to panic
> just because we can't successfully add a new CPU. It'd be
> nicer to somehow make the addition fail so the new CPU is
> just not usable.
The current code sequence is:
start_secondary -> cpu_init -> ia64_mca_cpu_init
and the memory allocation here happens very late in the
sequence ... so it it fails we'd have to do a lot of work
to back out. Moving the ia64_mca_cpu_init() much earlier
would help some ... but we don't currently have a graceful
failure path if anything goes wrong. The new cpu has
already been passed from SAL control to OS control ... so
we'd have to pass it back again.
There are probably a whole host of potential failures in
this code path that ought to be checked but currently
aren't because all these routines were written to be
called once at boot time when memory allocations hardly
ever fail (and it they do, panic is perhaps the best
answer).
The liklihood of this particular allocation failing goes
up as the configured pagesize is reduced. With the
default 64k, the allocation is order=1 ... but with a
4k page we need an order=4 allocation to succeed.
-Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
