Bug 16269

	For some reason the BIOS on the Goliath II sets the IO APIC's
	id to 2 in the mptable, while also setting cpu 2's id to 2.
	This causes SMP initialization to blow up.  Because
	ID_TO_CPU() and ID_TO_IO() both refrence the same array, when
	we reach the IO APIC's mptable entry, it overwrites the
	mapping	for cpu 2, causing panics like this:

	[other kernel messages deleted]
	SMP: AP CPU #3 Launched!
	SMP: AP CPU #1 Launched!
	SMP: AP CPU #2 Launched!
	SMP: cpuid = 2
	SMP: apic_id = 0
	PTD[MPPTDI] = 0x31d023
	panic: cpuid mismatch! boom!!
	mp_lock = 02000001; cpuid = 2; lapic.id = 02000000

Fix: Ideally there'd be a new BIOS for this board that wasn't so
	braindead.  However, I spent some time trying to find an
	updated BIOS for it and had no luck.  It seems that AMI
	dosen't seem to care much about it these days. =(

	At the very least there should be a check to see if we've
	already got a cpu at that apic id.  ie. add this to
	mp_machdep.c:io_apic():

if (ID_TO_CPU(io_apic_id) != -1)
	panic("IO APIC #%d id conflicts with cpu #%d's local APIC id!",
		apic, ID_TO_CPU(io_apic_id));

 	However, the last paragraph of section 3.6.6 of v1.4 of the MP
 	spec does clearly state that it's up to the OS to assign a
 	unique id to io apic's in case there's a conflict, so 
 	this fix is potentially useful anyway, even if in this case
 	AMI was just being lazy/stupid. =)

	So, the patch: It checks to see if there's a conflict
	between an io apic's id and a cpu's id.  If there's a
	conflict, it assigns a new id starting with the lowest
	possible id, as per section 3.6.6.  In the process it keeps
	track of the mapping from the original mptable id and the new
	id, since we'll also have to remap the destination apic id of
	any io interrupt mptable entries.
How-To-Repeat: 
	Boot an SMP kernel with NCPU > 2 on a Goliath II system. =)