So, I've been using GA-970A-UD3 for about three months now, coupled with 2x4Gb of ordinary DDR3 PC-10600 by Samsung and AMD FX-8120 CPU. As a cooling solution I use Hyper 212 Plus in dual-fan pull/push configuration and original thermal grease (i.e. one that had been supplied inside retail package of this cooler) as a thermal interface.
Hadn't had major problems so far, but can't tell that my experience with this mobo is as flawless as it was with previous mobos (almost all of them were by GigaByte) I've been using.
First of all, there's extremely annoying BIOS issue (affects all BIOS versions I had tried so far: F4, F5, F6) that it fails to successfully enter BIOS setup utility in case there are more than 7 hard drives available for enumerations through Int13h interface. It annoys me pretty badly as the rig I have here is a bit linux-hosted RAID array consisting of 10 HDDs. Six of them are connected to the mobo's built-in SATA ports, rest four are connected to the Sil3114-based PCI controller card. I've got a special hot-swap bay for HDDs which have a per-HDD On/Off switch. In case I have all HDDs turned on and try to access BIOS setup utility - it merely fails with a "silent" hang after AHCI and Sil3114 HDD detection screens with the totally black screen + blinking cursor. As soon as I turn off any three of hard drives (no matter the port/controller they are connected to) - I have no problems accessing BIOS setup utility. I've got just the same hang in case I have 7 HDDs turned on + attached USB flash drive, so it smells to me like an old good "array index out of the bounds" error. Funny thing is that "Boot Selection Menu" (one you got when press F12 key during bootup) does not experience this problem, but it indirectly confirms my suspects about array bounds displaying seven HDDs + one USB "HDD" for the case when I've got all 10 HDDs turned on and a USB stick attached to USB2.0 port.
Second problem is also BIOS-related: in case I install two PCIe SATA 3.0 dual port controllers (as a replacement for my old good 4port SATA PCI card) system refuses to boot and hangs right after displaying BIOS screen of the second controlled card. Same cards work as expected when inserted into several other mobos, including AM2+ mobo by GigaByte I've been using prior to purchasing 970A-UD3.
Sure, the above issues are not something that would affect "normal" user of this mobo (who would usually attach at max three SATA devices, namely SSD for system, HDD for storage and - optionally - ODD for CD/DVD/BD), but in general I'm a bit disappointed by the "BIOS quality" of this mobo - it had been better with previous mobos by GigaByte.
Third problem is not a problem per se, but rather is a total mess I've got with temperature readings using different utilities under different OSes. Main OS this box is running with is linux with pretty fresh kernel version 3.2. Supplemental OS used mostly for testing and gaming is 64bit Win7. Under linux there are special kernel modules k10temp, fam15h_power and it-87 that allow to read thermal into, CPU power consumption, PSU output voltages and FAN speeds info from built-in CPU and mobo sensors (first two drivers are for CPU sensors, it-87 is for mobo). I would not dive into details about these tools from linux world, but rather just say that the values I get from them seems to be mostly the same I get with AMD OverDrive and HWMonitor under Win7. And here we come to the mess named "what the TEMPIN2 really is?". OP writes that it's the temp reading for VRM, but I'm pretty sure it is not.
Here is why:
a) In case I specify in BIOS utlity to sound the alarm on CPU overhead - it programs channel TEMPIN2 of IT8720F chip with the alarm threshold value I had specified. It could be easily checked under linux with the output of the "sensors" utility, and it could be checked under Win7 by setting the threshold to a low value like 60 and executing demanding workload (prime95, multiple instances of SuperPi, Fritz in 8-threaded mode). One could easily notice that PC buzzer would start to buzz as soon as TEMPIN2 would reach 60C deg.
b) If one would inspect values reported by AMD OverDrive he would notice that TEMPIN2 report just the same values as are CPU Core 0-7 temps in AMD OverDrive. Due to a bug in AMD OverDrive it fails to properly report board status when I have all 8 cores of my FX-8120 enabled, but limiting it to 4 cores workarounds the bug and allows to compare TEMPIN2 with CPU Core 0-3 directly in AMD OverDrive at "Board Status" page. Keep in mind that TEMPIN2 is called TMPIN3 in AMD OverDrive. In case you don't want to bother with disabling cores in BIOS to "fix" AMD OD so it would read mobo sensors properly, you could run HWMonitor in parallel with AMD OD and you would easily notice that CPU Core 0-8 temp seems to be the same value as reported by TMPIN2 in HWMonitor.
Accordingly to AMD datasheets on built-in CPU thermal sensors, reported values has nothing to do with the real temperature and should only be used by OS and/or BIOS for controlling FAN speed of the CPU cooling system. Unfortunately it means that we - users of GA-970A-UD3 - are left without the reliable source of the real CPU temperature and have to hope that the cooling system we use is efficient enough and pray that built-in CPU thermal throttling features would keep it from overheating in case cooling efficiency would turn out to be insufficient.
Being pretty sure that TEMPIN2 channel of IT-87 (IT8720F actually) chip is connected to the something, that extremely closely resembles internal CPU thermal sensor, it leaves us with a question where are two other TEMPINx channels of SuperIO chip are connected to. First post on the topic states that TEMPIN0 is connected to the "Motherboard (chipset) sensor" and TEMPIN1 is "CPU". Comparing values reported by ET6 for "System" and values reported by HWMonitor I could agree that TEMPIN0 is most likely connected to the sensor under something, that for older chipsets had been known as "North bridge". As for TEMPIN1 - I'm not sure what it is. Yes, readings tend to increase steadily as I put some heavy workload on CPU and then it steadily decreases as soon as I put CPU back into idle state, so the behavior might resemble so-called "CPU casing" thermal sensor, but it could with the same probability resemble VRM-located thermal sensor as the temperature of VRM MOSFETs and coils would raise the same way CPU casing temparature raises when CPU is burning watts doing something heavy.
TL;DR I could state that this mobo is a pretty good product I woudl recommend to buy and use, despite it have some minor problems with BIOS that could affect some extremely-specific use cases.