Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.

From: William Lee Irwin III (wli@holomorphy.com)
Date: Fri Jul 04 2003 - 13:29:34 EST


At some point in the past, I wrote:
>>> -#define APIC_BROADCAST_ID (0x0f)
>>> +#define APIC_BROADCAST_ID (0xff)

On Fri, 4 Jul 2003, Martin J. Bligh wrote:
>> So ... you've tested that change on a bigsmp machine, right?
>> At least, provide some reasoning here. Like this comment further down the
>> patch ...

On Fri, Jul 04, 2003 at 11:47:03AM -0400, Zwane Mwaikambo wrote:
> That one is slightly worrying, yes.

It is not. It's a bound on physical APIC ID's. bigsmp is xAPIC-based.

At some point in the past, I wrote:
>>> +++ physid-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h
>>> 2003-07-04 02:45:17.000000000 -0700
>>>
>>> -static inline cpumask_t apicid_to_cpu_present(int logical_apicid)
>>> +static inline physid_mask_t apicid_to_cpu_present(int logical_apicid)
>>> {
>>> int node = apicid_to_node(logical_apicid);
>>> int cpu = __ffs(logical_apicid & 0xf);
>>>
>>> - return cpumask_of_cpu(cpu + 4*node);
>>> + return physid_mask_of_physid(cpu + 4*node);
>>> }

On Fri, 4 Jul 2003, Martin J. Bligh wrote:
>> Hmmmm. What are you using physical apicids here for? They seem
>> irrelevant to this function.

On Fri, Jul 04, 2003 at 11:47:03AM -0400, Zwane Mwaikambo wrote:
> Urgh, it's really hard to determine what these functions really want half
> the time. But that change does look wrong.

It's fine. It's used to generate a bitmask that's or'd with
phys_cpu_present_map.

-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:23 EST