[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



On Mon, May 18, 2009 at 05:11:41PM +0200, Andreas U. Trottmann wrote:
> 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.

A fix has been committed. It would be helpful if you could test a
lenny snaphot build and confirm the fix. Information on installing
snapshots is available here:

  http://wiki.debian.org/DebianKernel

The version you will want to test will be >= 2.6.26-16~snapshot.13633
and should be available after the next daily build cycle.

> 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,
> 

-- 
dann frazier




Reply to: