[ Putting everyone cc again and leaving maciej's reply intact for
reference ]
Maciej W. Rozycki wrote:
The ID is 0x14 for Intel. But that is wrong for AMD CPUs. The actual Dual-Core
Why can't hw designers ever get such things right? Sigh...
Athlon CPUs we have report an APIC version of
On Wednesday 31 August 2005 15:13, Martin Wilck wrote:
> In other words: What would be broken if we just used an APIC ID mask of
> 0xFF everywhere?
Nothing I think. It's more historical reasons. The physflat subarchitecture
patch essentially removed it, but it needs some rework and merging
with
Hi Maciej,
It actually depends on the APIC type, rather than the CPU. E.g. with
Pentium systems the width of the ID is either 4 bits or 8 bits,
depending on whether the integrated or an external 82489DX APIC is
used. This should be able to be determined by the APIC version; for
v <= 0xf the ID
On Wed, 31 Aug 2005, Martin Wilck wrote:
> We are wondering why these masks are there in the subarch code at all. After
> all, whether or not 8-bit APIC IDs are supported depends mainly on the CPU
> type used. Why wouldn't it possible to have a "default" architecture with APIC
> IDs > 15, if the C
Hi Andi, hi everyone,
The MP_valid_apicid() function [arch/i386/kernel/mpparse.c] checks
whether the APIC version field is >=20 in order to determine whether
the CPU supports 8-bit physical APIC ids.
Yes, it's broken. ... . Also it's only
a sanity check for broken BIOS, and in this case it cau
Maciej W. Rozycki wrote:
You are unfortunately mistaken -- the spec is explicit about *local* APIC
IDs having to start at 0. There are at least two places in the spec that
refer to that.
I see. Thanks for the clarification.
You can always assign 0, 16, 17, etc. to local APICs and then 1,
On Fri, 26 Aug 2005, Martin Wilck wrote:
> Unless I am mistaken, the MP spec does not say that _CPUs_ must start from 0.
> We had an IO-APIC at 0. The MP spec says that the IDs must be unique (I am
> told this isn't true any more because an IO APIC and a CPU may have the same
> ID) and _need not_
Maciej W. Rozycki wrote:
Well, Intel's "Multiprocessor Specification" mandates that (see section
3.6.1 and also the compliance list in Appendix C). I does not mandate
local APIC IDs to be consecutive though.
Unless I am mistaken, the MP spec does not say that _CPUs_ must start
from 0. We h
On Mon, 22 Aug 2005, Martin Wilck wrote:
> It's a scalable system where multiple boards may be combined. Anyway, I see
> nothing in the specs that says you must start counting CPUs from zero.
Well, Intel's "Multiprocessor Specification" mandates that (see section
3.6.1 and also the compliance l
yhlu wrote:
why matrin need to make apic id to be greater than 0x10 when system is
only 2way?
It's a scalable system where multiple boards may be combined. Anyway, I
see nothing in the specs that says you must start counting CPUs from zero.
Regards
Martin
--
Martin WilckPh
> Not sure if we ever support CPUs with different APIC versions. That will
> probably require some ACPI SPEC changes too..
>
> I would say, for now just follow the i386 code.
Ok I applied the patch. Thanks.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
On Fri, Aug 12, 2005 at 08:22:28PM +0200, Andi Kleen wrote:
> > --- linux-2.6.13-rc6/arch/x86_64/kernel/mpparse.c~ 2005-08-12
> > 10:19:07.037696416 -0700
> > +++ linux-2.6.13-rc6/arch/x86_64/kernel/mpparse.c 2005-08-12
> > 10:19:38.098974384 -0700
> > @@ -707,7 +707,7 @@
> >
> > process
> --- linux-2.6.13-rc6/arch/x86_64/kernel/mpparse.c~2005-08-12
> 10:19:07.037696416 -0700
> +++ linux-2.6.13-rc6/arch/x86_64/kernel/mpparse.c 2005-08-12
> 10:19:38.098974384 -0700
> @@ -707,7 +707,7 @@
>
> processor.mpc_type = MP_PROCESSOR;
> processor.mpc_apicid = id;
> -
On Fri, Aug 12, 2005 at 04:57:25PM +0200, Andi Kleen wrote:
> On Fri, Aug 12, 2005 at 04:55:40PM +0200, Martin Wilck wrote:
> > I wrote:
> >
> > >>How so? The XAPIC version check should work there.
> > >
> > >ACPI: LAPIC (acpi_id[0x11] lapic_id[0x21] enabled)
> > >Processor #33 15:4 APIC version 1
why matrin need to make apic id to be greater than 0x10 when system is
only 2way?
too much io-apic in system?
YH
On 8/12/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 12, 2005 at 09:37:11AM -0700, yhlu wrote:
> > So MPTABLE do not have problem with it, only acpi related...?
>
> It's o
On Fri, Aug 12, 2005 at 09:37:11AM -0700, yhlu wrote:
> So MPTABLE do not have problem with it, only acpi related...?
It's only a cosmetic problem I think with the printk being
wrong. The actual decision in the code should all use the true
value.
Another way would be to just remove the printk out
So MPTABLE do not have problem with it, only acpi related...?
YH
On 8/12/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 12, 2005 at 04:55:40PM +0200, Martin Wilck wrote:
> > I wrote:
> >
> > >>How so? The XAPIC version check should work there.
> > >
> > >ACPI: LAPIC (acpi_id[0x11] lapic_
I wrote:
How so? The XAPIC version check should work there.
ACPI: LAPIC (acpi_id[0x11] lapic_id[0x21] enabled)
Processor #33 15:4 APIC version 16
ACPI: LAPIC (acpi_id[0x12] lapic_id[0x26] enabled)
Processor #38 15:4 APIC version 16
Forget it. I have fallen prey to this line:
proces
On Fri, Aug 12, 2005 at 04:55:40PM +0200, Martin Wilck wrote:
> I wrote:
>
> >>How so? The XAPIC version check should work there.
> >
> >ACPI: LAPIC (acpi_id[0x11] lapic_id[0x21] enabled)
> >Processor #33 15:4 APIC version 16
> >ACPI: LAPIC (acpi_id[0x12] lapic_id[0x26] enabled)
> >Processor #38 1
Andi Kleen wrote:
on the Intel Xeon MP systems, too,
How so? The XAPIC version check should work there.
ACPI: LAPIC (acpi_id[0x11] lapic_id[0x21] enabled)
Processor #33 15:4 APIC version 16
ACPI: LAPIC (acpi_id[0x12] lapic_id[0x26] enabled)
Processor #38 15:4 APIC version 16
This is a boot
On Fri, Aug 12, 2005 at 03:21:00PM +0200, Martin Wilck wrote:
> >Yes, it's broken. In fact I removed it in my physflat32 patch
> >which is needed for 16 core AMD systems. I don't think there
> >is a generic way to fix it because the XAPIC check breaks
> >on AMD systems
>
> on the Intel Xeon MP sy
Andi Kleen wrote:
Yes, it's broken. In fact I removed it in my physflat32 patch
which is needed for 16 core AMD systems. I don't think there
is a generic way to fix it because the XAPIC check breaks
on AMD systems
on the Intel Xeon MP systems, too,
and there is no good way to decide early
o
Martin Wilck <[EMAIL PROTECTED]> writes:
> Hi William, hello everyone,
>
> The MP_valid_apicid() function [arch/i386/kernel/mpparse.c] checks
> whether the APIC version field is >=20 in order to determine whether
> the CPU supports 8-bit physical APIC ids.
Yes, it's broken. In fact I removed it
Hi William, hello everyone,
The MP_valid_apicid() function [arch/i386/kernel/mpparse.c] checks
whether the APIC version field is >=20 in order to determine whether the
CPU supports 8-bit physical APIC ids.
We currently have two modern processors oin our labs (Intel Xeon MP, AMD
Dual-Core Opt
24 matches
Mail list logo
