[PATCH 08/10] ia64: Convert cpu_sibling_map to a per_cpu data array (v3)

2007-09-11 Thread travis
Convert cpu_sibling_map to a per_cpu cpumask_t array for the ia64 architecture. This fixes build errors in block/blktrace.c and kernel/sched.c when CONFIG_SCHED_SMT is defined. There was one access to cpu_sibling_map before the per_cpu data area was created, so that step was moved to after the p

[PATCH 09/10] ppc64: Convert cpu_sibling_map to a per_cpu data array (v3)

2007-09-11 Thread travis
Convert cpu_sibling_map to a per_cpu cpumask_t array for the ppc64 architecture. This fixes build errors in block/blktrace.c and kernel/sched.c when CONFIG_SCHED_SMT is defined. Note: these changes have not been built nor tested. Signed-off-by: Mike Travis <[EMAIL PROTECTED]> --- arch/powerpc/k

[PATCH 10/10] sparc64: Convert cpu_sibling_map to a per_cpu data array (v3)

2007-09-11 Thread travis
Convert cpu_sibling_map to a per_cpu cpumask_t array for the sparc64 architecture. This fixes build errors in block/blktrace.c and kernel/sched.c when CONFIG_SCHED_SMT is defined. Note: these changes have not been built nor tested. Signed-off-by: Mike Travis <[EMAIL PROTECTED]> --- arch/sparc64

[PATCH 07/10] x86: acpi-use-cpu_physical_id (v3)

2007-09-11 Thread travis
This is from an earlier message from Christoph Lameter: processor_core.c currently tries to determine the apicid by special casing for IA64 and x86. The desired information is readily available via cpu_physical_id() on IA64, i386 and x86_64. Signed-off-by: Christoph

[PATCH 05/10] x86: Convert x86_cpu_to_apicid to be a per cpu variable (v3)

2007-09-11 Thread travis
This patch converts the x86_cpu_to_apicid array to be a per cpu variable. This saves sizeof(apicid) * NR unused cpus. Access is mostly from startup and CPU HOTPLUG functions. MP_processor_info() is one of the functions that require access to the x86_cpu_to_apicid array before the per_cpu data are

[PATCH 06/10] x86: Convert cpu_llc_id to be a per cpu variable (v3)

2007-09-11 Thread travis
Convert cpu_llc_id from a static array sized by NR_CPUS to a per_cpu variable. This saves sizeof(cpu_llc_id) * NR unused cpus. Access is mostly from startup and CPU HOTPLUG functions. Note there's an addtional change of the type of cpu_llc_id from int to u8 for ARCH i386 to correspond with the s

[PATCH 02/10] x86: fix cpu_to_node references (v3)

2007-09-11 Thread travis
Fix four instances where cpu_to_node is referenced by array instead of via the cpu_to_node macro. This is preparation to moving it to the per_cpu data area. Signed-off-by: Mike Travis <[EMAIL PROTECTED]> --- arch/x86_64/kernel/vsyscall.c |2 +- arch/x86_64/mm/numa.c |4 ++-- arch

[PATCH 04/10] x86: Convert cpu_sibling_map to be a per cpu variable (v3)

2007-09-11 Thread travis
Convert cpu_sibling_map from a static array sized by NR_CPUS to a per_cpu variable. This saves sizeof(cpumask_t) * NR unused cpus. Access is mostly from startup and CPU HOTPLUG functions. Signed-off-by: Mike Travis <[EMAIL PROTECTED]> --- arch/i386/kernel/cpu/cpufreq/p4-clockmod.c |2 - ar

[PATCH 03/10] x86: Convert cpu_core_map to be a per cpu variable (v3)

2007-09-11 Thread travis
This is from an earlier message from 'Christoph Lameter': cpu_core_map is currently an array defined using NR_CPUS. This means that we overallocate since we will rarely really use maximum configured cpu. If we put the cpu_core_map into the per cpu area then it will be allocated fo

[PATCH 01/10] x86: remove x86_cpu_to_log_apicid array (v3)

2007-09-11 Thread travis
This is a copy of an older patch that is in rc3-mm1. It's needed to allow the remaining patches to integrate correctly. Signed-off-by: Mike Travis <[EMAIL PROTECTED]> --- arch/x86_64/kernel/genapic.c |2 -- arch/x86_64/kernel/genapic_flat.c |1 - arch/x86_64/kernel/smpboot.c |

[PATCH 00/10] x86: Reduce Memory Usage and Inter-Node message traffic (v3)

2007-09-11 Thread travis
Note: This patch consolidates all the previous patches regarding the conversion of static arrays sized by NR_CPUS into per_cpu data arrays and is referenced against 2.6.23-rc6 . v1 Intro: In x86_64 and i386 architectures most arrays that are sized using NR_CPUS lay in local memory on node 0.

SILO problem on a T1000

2007-09-11 Thread Iván Chavero
Hello, I have a problem with SILO. I've successfully installed gentoo 2007.0 on my T1000, i run silo and it does not return any error. But when i try to boot i get this error: boot disk Big Fat Output Sun Fire(TM) T1000, No Keyboard Copyright 2006 Sun Microsystems, Inc. All rig