I think I've seen some recent talk about this problem. I have an HPAQ
xw6000 w/ 2xP4 CPUs. A RH kernel finds both CPUs (4 if I enable HT). A
kernel.org kernel only finds 1 (2 if I enable HT). I've been playing with
this thing for awhile now, and I am at a loss.
I set DEBUG_APIC=1 and captured the attached dmesg's. The configs are
identical as far as APIC and SMP goes. Also, ACPI is not set, and I
am using CONFIG_M686.
Any clues?
thanks
/fc
On Thu, Sep 04, 2003 at 02:11:13AM -0700, Frank Cusack wrote:
> I think I've seen some recent talk about this problem. I have an HPAQ
> xw6000 w/ 2xP4 CPUs. A RH kernel finds both CPUs (4 if I enable HT). A
> kernel.org kernel only finds 1 (2 if I enable HT).
Works with 2.4.22. If anyone is interested, I'll followup with the exact
change from 2.4.21 that makes this work (I need to figure that out anyway).
It's NOT the recent apic.c changes (local APIC), at least not by itself.
/fc
On Thu, Sep 04, 2003 at 09:14:37AM -0700, Frank Cusack wrote:
> On Thu, Sep 04, 2003 at 02:11:13AM -0700, Frank Cusack wrote:
> > I think I've seen some recent talk about this problem. I have an HPAQ
> > xw6000 w/ 2xP4 CPUs. A RH kernel finds both CPUs (4 if I enable HT). A
> > kernel.org kernel only finds 1 (2 if I enable HT).
This turned out to be a CPU numbering issue. The HPAQ machine numbers
the cpus #0 and #6. I had NR_CPUS set to 2. That only works if the CPUs
are physically numbered 0 and 1.
So NR_CPUS is a little misleading. I could suggest a Config.help change
if you like.
/fc
On 09.29, Frank Cusack wrote:
> On Thu, Sep 04, 2003 at 09:14:37AM -0700, Frank Cusack wrote:
> > On Thu, Sep 04, 2003 at 02:11:13AM -0700, Frank Cusack wrote:
> > > I think I've seen some recent talk about this problem. I have an HPAQ
> > > xw6000 w/ 2xP4 CPUs. A RH kernel finds both CPUs (4 if I enable HT). A
> > > kernel.org kernel only finds 1 (2 if I enable HT).
>
> This turned out to be a CPU numbering issue. The HPAQ machine numbers
> the cpus #0 and #6. I had NR_CPUS set to 2. That only works if the CPUs
> are physically numbered 0 and 1.
>
> So NR_CPUS is a little misleading. I could suggest a Config.help change
> if you like.
>
This is a little weird. This forces you to have all the SMP structures sized
8 just to use 2 members.
Was not there a physical-logical map ? Or that was in -aa kernel and 2.6 ?
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandrake Linux release 9.2 (Cooker) for i586
Linux 2.4.23-pre5-jam1 (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk))
J.A. Magallon writes:
>
> On 09.29, Frank Cusack wrote:
> > On Thu, Sep 04, 2003 at 09:14:37AM -0700, Frank Cusack wrote:
> > > On Thu, Sep 04, 2003 at 02:11:13AM -0700, Frank Cusack wrote:
> > > > I think I've seen some recent talk about this problem. I have an HPAQ
> > > > xw6000 w/ 2xP4 CPUs. A RH kernel finds both CPUs (4 if I enable HT). A
> > > > kernel.org kernel only finds 1 (2 if I enable HT).
> >
> > This turned out to be a CPU numbering issue. The HPAQ machine numbers
> > the cpus #0 and #6. I had NR_CPUS set to 2. That only works if the CPUs
> > are physically numbered 0 and 1.
> >
> > So NR_CPUS is a little misleading. I could suggest a Config.help change
> > if you like.
> >
>
> This is a little weird. This forces you to have all the SMP structures sized
> 8 just to use 2 members.
>
> Was not there a physical-logical map ? Or that was in -aa kernel and 2.6 ?
Problem #1 is that physical CPU numbering isn't dense. This is not a bug.
Problem #2 is that the kernel's internal dense-logical-to-sparse-physical
numbering was deleted in 2.5.23 or thereabouts.
Hence NR_CPUS is basically impossible to use reliably in 2.6 unless we
reintroduce cpu_logical_map[].
/Mikael
On Mon, Sep 29, 2003 at 11:13:21AM +0200, Mikael Pettersson wrote:
> Problem #1 is that physical CPU numbering isn't dense. This is not a bug.
> Problem #2 is that the kernel's internal dense-logical-to-sparse-physical
> numbering was deleted in 2.5.23 or thereabouts.
> Hence NR_CPUS is basically impossible to use reliably in 2.6 unless we
> reintroduce cpu_logical_map[].
We should be able to at least boot them, since we program logical ID's
ourselves. If you're relying on knowing physids at runtime you'll need
cpu_logical_map[].
-- wli