Messages in this thread | ![/](/images/icornerl.gif) | | Date | Fri, 4 Jul 2003 12:16:41 -0400 (EDT) | From | Zwane Mwaikambo <> | Subject | Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works. |
| |
On Fri, 4 Jul 2003, Martin J. Bligh wrote:
> > No, the problem is no space for physical ids in cpumask bitmaps, this > > could manifest itself later on unless we fix it now. > > Ugh, are you saying the cpumask stuff shrinks masks to < 32 bits if > NR_CPUS is low enough? If so, I can see more point to the patch, but > it still seems like violent overkill. Stopping it doing that would > probably fix it ... I can't imagine it buys you much.
Hmm i hope not, Bill can you verify that? Looking at the source it doesn't appear to be so;
#define BITS_TO_LONGS(bits) \ (((bits)+BITS_PER_LONG-1)/BITS_PER_LONG) #define DECLARE_BITMAP(name,bits) \ unsigned long name[BITS_TO_LONGS(bits)]
> phys_cpu_present_map started off as an unsigned long, and I reused it > in a fairly twisted way for NUMA-Q. As it's an array that's bounded > by apic space, using the bios_cpu_apicid method that summit uses > would be a much cleaner fix, and just leave the old one as a long > bitmask like it used to be - which is fine for non- clustered apic > systems, and saves inventing a whole new data type. See the > cpu_present_to_apicid abstraction.
Thanks i'll have a look.
-- function.linuxpower.ca - 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/
| ![\](/images/icornerr.gif) |