[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#529312: linux-image-2.6.26-2-686-bigmem: Does not recognize all CPUs on "summit" SMP machines



Package: linux-image-2.6.26-2-686-bigmem
Version: 2.6.26-15

Hello,

The Linux kernel sources upon which
linux-image-2.6.26-2-686-bigmem is based are suffering from a
bug, which only affects the (relatively rare) "summit" SMP
architecture. It is found in IBM xSeries servers such as the 
x440 or x445.

On these servers, linux-image-2.6.26-2-686-bigmem only correctly
identifies and uses one CPU, regardless of the number of CPUs 
actually installed.

The bug is documented and resolved on linux-kernel:

http://lkml.indiana.edu/hypermail/linux/kernel/0807.3/0493.html

The patch responsible for the resolution is the following:

--- a/include/asm-x86/mach-summit/mach_apic.h 2008-07-24 18:06:39.000000000 -0700
+++ b/include/asm-x86/mach-summit/mach_apic.h 2008-07-24 18:09:29.000000000 -0700
@@ -122,7 +122,7 @@ static inline physid_mask_t ioapic_phys_

 static inline physid_mask_t apicid_to_cpu_present(int apicid)
 {
- return physid_mask_of_physid(0);
+ return physid_mask_of_physid(apicid);
 }


I report the bug against a lenny kernel, as I don't have any such system running 
testing or unstable. The current linux kernel source in unstable, linux-2.6_2.6.29-5,
appears to have the file structure reorganized. The relevant file appears to be
arch/x86/include/asm/summit/apic.h, and the bug appears still to be present: 
apicid_to_cpu_present still returns physid_mask_of_physid(0) instead of (apicid).

However, currently I cannot test whether the fix is still relevant.

If it is of help, I could try to boot an unpatched linux-2.6_2.6.29-5 kernel on a 
summit machine and compare the number of identified CPUs with a patched linux-2.6_2.6.29-5
kernel.

In any case, it could probably be a good idea to include the fix in the next lenny 
kernel update, as it does render those multi-CPU machines relatively useless, and
the fix does not affect anyone else.



With kind regards,

-- 
Andreas Trottmann



Reply to: