Sorry I've generated some unnecesary confusion re: my comments about the use of DEFINE_PER_CPU and DECLARE_PER_CPU. That's what I get for trying to multi-task... Stepping back, the init_tss array is defined in "arch/x86_64/kernel/init_task.c". In 2.6.9, it's declared like so: /* * per-CPU TSS segments. Threads are completely 'soft' on Linux, * no more per-task TSS's. The TSS size is kept cacheline-aligned * so they are allowed to end up in the .data.cacheline_aligned * section. Since TSS's are completely CPU-local, we want them * on exact cacheline boundaries, to eliminate cacheline ping-pong. */ DEFINE_PER_CPU(struct tss_struct, init_tss) ____cacheline_maxaligned_in_smp; In 2.6.13, it's slightly different in that it is initialized to INIT_TSS: /* * per-CPU TSS segments. Threads are completely 'soft' on Linux, * no more per-task TSS's. The TSS size is kept cacheline-aligned * so they are allowed to end up in the .data.cacheline_aligned * section. Since TSS's are completely CPU-local, we want them * on exact cacheline boundaries, to eliminate cacheline ping-pong. */ DEFINE_PER_CPU(struct tss_struct, init_tss) ____cacheline_maxaligned_in_smp = INIT_TSS; Both kernels have the same DECLARE_PER_CPU in the "x86_64/processor.h" header file: DECLARE_PER_CPU(struct tss_struct,init_tss); That being the case, and not seeing why the INIT_TSS initialization should have anything to do with the problem at hand, I am officially stumped at why the 2.6.14 kernel shows the problem with your patch. Dave
