On Tue, 22 Jan 2008, Mel Gorman wrote: > Christoph/Pekka, this patch is papering over the problem and something > more fundamental may be going wrong. The crash occurs because l3 is NULL > and the cache is kmem_cache so this is early in the boot process. It is > selecting l3 based on node 2 which is correct in terms of available memory > but it initialises the lists on node 0 because that is the node the CPUs are > located. Hence later it uses an uninitialised nodelists and BLAM. Relevant > parts of the log for seeing the memoryless nodes in relation to CPUs is;
Would it be possible to run the bootstrap on a cpu that has a node with memory associated to it? I believe we had the same situation last year when GFP_THISNODE was introduced? After you reverted the slab memoryless node patch there should be per node structures created for node 0 unless the node is marked offline. Is it? If so then you are booting a cpu that is associated with an offline node. > Can you see a better solution than this? Well this means that bootstrap will work by introducing foreign objects into the per cpu queue (should only hold per cpu objects). They will later be consumed and then the queues will contain the right objects so the effect of the patch is minimal. I thought we fixed the similar situation last year by dropping GFP_THISNODE for some allocations? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
