Date: Mon, 17 Mar 2003 05:22:55 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Mike O'Brien <obrien@leonardo.net> Cc: John Baldwin <jhb@freebsd.org>, freebsd-smp@freebsd.org Subject: Re: Question about number of CPUs Message-ID: <3E75CC2F.90E35F87@mindspring.com> References: <200303170914.h2H9EXl00756@c-24-130-253-104.we.client2.attbi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike O'Brien wrote: > A reminder: I'm running RELENG_4 on an Iwill DP533 motherboard > with dual Xeons. I'm using this board because it's the only board I've > found that supports both dual Xeon processors and an AGP slot. > > When we last left our hero, he was struggling with the fact that > 'mptable' reports, and the SMP kernel activates, APIC IDs 0 and 1. This > seems screwball; it should be reporting 0 and 2. Nevertheless, Windows XP, > which must be using the ACPI table as opposed to the MP table, correctly > finds four processors. The table doesn't really matter. What matters is the BIOS assignments into the CPUID registers, and which CPU the BIOS considered the "BP", and which CPU(s) the BIOS considers "AP". I believe it should be fairly easy to get your hardware working get your hardware working, given this information. The problem is that FreeBSD trusts the BIOS MP Table too much. I don't think this problem will be solved, as a general case, by shifting the trust from the BIOS MP Table to the ACPI MP Table; it will most likely just switch around who is "broken" and who is "fixed". 8-). No matter who has the "correct" information, or if everyone has the "incorrect" information, or if it's a mixed bag of odds and ends, and some people end up with an "odd" and others end up with an "end" (appologies to George Carlin 8-))... I think that the "correct" thing to do is to use a broadcast IPI to start all the available CPUs. This is because no matter what the case, if it works for _someone_ at all, then the CPU's all have APIC ID's correctly assigned into their APICID registers by the BIOS. Since you can depend on just that, and to hell with the APICID assignments in the MP Table, why not do that, instead? > Certainly something is broken. Either it's doing that, or it's > assigning APIC IDs 0 and 2 to the first physical CPU, and APIC IDs 1 and > 3 to the second physical CPU. Whichever, the spec is being violated. > The board is running the most current BIOS available from Iwill. I think this is more likely... and I don't think it violates the spec. If they wanted, they could pick random non-colliding numbers from 0..31, and I don't think they would be in technical violation of the specification (include the IO APIC(s) in there, though: you have to avoid collisions). Heck... they may have put the IO APIC on APICID 1, and assigned the SMT cores later (i.e. Real CPU #1, I/O APIC, Real CPU #2, SMT Core #1, SMT Core #2). It would even make sense, from the standpoint of doing APIC I/O on a single processor machine. > This message is to report that I girded my loins and committed > violent upon i386/mp_machdep.c. I short-circuited the sanity check > on the APIC ID numbers, and using my a priori knowledge of the results > of 'acpidump', I hotwired the cpu activation code in the second pass > to activate the logical CPUS at the proper APIC IDs. This argues that the boradcast IPI is the way to go. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E75CC2F.90E35F87>