The short story:
If your mobo posts, and your system boots, and free/top show your ram as 16 gB, then it works. Even mobo makers can under-report capacity of system boards, so the real test is if ram is installed correctly, matched correctly, runs, ie, boots, and runs with stability, ie, doesn't crash, then it works. You can also test by trying to use all your memory for something or other, and seeing if the system remains stable. Because you got very good ram, crucial, it's quite possible that lower grade ram might not have worked at 16gB. That can be why they don't say it supports 16gB but opt for the more conservative 8gB.
Your tools, like free, top, that report real memory of system, are not lying, that is the usable memory the kernel has access to. Tools that read dmi data do lie, because dmi lies randomly based on the companies who filled that data out.
Does gnome-control-center.real info lie?
Memory: 15,7GB
No, it is telling you the truth.
Does dmidecode -t16 say my board can take 2x 8GB or 8GB total?
Maximum Capacity: 8 GB
Number Of Devices: 2
It says 8gB total. You can see it clearly when looking at a sample type 16 (mine, in this case). The capacity refers to the capacity of the array. This is a single memory array. This array has an alleged (though false in your case) capacity of 8gB (correct in my case), and in my case, it has 4 devices. In your case it has 2 devices. Note that you cannot deduce the overall capacity by the max stick you can use in one slot, unfortunately. That is, you could have 4 slots, with an 8gB capacity, but a 4gB per slot max, which would mean you could use either 4x2gG sticks, or 2x4gB, but not 4x4gB.
Handle 0x0012, DMI type 16, 15 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 8 GB
Error Information Handle: Not Provided
Number Of Devices: 4
Does free -h lie saying 11 out of 15GB is used?
No, free is telling you the truth. top will tell you the same truth (though the question of what the kernel considers free or not free is highly arcane, and varies with the implementations of these tools, but that veers far off topic of this question). This is the kernel reporting to userland what ram it has access to, and what is used.
Shouldn't this output of dmidecode -t 17 say 1600 MHz speed?
It depends on your system. And on how dmidecode is interpreting the data. I'm rusty on this part of the question.
The long story:
Since I had to deal pretty heavily with ram reporting issues, I had to discover the variance in quality of the dmidecode ram data reports. Note that this is NOT the fault of dmidecode, since its job is to report the dmi data, not to interpret it or correct it.
First: dmidecode essentially reports two sets of data: 1: some data that someone filled out, that is, a low paid drone at the motherboard vendor has a form to fill out, and either doesn't bother doing it right, or does it right for one model, and then just copies over that data to another. 2: real data, like whether a ram slot has ram in it, it's size, type, speed, etc.
So in the case of system board ram capacity, dmidecode is NOT telling you the capacities based on any actual technical specifications available to dmidecode when it runs. What it's doing is repeating the data that the aforementioned underpaid person was told to fill out to check some box prior to shipping the hardware.
Some mobo vendors supply this data perfectly, and you can fully trust their statements. Others offer completely nonsensical statements, which leads dmidecode to correctly report 4x2gB ram installed, but a capacity of 4gB.
For example, dmidecode will I believe almost always, if not always, tell you the exactly correct information about your installed ram, quite accurately, but the dmi data will then often contain wrong data about capacity.
When I had to deal with this issue, I always used the per stick reporting as authoritative, and I always let it override dmidecode data about actual capacity, because the latter is not real data.
# can be true, false, totally off, or pure fiction re capacity
# the rest of the data is usually pretty good though
dmidecode -t 5
# extremely accurate and reliable, per stick information. Trust it.
dmidecode -t 6
# same as 5, might be right re maximum capacity, might not be
dmidecode -t 16
# extremely accurate, can trust it, but can't learn max
dmidecode -t 17 capacity.
Basically it depends on the motherboard vendor, did they complete the data fields that 5 and 16 use correctly? I'll give you an example that clearly shows the fields they didn't feel like filling out.
Handle 0x001A, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x0012
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 72 bits
Size: 2048 MB
Form Factor: DIMM
Set: None
Locator: DIMM3
Bank Locator: BANK3
Type: DDR2
Type Detail: Synchronous
Speed: 400 MHz
Manufacturer: Manufacturer3
Serial Number: SerNum3
Asset Tag: AssetTagNum3
Part Number: PartNum3
You see this all through dmi data, and inside of /sys, data that was not filled out, half filled out by the vendors, or filled out wrong. The items after speed were not filled out right. My personal favorite is this, which is far more common internally than you'd think:
[Field Name]: To be filled by O.E.M.
You'd think that in this day and age there would be something that actually tells systems exactly what it is, but that's sadly not the case.
I could show you hundreds of instances of machine dmidecode data that demonstrate this issue, but really you only have to see one or two. I tend to think that the better mobo makers tend to fill out their dmi data sets better, and the lower end ones tend to not do that, but there's no hard and fast rule about it.
As a basic rule, this is the information you can trust from dmidecode and ram:
DMI type 5
# Almost nothing in there except some generic information
Error Detecting Method: 64-bit ECC
Error Correcting Capabilities::
None
Associated Memory Slots: 4
Enabled Error Correcting Capabilities:
None
DMI type 6
Socket Designation: DIMM3
Current Speed: 167 ns
Installed Size: 2048 MB (Double-bank Connection)
Enabled Size: 2048 MB (Double-bank Connection)
Error Status: OK # probably
DMI type 16
Number Of Devices: 4
DMI type 17
Data Width: 72 bits
Size: 2048 MB
Locator: DIMM0
Bank Locator: BANK0
Type: DDR2
Type Detail: Synchronous # usually anyway
From Gilles, in comments:
Another reason why dmidecode might underreport the maximum capacity is
when X GB sticks didn't exist yet when the board was manufactured (or
the board manufacturer didn't bother to test with them for some
reason), so the board documents Y GB as the maximum with Y < X, but
when X GB sticks appear they turn out to work.
The key is to realize that the max capacity that dmidecode reports the memory array having is not calculated, it's just some data someone entered when they create the dmi table for the mobo. I generally trust the vendor mobo documentation over the dmi data, but as this poster discovered, even that's not reliable.
