Re: UP local APIC is deadly on SMP Athlon

Mikael Pettersson (mikpe@user.it.uu.se)
Sat, 22 Feb 2003 01:38:49 +0100 (MET)


On Fri, 21 Feb 2003 22:41:23 +0100, Marc-Christian Petersen wrote:
>> And this is what I found: eliminating two lines from
>> APIC_init_uniprocessor() makes the problem go away.
>> diff -urNX diff_kernel_excludes linux-2.4.10-pre12/arch/i386/kernel/apic.c
>> linux-2.4.10-pre11++/arch/i386/kernel/apic.c ---
>> linux-2.4.10-pre12/arch/i386/kernel/apic.c Wed Feb 19 23:53:15 2003 +++
>> linux-2.4.10-pre11++/arch/i386/kernel/apic.c Fri Feb 21 15:37:06 2003 @@
>> -1087,9 +1087,6 @@
>>
>> connect_bsp_APIC();
>>
>> - phys_cpu_present_map = 1;
>> - apic_write_around(APIC_ID, boot_cpu_id);
>> -
>> apic_pm_init2();
>>
>> setup_local_APIC();
>>
>> [patch against 2.4.10-pre12, but 2.4.21-pre4 is reasonably similar]
>Don't do this. I am pretty sure it will break all Intels. I still cannot
>understand why this fixes your AMD Athlon problem.

This is interesting. Very interesting, even. A plain UP_APIC kernel
(with IO_APIC not enabled or not detected) shouldn't need to touch
APIC_ID at all. I strongly suspect this is a remnant of apic.c's old
SMP-only history, and that it should be removed for UP_APIC-only.

I need to get some downtime (zzz...) but I'll look into this ASAP.

/Mikael
-
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/


gfp_mask, order) \
+ alloc_pages_node(numa_node_id(), gfp_mask, order)
+#define alloc_page(gfp_mask) \
+ alloc_pages_node(numa_node_id(), gfp_mask, 0)

extern unsigned long FASTCALL(__get_free_pages(unsigned int gfp_mask, unsigned int order));
extern unsigned long FASTCALL(get_zeroed_page(unsigned int gfp_mask));

--=_courier-6148-1045874843-0001-2--