On Fri, 2007-03-02 at 09:44 +0530, Vivek Goyal wrote:
> On Thu, Mar 01, 2007 at 09:06:48AM -0500, Benjamin LaHaise wrote:
> > On Thu, Mar 01, 2007 at 04:16:13PM +0900, Fernando Luis Vázquez Cao wrote:
> > > As a consequence, the hardcoding of hard_smp_processor_id() to 0 on UP
> > > systems (see
On Fri, 2007-03-02 at 09:44 +0530, Vivek Goyal wrote:
On Thu, Mar 01, 2007 at 09:06:48AM -0500, Benjamin LaHaise wrote:
On Thu, Mar 01, 2007 at 04:16:13PM +0900, Fernando Luis Vázquez Cao wrote:
As a consequence, the hardcoding of hard_smp_processor_id() to 0 on UP
systems (see
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
On Thu, Mar 01, 2007 at 09:06:48AM -0500, Benjamin LaHaise wrote:
> On Thu, Mar 01, 2007 at 04:16:13PM +0900, Fernando Luis Vázquez Cao wrote:
> > 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
On Thu, Mar 01, 2007 at 09:06:48AM -0500, Benjamin LaHaise wrote:
On Thu, Mar 01, 2007 at 04:16:13PM +0900, Fernando Luis Vázquez Cao wrote:
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:
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
6 matches
Mail list logo
