I haven't completely unraveled this yet, but I'm pretty sure that one reason my second Xeon chip won't start is due to a nested spin_lock within the 2nd chip's execution path.
Since my board is similar to the Tyan s2735 I use the same setting, CONFIG_MAX_CPUS = 4. If I am tracing the code correctly, I believe that results in the following sequence of calls to bring up the CPUs. The "CPU #x" header shows which logical CPU executes each set of calls.
CPU #0 (APIC ID 0, Xeon Chip 0, Logical processor 0): northbridge.c: cpu_bus_init lapic_cpu_init.c: initialize_cpus cpu.c: cpu_initialize model_f2x_init.c: model_f2x_init intel_sibling.c: intel_sibling_init lapic_cpu_init.c: start_cpu (APIC ID 1) spin_lock(&start_cpu_lock) lapic_cpu_init.c: lapic_start_cpu spin_unlock(&start_cpu_lock) lapic_cpu_init.c: initialize_other_cpus lapic_cpu_init.c: start_cpu(APIC ID 6) spin_lock(&start_cpu_lock) lapic_cpu_init.c: lapic_start_cpu spin_unlock(&start_cpu_lock)
CPU #1 (APIC ID 1, Xeon Chip 0, Logical processor 1): lapic_cpu_init.c: secondary_cpu_init spin_lock(&start_cpu_lock) cpu.c: cpu_initialize model_f2x_init.c: model_f2x_init intel_sibling.c: intel_sibling_init (no-op) spin_unlock(&start_cpu_lock) lapic.h: stop_this_cpu
CPU #2 (APIC ID 6, Xeon Chip 1, Logical processor 0): lapic_cpu_init.c: secondary_cpu_init spin_lock(&start_cpu_lock) cpu.c: cpu_initialize model_f2x_init.c: model_f2x_init intel_sibling.c: intel_sibling_init lapic_cpu_init.c: start_cpu (APIC ID 7) spin_lock(&start_cpu_lock) lapic_cpu_init.c: lapic_start_cpu spin_unlock(&start_cpu_lock) spin_unlock(&start_cpu_lock) lapic.h: stop_this_cpu
CPU #3 (APIC ID 7, Xeon Chip 1, Logical processor 1): lapic_cpu_init.c: secondary_cpu_init spin_lock(&start_cpu_lock) cpu.c: cpu_initialize model_f2x_init.c: model_f2x_init intel_sibling.c: intel_sibling_init (no-op) spin_unlock(&start_cpu_lock) lapic.h: stop_this_cpu
It sure looks to me like the CPU #2 call sequence tries to grab the start_cpu_lock twice.
Steve