dmesg (new) with disabled GART error reporting if anyone wants to
compare to previous dmesg with GART error reporting :
dmesg
Linux version 2.6.23.1 (root@unix) (gcc version 4.1.2 20061115
(prerelease) (Debian 4.1.1-21)) #5 SMP Fri Oct 26 04:07:27 EDT 2007
Command line: root=/dev/md1 ro
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
 BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000c7ff0000 (usable)
 BIOS-e820: 00000000c7ff0000 - 00000000c7ffe000 (ACPI data)
 BIOS-e820: 00000000c7ffe000 - 00000000c8000000 (ACPI NVS)
 BIOS-e820: 00000000fec00000 - 00000000fec03000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 0000000100000000 - 0000000238000000 (usable)
Entering add_active_range(0, 0, 159) 0 entries of 3200 used
Entering add_active_range(0, 256, 819184) 1 entries of 3200 used
Entering add_active_range(0, 1048576, 2326528) 2 entries of 3200 used
end_pfn_map = 2326528
DMI 2.3 present.
ACPI: RSDP 000F9200, 0024 (r2 ACPIAM)
ACPI: XSDT C7FF0100, 0054 (r1 A M I  OEMXSDT   8000729 MSFT       97)
ACPI: FACP C7FF0290, 00F4 (r3 A M I  OEMFACP   8000729 MSFT       97)
ACPI: DSDT C7FF0470, 3B36 (r1  0AAAA 0AAAA000        0 INTL  2002026)
ACPI: FACS C7FFE000, 0040
ACPI: APIC C7FF0390, 00DA (r1 A M I  OEMAPIC   8000729 MSFT       97)
ACPI: OEMB C7FFE040, 0056 (r1 A M I  AMI_OEM   8000729 MSFT       97)
ACPI: SRAT C7FF3FB0, 00E8 (r1 AMD    HAMMER          1 AMD         1)
ACPI: HPET C7FF40A0, 0038 (r1 A M I  OEMHPET   8000729 MSFT       97)
ACPI: SSDT C7FF40E0, 0A30 (r1 A M I  POWERNOW        1 AMD         1)
SRAT: PXM 0 -> APIC 0 -> Node 0
SRAT: PXM 0 -> APIC 1 -> Node 0
SRAT: PXM 0 -> APIC 2 -> Node 0
SRAT: PXM 0 -> APIC 3 -> Node 0
SRAT: Node 0 PXM 0 0-a0000
Entering add_active_range(0, 0, 159) 0 entries of 3200 used
SRAT: Node 0 PXM 0 0-c8000000
Entering add_active_range(0, 0, 159) 1 entries of 3200 ...
[ message continues ]

This is probably wrong.  The TSC is on the northbridge on Barcelona chips, so 
every core on the die should be in sync.  Hypothetically you could have 
different speed northbridges in different sockets, but we've never tried very 
hard to support that case anyway.  We should probably be marking the TSC as 

We should probably also implement an SSE5 function to take advantage of the 

Hmmm... perhaps we're not handling the new mmconfig stuff correctly?  Or maybe 


An update here for SSE5 might be in order as well.

	-- Chris
-

[ message continues ]

It's a little more complicated. Stable clock is only guaranteed as long 
as the CPUs all run on the same clock crystal. That is true 
when they're all on the current motherboard. But at least for K8
there were several systems that consist of multiple motherboards
and HT cables inbetween them (like all the 8 socket systems).
On those the TSCs can drift too with Fam10h. I'm not aware
of any of those shipping yet, but since it's essentially 
the same platform as K8 they will appear sooner or later.

So far we lack a reliable way to detect this condition. If it could
be detected it would be possible to switch to TSC timing
for the single motherboard systems.

However after some bad experiences in the past I personally would only
do that after such a system demonstrates synchronized TSC for at least

SSE5 doesn't exist in Fam10h

In general the optimized x86 RAID functions are mostly quite suboptimal
on my testing and do not actually do what they promise (E.g. the cache
avoiding functions do not actually avoid the cache fully etc.) I had a
rewrite of them in C some time ago which was faster on most CPUs
except on Core2 for so far unknown reasons. Needs more work.

-Andi
-

[ message continues ]

Would it not be as simple as looking at the BIOS provided topology
information? If nr sockets > 4 assume multiple board.

Of course one could run a multi board solution and not utilize all
sockets, in which case the heuristic would fail, but I guess buying such
an expensive solution and then not sticking in the cpus is rather rare.


-

[ message continues ]

There is no reason multiple two socket boards couldn't be connected
with HT cables to form a larger system. Then you might end up
with a 4 socket system with multiple oscillators.

-Andi
-

[ message continues ]