|
|
|
Re: [PATCH RFC 0/5] hard_smp_processor_id overhaul | |
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] | |
On Thu, Mar 01, 2007 at 04:16:13PM +0900, Fernando Luis Vázquez Cao wrote: > With the advent of kdump, the assumption that the boot CPU when running > an UP kernel is always the CPU with a hardware ID of 0 (usually referred > to as BSP on some architectures) does not hold true anymore. The reason > being that the dump capture kernel boots on the crashed CPU (the CPU > that invoked crash_kexec). > > As a consequence, the hardcoding of hard_smp_processor_id() to 0 on UP > systems (see "linux/smp.h") is not correct. > > This patch-set does the following: > > 1- Remove hardcoding of hard_smp_processor_id on UP systems. > > 2- Ask the hardware when possible to obtain the hardware processor id on > i386, x86_64, and ia64, independently of whether CONFIG_SMP is set or > not. > > 3- Move definition of hard_smp_processor_id for the UP case to asm/smp.h > on alpha, m32r, powerpc, s390, sparc, sparc64, and um architectures. I > guess that hardware features could be used to implement > hard_smp_processor_id even in the UP case, but since I am not an expert > in this architectures I just move the definition. > > The patches have been tested on i386, x86_64, and ia64. Hi Fernando, These patches seem find to me. Tested on ia64 (Tiger2) Acked: Simon Horman <horms@xxxxxxxxxxxx> _______________________________________________ fastboot mailing list fastboot@xxxxxxxxxxxxxx https://lists.osdl.org/mailman/listinfo/fastboot
[Netdev] [Linux Wireless] [Kernel Newbies] [Security] [Linux for Hams] [Netfilter] [Bugtraq] [Photo] [Yosemite] [Yosemite Forum] [MIPS Linux] [ARM Linux] [Linux RAID] [Linux Admin] [Samba] [Linux Media] [Linux Resources]