> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
![]() |