Wired Memory Reports 16TB

[Asher-]

I'm working with an Asus Z10PE-D8-WS, which is quad channel with 8 slots. Slots 1 and 5 each have a 64GB Nemix LRDIMM. 

Automatic detection reports each DIMM as 32GB, although OS X nevertheless ends up reporting 128GB. However, Activity Monitor reports 16TB (yes TB) wired memory.

Has anyone else seen this? 

Can any developers point me to a general region of Clover source that corresponds to handling system profiler information? I was able to solve autodetection by changing Size to UINT_32 (see issue comment) but that didn't change wired memory reporting. 

More info here https://sourceforge.net/p/cloverefiboot/tickets/460/. 

Edited June 18, 2018 by Asher-

[Slice]

smbios.c

[Asher-]

Am I correct in understanding that memory reported by the OS as wired that comes from Clover/SmBios would arrive through table 19, which is used to declare mapped memory? 

 

Could you offer any conceptual understanding as to how information calculated by Clover arrives at an xnu interface for vm_page_wire_count? 

 

I believe what is happening is that an integer overflow somewhere in Clover is causing a mapped range to be extended to 0xfff... or similar. Any ideas how to approach tracking that down? I'm happy to do the heavy lifting, but could use some insight.

 

Asher

[Slice]

AppleSmbios.kext parsed SMBIOS left by Clover and takes values from tables 16,17,19,20.

You may look AppleSmbios sources, your boot-log, DarwinDumper report: DMI section and compare where is the discrepancy.

[Asher-]

No solution yet, but have learned some things:

 

* There was a known issue with the same SPD 8086.8D22 in 2016 - pages ~32-35 of the Clover issues post. It's unclear whether a resolution was reached, as the following 9 days were apparently lost in a server crash. There doesn't seem to be any sign of the code fragments under discussion in the Clover codebase, and no further discussion seems available. 

* I stripped the SMBIOS 17 section to the bare minimum using only static info declared in code. This works consistently with unedited codebase.

  - Setting ModuleSize to 65536 prevents boot (+++++)

  - setting to 32768 boots past ++++ but hangs after spaceman_trim with an out of memory for zone map error.

  - Clover boot.log autodetect from SmbiosTable.Type17->Size reports "622591MB" for each of the two 64GB LRDIMMs. 

  - Manually-specified value of 622591 boots consistently with unedited codebase. 

* Bad SPD info was causing additional misinformation to be injected (each of the empty slots was reporting in use @ 1245182), but fixing code so empty slots register as empty has not changed reporting on wired memory. I would assume this is related to the total memory reporting, but the wired memory value hasn't changed while the total memory has, even if it is still wrong. 

* Total memory reported at 1245182.

 

Questions

* Is there some way that 622591 makes sense?

* Any idea whether there was any resolution to reading spd on 8086.8d22?

* Should I worry about the SPD at all or simply continue excluding it by way of static values until narrowing down the issue elsewhere? (I'm thinking this is the course to take, but please correct if there is a good reason to figure out reading from this SPD).

[Asher-]

Do we have any understanding of Table 130?

 

Quote

typedef struct {
  SMBIOS_STRUCTURE      Hdr;
  UINT16                Type17Handle;  // 17 << 8
  UINT16                Offset;             // ??
  UINT16                Size;                // ?? - 128?
  UINT16                Data[];            // First 128 bytes of SPD data
} SMBIOS_TABLE_TYPE130;

 

Clover currently just skips the table:

 

Quote

VOID PatchTableType130()
{
    //
    // MemorySPD (TYPE 130)
    // TODO:  read SPD and place here. But for a what?
    //
    SmbiosTable = GetSmbiosTableFromType (EntryPoint, 130, 0);
    if (SmbiosTable.Raw == NULL) {
        return ;
    }
    //
    // Log Smbios Record Type130
    //
    LogSmbiosTable(SmbiosTable);
    return ;
}

 

Presumably the table will never exist since we are not using Apple hardware and it is an Apple specific SMBIOS table. 

 

Apple SMBIOS relates to the provided data in this method:

 

Quote

 

void AppleSMBIOS::processSMBIOSStructureType130(
    const SMBMemorySPD *    spd,
    SMBPackedStrings *      strings )
{
    unsigned int dataSize;
    
    if(spd->Offset > 127) return; // Only care about the first 128 bytes of spd data
    
    dataSize = (spd->Size + spd->Offset) > 128 ? 128 - spd->Offset : spd->Size;
    memInfoData->appendBytes(spd->Data, dataSize);

}

 

 

The comment reads to me to indicate that the goal is the first 128 bytes of spd data. Why Size and Offset, then? 

 

dataSize seems to be calculating whether to read the spd from the front (page 1) or the back (page2). But why if the goal is the first 128 bytes?

 

On my MacbookPro13,3, table 130 looks like this:
 

Quote

 

∴ dmidecode -t 130
# dmidecode 3.1
Getting SMBIOS data from Apple SMBIOS service.
SMBIOS 3.0 present.

Bad address
Handle 0x0007, DMI type 130, 186 bytes
OEM-specific Type
    Header and Data:
        82 BA 07 00 06 00 00 00 B0 00 91 20 F1 03 05 1A
        05 0A 03 11 01 08 08 00 00 15 78 78 90 50 90 11
        50 E0 90 06 3C 3C 01 90 00 00 00 31 C2 08 00 00
        00 A8 00 88 00 00 00 00 00 00 00 00 00 00 00 00
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80
        2C 00 00 00 00 00 00 00 93 41 4D 54 35 32 4C 31
        47 33 32 44 34 50 47 2D 30 39 33 20 00 00 00 00
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        00 00 00 00 00 00 00 00 00 00

Handle 0x0009, DMI type 130, 186 bytes
OEM-specific Type
    Header and Data:
        82 BA 09 00 08 00 00 00 B0 00 91 20 F1 03 05 1A
        05 0A 03 11 01 08 08 00 00 15 78 78 90 50 90 11
        50 E0 90 06 3C 3C 01 90 00 00 00 31 C2 08 00 00
        00 A8 00 88 00 00 00 00 00 00 00 00 00 00 00 00
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80
        2C 00 00 00 00 00 00 00 93 41 4D 54 35 32 4C 31
        47 33 32 44 34 50 47 2D 30 39 33 20 00 00 00 00
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        00 00 00 00 00 00 00 00 00 00

 

 

Bytes 0-9 (0x82 0xBA) are identical. => ??

Bytes 17-24 (0x07 and 0x09) correspond to the table 130 handle. 

Bytes 32-40 (0x06 and 0x08) correspond to the table 17 handle.

The next sequence is shared (00 00 00 B0 00 91 20 F1 03 05 1A 05 0A 03 11 01 08 08 00 00 15 78 78 90 50 90 11 50 E0 90 06 3C 3C 01 90 00 00 00 31 C2 08). Probably manufacturer, etc?

The second set of bytes "93 41 4D 54 35 32 4C 31 47 33 32 44 34 50 47 2D 30 39 33 20" corresponds with the part number listed in table 17 (0x4D5435324C31473332443450472D30393320). Both SODIMMs have the same part number.

 

Thoughts on how to approach this?