mathfThe Titan X is also let's say more sensitive than the 780 (Ti or not)...
It has 12 GB of VRAM, which means that you need at least the same amount on your board for this work properly.

 
That is actually a myth. There is no requirement for all of the VRAM to be shadowed in main RAM (apertures still only total 192MB of IOMEM space). Of course, that doesn't mean that some poorly programmed games/applications don't do it, I'm just saying there is no strict need for it. You can load the textures (what eats most of the memory) off the disk, shove them into VRAM, and be done with it, no need to keep them in main RAM.
 

mathfI am also thinking that, due to the fact that the SR-2 is a dual socket board, each CPU accesses only its "part" of the RAM... which means that each CPU can allocate max 24 GB (Ok, in your case, 48 GB :P ).
If the guy is using let's say 16 GB in total, it makes 8 per CPU... which is < than the 12 on the card.

 
What you are referring to WRT each CPU directly accessing half the RAM is called NUMA (Non-Uniform Memory Architecture). And there is no real connection between that and the GPU apertures and the RAM allocations. For performance reasons, you ideally want RAM to be allocated on the "near" MCH because the access latency to "local" RAM is half what it is for "remote" RAM. But in reality, process schedulers migrate processes to wherever there's space CPU time available, so on a heavily loaded system, while you can make some optimizations, all bets are generally off. One example of this, and consequences of the optimizations kernels do is what is known as "MySQL swap insanity", if you want to google for some gory details. The "fix" there is to make NUMA allocation work round-robin rather than try to allocate near RAM. You lose some performance on average RAM latency, but you avoid stuff swapping out to disk, which is worse.
 
Anyway, the point is that it's not about RAM size, it's about something quirky going on that breaks the already quirky NF200 (which breaks IOMMU DMA operations anyway, but I've got a workaround for the part of that I was falling foul of, which involves making sure guest VMs don't have any physical RAM mapped between 1GB and 4GB, which is where PCI IOMEM is mapped in host's e820 map).

I'm not even convinced the problem can be "fixed" with a firmware update.
But if we know the specific DMA access pattern that triggers the issue, it may potentially be possible to work around it in the driver (then we would need Nvidia to write a workaround in the driver - not something that I expect to happen any more than a BIOS update for the SR-2 to fix other much more obvious problems that have been known about for longer).

Not yet - the cards weren't available yet from my usual suppliers in UK.

I haven't looked very hard, but people have reported issues here on the EVGA forums.
My use case is very narrow (Linux-only, VT-d with PCI passthrough of GPUs to VMs), but the Titan X would be on the bare metal side of that configuration, with the VM running a 780Ti. I'm only really looking to upgrade one of my 780Ti cards because I want to upgrade to the new Dell UP2715K monitor - that requires dual DP inputs, and there are no pre-Maxwell GeForce cards with multiple DPs. Some Quadros with multiple DPs are available, but they are far too expensive.
 
If the Titan X proves to be too problematic, I'll probably have to do the unthinkable and downgrade to an AMD HD7970. Oddly, HD7970 (and rebadged versions thereof), came with dual DP outputs, but R9 cards did not.

I'm currently using an IBM T221 - at 3840x2400, it is still the second highest pixel count on any monitor, and after 14 years, it has only just been bested by the 5K screens.

No, that is not normal. Have you verified the problem is tied to the specific CPU socket, rather than the specific CPU or memory.
Do you use ECC RAM? I'm not sure how extensive Windows support for EDAC error reporting is, if it supports it there would be entries in the system event log to that effect. Xeons have ECC built in for various parts of them, and the NB/SB do as well, as does PCI, and all of this will be reported via EDAC, along with any RAM ECC errors, correctable or otherwise.
 
I have seen RAM before that is unstable at stock settings (e.g. Patriot), which is the main reason I have woved to never again build a workstation without ECC RAM.
If you can eliminate RAM being the cause (ideally by getting some ECC RDIMMs and testing sockets one at a time), then it's time to RMA the board.
 
It might also be worth checking all the pins in your CPU sockets, and cleaning the CPU contacts with isopropanol and/or a pencil eraser.
 
Either way, what you are describing is definitely not normal, at stock settings everything should "just work".

I am reasonably sure I have tested before with each socket on my boards, but last time I had to do that was 18+ months ago, so I'm not 100% sure.
Troubleshooting issues like this is tricky. It is the main reason why I bought a complete second set of components (SR-2, ECC RAM, CPUs) just to be able to carry out a sanity cross-check on everything. If I hadn't done that, I might have given up on my first SR-2 (which I'm about to RMA for the 3rd time). Thankfully the 2nd one I bought never skipped a beat).

***WARNING READ THIS BEFORE YOU UPDATE***

The firmware update instructions at the top of this thread failed to mention one REALLY important detail.
 
"First go into your BIOS and load defaults, save and exit"
 
If you have hardware RAID enabled, this will disable it.  WORSE!  If you have RAID 0 and try to boot windows 7 or newer it will write to the first disk in the array and corrupt it. The last step of resetting the BIOS and rebooting will do the same too.
 
Just lost my 6TB raid set thanks to these instructions.    This really choked me!
 
 

You can download it from the evga support center:
 
http://cdn.evga.com/bios/SR2/W555_A58.zip

Done: I put the folder in C directory and ran it normally (I mean, If I 'run as administrator' it does not work...)

I have updated my SR-2 with a Titan X (maxwell) for KVM, and Titan Black for host (i also use linux and KVM with VGA passtrougth)
 
at the moment , no issues
 
have a 48G Gskill Riphaws @1600 and dual xeon [link=mailto:x5650@2.72]x5650@2.72[/link] (for can use the memos at 1600)
 
also have a LSI 9240-i8 (5 disk at the moment. JBOD, no raid), and installed today a Dell PERC H200 for the SSD for host and SDD used by the guest (Win 10), and one normal HDD and one BR-DVD unit. both controllers only for host (zero units/controllers passtroughted)
 
greetings