On Fri, Dec 28, 2012 at 08:49:51AM +0000, Mark Morgan Lloyd wrote: > [email protected] wrote: > >On Thu, Dec 27, 2012 at 07:01:08PM +0000, Mark Morgan Lloyd wrote: > >>Ewald wrote: > >> > >>>Now, for the implementation of ProcessorCount I've got code here that > >>>reads the amount of processor cores from `/proc/cpuinfo` (linux only I > >>>think) and some assembly code [asmmode att] (tested on x86_64 and i386) > >>>that *tries* to get the amount of cpu cores by the use of CPUID. The > >>In the general case, you have to be careful with this since (a) > >>every architecture puts different info in /proc/cpuinfo and (b) the > >>processor numbering and affinity vectors can have gaps. > > > >In the general case how is his x86 asm supposed to ever work on anything but > >Intel or AMD boxes? > .. > >Looks like a weird bug in the probing. Why does it miss CPs 2,3,6,7? > > Because on that architecture every board, when initialising, starts > off by running independently and gets an ID from its slot position. > One slot (slot 1, not 0) is taken up by the mandatory card which has > things like keyboard, serial and diagnostic JTAG support, and > another (slot 3 on the system here) by a card with enough SCSI and > Ethernet to boot. Once all cards have decided they're OK, the first > card sends JTAG commands to the bus controllers on every card to > rewire them to distribute resources over the centerplane, but the > CPU IDs persist through to the process and interrupt affinity > vectors (the taskset command on Linux).
Oh sorry, I misunderstood your post. I thought you meant only 12 of 16 CPUs were showing in Linux. If you only have 12 CPUs in this case then I understand the explanation. I seem to remember a discussion where you said you have a box with 16 sockets. _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
