I have access to a server and want to check its HMAT table. However, the HMAT table is not present (the SRAT and SLIT are though). I checked the Linux kernel config and the HMAT is enabled (CONFIG_ACPI_HMAT=y and CONFIG_ACPI=y). So probably the issue is with the hardware and firmware. Can I enable the HMAT, and if so, how? Here's the server spec (let me know if more information is needed): $ uname -a Linux node0.acpi-tinkering-0.prismgt-pg0.clemson.cloudlab.us 5.15.0-122-generic #132-Ubuntu SMP Thu Aug 29 13:45:52 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux $ sudo dmidecode -t 2 # dmidecode 3.3 Getting SMBIOS data from sysfs. SMBIOS 3.3 present. Handle 0x0200, DMI type 2, 8 bytes Base Board Information Manufacturer: Dell Inc. Product Name: 024PW1 Version: A00 Serial Number: .13D52G3.CNIVC001610605. $ sudo dmidecode -t 0 # dmidecode 3.3 Getting SMBIOS data from sysfs. SMBIOS 3.3 present. Handle 0x0000, DMI type 0, 26 bytes BIOS Information Vendor: Dell Inc. Version: 2.8.4 Release Date: 06/23/2022 Address: 0xF0000 Runtime Size: 64 kB ROM Size: 32 MB Characteristics: ISA is supported PCI is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported EDD is supported Japanese floppy for Toshiba 1.2 MB is supported (int 13h) 5.25"/360 kB floppy services are supported (int 13h) 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 kB floppy services are supported (int 13h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported BIOS boot specification is supported Function key-initiated network boot is supported Targeted content distribution is supported UEFI is supported BIOS Revision: 2.8 sudo dmidecode -t 4 # dmidecode 3.3 Getting SMBIOS data from sysfs. SMBIOS 3.3 present. Handle 0x0400, DMI type 4, 48 bytes Processor Information Socket Designation: CPU1 Type: Central Processor Family: Zen Manufacturer: AMD ID: 11 0F A0 00 FF FB 8B 17 Signature: Family 25, Model 1, Stepping 1 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) MMX (MMX technology supported) FXSR (FXSAVE and FXSTOR instructions supported) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) HTT (Multi-threading) Version: AMD EPYC 7543 32-Core Processor Voltage: 1.8 V External Clock: 16000 MHz Max Speed: 3900 MHz Current Speed: 2800 MHz Status: Populated, Enabled Upgrade: Socket SP3 L1 Cache Handle: 0x0700 L2 Cache Handle: 0x0701 L3 Cache Handle: 0x0702 Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified Core Count: 32 Core Enabled: 32 Thread Count: 64 Characteristics: 64-bit capable Multi-Core Hardware Thread Execute Protection Enhanced Virtualization Handle 0x0401, DMI type 4, 48 bytes Processor Information Socket Designation: CPU2 Type: Central Processor Family: Zen Manufacturer: AMD ID: 11 0F A0 00 FF FB 8B 17 Signature: Family 25, Model 1, Stepping 1 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) MMX (MMX technology supported) FXSR (FXSAVE and FXSTOR instructions supported) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) HTT (Multi-threading) Version: AMD EPYC 7543 32-Core Processor Voltage: 1.8 V External Clock: 16000 MHz Max Speed: 3900 MHz Current Speed: 2800 MHz Status: Populated, Enabled Upgrade: Socket SP3 L1 Cache Handle: 0x0703 L2 Cache Handle: 0x0704 L3 Cache Handle: 0x0705 Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified Core Count: 32 Core Enabled: 32 Thread Count: 64 Characteristics: 64-bit capable Multi-Core Hardware Thread Execute Protection Enhanced Virtualization

**Description:** I am experiencing an issue with obtaining detailed CPU information using the dmidecode command on a Linux guest OS virtual machine running in VirtualBox. The dmidecode command provides only limited data, while other commands like lscpu and cat /proc/cpuinfo return complete CPU details. **Steps to Reproduce:** 1. Install Debian11/12 or Ubuntu22.04 as a guest OS in VirtualBox. 2. Run the sudo dmidecode command to obtain hardware information. **Expected Results:** The dmidecode command should provide detailed CPU information similar to what is provided by lscpu and /proc/cpuinfo. **Actual Results:** The dmidecode command returns limited information, mostly related to the BIOS and basic system configuration. Detailed CPU information is not included. **Example Output:** Here is the output of the sudo dmidecode command on my Debian12 VM:

# dmidecode 3.4
Getting SMBIOS data from sysfs.
SMBIOS 2.5 present.
10 structures occupying 450 bytes.
Table at 0x000E1000.

Handle 0x0000, DMI type 0, 20 bytes
BIOS Information
    Vendor: innotek GmbH
    Version: VirtualBox
    Release Date: 12/01/2006
    Address: 0xE0000
    Runtime Size: 128 kB
    ROM Size: 128 kB
    Characteristics:
        ISA is supported
        PCI is supported
        Boot from CD is supported
        Selectable boot is supported
        8042 keyboard services are supported (int 9h)
        CGA/mono video services are supported (int 10h)
        ACPI is supported

Handle 0x0001, DMI type 1, 27 bytes
System Information
    Manufacturer: innotek GmbH
    Product Name: VirtualBox
    Version: 1.2
    Serial Number: 0
    UUID: e83f6988-828d-5142-a0e2-2bca4c199fc3
    Wake-up Type: Power Switch
    SKU Number: Not Specified
    Family: Virtual Machine

Handle 0x0008, DMI type 2, 15 bytes
Base Board Information
    Manufacturer: Oracle Corporation
    Product Name: VirtualBox
    Version: 1.2
    Serial Number: 0
    Asset Tag: Not Specified
    Features:
        Board is a hosting board
    Location In Chassis: Not Specified
    Chassis Handle: 0x0003
    Type: Motherboard
    Contained Object Handles: 0

Handle 0x0003, DMI type 3, 13 bytes
Chassis Information
    Manufacturer: Oracle Corporation
    Type: Other
    Lock: Not Present
    Version: Not Specified
    Serial Number: Not Specified
    Asset Tag: Not Specified
    Boot-up State: Safe
    Power Supply State: Safe
    Thermal State: Safe
    Security Status: None

Handle 0x0007, DMI type 126, 42 bytes
Inactive

Handle 0x0005, DMI type 126, 15 bytes
Inactive

Handle 0x0006, DMI type 126, 28 bytes
Inactive

Handle 0x0002, DMI type 11, 7 bytes
OEM Strings
    String 1: vboxVer_6.1.50
    String 2: vboxRev_161033

Handle 0x0004, DMI type 128, 8 bytes
OEM-specific Type
    Header and Data:
        80 08 04 00 FF C5 2A 00

Handle 0xFEFF, DMI type 127, 4 bytes
End Of Table

**Commands That Work:** The following commands provide complete CPU details: - lscpu - cat /proc/cpuinfo **Example lscpu Output:**

root@faiserver:~# lscpu
Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         39 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  1
  On-line CPU(s) list:   0
Vendor ID:               GenuineIntel
  Model name:            11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
    BIOS Model name:       CPU @ 0.0GHz
    BIOS CPU family:     0
    CPU family:          6
    Model:               140
    Thread(s) per core:  1
    Core(s) per socket:  1
    Socket(s):           1
    Stepping:            1
    BogoMIPS:            5606.39
    Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse ss
                         e2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid tsc_known_fre
                         q pni pclmulqdq monitor ssse3 cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx rdrand
                         hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti fsgsbase avx2 invpcid rdseed clflushopt
                          md_clear flush_l1d arch_capabilities
Virtualization features:
  Hypervisor vendor:     KVM
  Virtualization type:   full
Caches (sum of all):
  L1d:                   48 KiB (1 instance)
  L1i:                   32 KiB (1 instance)
  L2:                    1.3 MiB (1 instance)
  L3:                    12 MiB (1 instance)
NUMA:
  NUMA node(s):          1
  NUMA node0 CPU(s):     0
Vulnerabilities:
  Gather data sampling:  Unknown: Dependent on hypervisor status
  Itlb multihit:         KVM: Mitigation: VMX unsupported
  L1tf:                  Mitigation; PTE Inversion
  Mds:                   Mitigation; Clear CPU buffers; SMT Host state unknown
  Meltdown:              Mitigation; PTI
  Mmio stale data:       Not affected
  Retbleed:              Not affected
  Spec rstack overflow:  Not affected
  Spec store bypass:     Vulnerable
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:            Mitigation; Retpolines, STIBP disabled, RSB filling, PBRSB-eIBRS Not affected
  Srbds:                 Not affected
  Tsx async abort:       Not affected
root@faiserver:~#

**Example /proc/cpuinfo Output:**

root@faiserver:~# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 140
model name      : 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
stepping        : 1
cpu MHz         : 2803.198
cache size      : 12288 KB
physical id     : 0
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 22
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni pclmulqdq monitor ssse3 cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti fsgsbase avx2 invpcid rdseed clflushopt md_clear flush_l1d arch_capabilities
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit gds
bogomips        : 5606.39
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:
root@faiserver:~#

**Request for Assistance:** - Is there a way to configure VirtualBox to expose more detailed SMBIOS information to the guest OS? - Are there any settings or additional steps that can be taken to enable dmidecode to retrieve full CPU information in a VirtualBox VM? - Any insights or suggestions to address this issue would be greatly appreciated. Thank you for your assistance.

I used a system information utility to take the model number of a system, and also of the motherboard. DMI System Manufacturer LENOVO DMI System Product 2306CTO DMI System Version ThinkPad X230 DMI Motherboard Product 2306CTO Is there a way to get model number, in this case 2306CTO, in Linux?

I have a Dell laptop running Debian Sid. Current kernel (4.15.4) is configured to load dell_smbios as module (CONFIG_DELL_SMBIOS=m). This produces the followning error while booting dell_smbios: No dell-smbios drivers are loaded I want to add a kernel boot parameter to stop dell-smbios from being loaded. Something like dell_smbios=off (Used to diable ACPI, i.e acpi=off) or dell_smbios.disable=1 (Used to disable IPv6, i.e ipv6.disable=1). So how do I know the specific kernel boot parameter for a given configuration option in the config file in /boot directory?

I want to do some interaction with bios of a embedded linux on an AMD Ryzen embedded platform. The main tool I think is flashrom which can read/write flash chips. It should also be possible to write data to flash rom using something like dd if the address of the chip in memory is known? Is this the correct way to look for system bios: root@device:~/bios# grep ROM /proc/iomem 000c0000-000cd3ff : Video ROM 000f0000-000fffff : System ROM If I look for the rom using flashrom tool I get the following: root@device:~/bios# flashrom -p internal --flash-name flashrom v1.2 on Linux 5.4.199 (x86_64) flashrom is free software, get the source code at https://flashrom.org Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Found chipset "AMD FP4". Enabling flash write... OK. Found Winbond flash chip "W25Q64.W" (8192 kB, SPI) mapped at physical address 0x00000000ff800000. vendor="Winbond" name="W25Q64.W" So the iomem says the chip is at 000f0000-000fffff and flashrom is saying he chip is at 0x00000000ff800000 Which one is correct, or better yet, why these are not identical?

My laptop has a display adapter and from Windows 10 I can see its **BIOS Device Name** from.. Device Manager > Display Adapters > Properties > Details > "BIOS device name" And from there I get a pop up window saying something like: \_SB.PCI0.GFX0 How can I get that information if the same laptop is running Linux? Cheers Update ------ I need this information because I am building a hackintosh and need to build a SSDT to create a display backlight fix. I would like to help out at the [Opencore project](https://dortania.github.io/OpenCore-Install-Guide/) and provide a method to do this in Linux as currently [the only method](https://dortania.github.io/Getting-Started-With-ACPI/Laptops/backlight-methods/manual.html) is to switch in to Windows and use Device Manager I tried dmidecode and lspci and they don't give me a BIOS device name in the format that Windows does and is needed to create the SSDT. I tried [acpidump](https://01.org/linux-acpi/utilities) and it's getting me closer but the decompiled output has disassembly errors. It contains the string I am looking for \_SB.PCI0.GFX0 but I don't know how I would create a script to read that file and correlate it to my particular display adapter. e.g: Intel(R) HD Graphics 4000. These are the commands I have tried so far with acpidump I dump the ACPI tables from my system to a text file: sudo acpidump -o acpidump.out Extract the binary ACPI tables from acpidump output acpixtract -a acpidump.out I now have seven ssdt*.data files. I disassemble the binary table of ssdt1.dat into human source iasl -d ssdt1.dat This gives a large .dsl file, this is just the first 60 lines of over a thousand.. /* * Intel ACPI Component Architecture * AML/ASL+ Disassembler version 20190509 (64-bit version) * Copyright (c) 2000 - 2019 Intel Corporation * * Disassembling to symbolic ASL+ operators * * Disassembly of ssdt1.dat, Mon Jun 7 09:54:08 2021 * * Original Table Header: * Signature "SSDT" * Length 0x00001EED (7917) * Revision 0x01 * Checksum 0x9C * OEM ID "COMPAL" * OEM Table ID "CRV ORB " * OEM Revision 0x00001000 (4096) * Compiler ID "ACPI" * Compiler Version 0x00040000 (262144) */ DefinitionBlock ("", "SSDT", 1, "COMPAL", "CRV ORB ", 0x00001000) { /* * iASL Warning: There was 1 external control method found during * disassembly, but only 0 were resolved (1 unresolved). Additional * ACPI tables may be required to properly disassemble the code. This * resulting disassembler output file may not compile because the * disassembler did not know how many arguments to assign to the * unresolved methods. Note: SSDTs can be dynamically loaded at * runtime and may or may not be available via the host OS. * * To specify the tables needed to resolve external control method * references, the -e option can be used to specify the filenames. * Example iASL invocations: * iasl -e ssdt1.aml ssdt2.aml ssdt3.aml -d dsdt.aml * iasl -e dsdt.aml ssdt2.aml -d ssdt1.aml * iasl -e ssdt*.aml -d dsdt.aml * * In addition, the -fe option can be used to specify a file containing * control method external declarations with the associated method * argument counts. Each line of the file must be of the form: * External (, MethodObj, ) * Invocation: * iasl -fe refs.txt -d dsdt.aml * * The following methods were unresolved and many not compile properly * because the disassembler had to guess at the number of arguments * required for each: */ External (_SB_.PCI0.GFX0, DeviceObj) External (_SB_.PCI0.GFX0._DOD, IntObj) External (_SB_.PCI0.GFX0.AINT, MethodObj) // Warning: Unknown method, guessing 2 arguments External (_SB_.PCI0.GFX0.DD01._ADR, IntObj) External (_SB_.PCI0.GFX0.DD01._DGS, IntObj) External (_SB_.PCI0.GFX0.DD02._ADR, IntObj) External (_SB_.PCI0.GFX0.DD02._BCL, IntObj) External (_SB_.PCI0.GFX0.DD02._BCM, IntObj) External (_SB_.PCI0.GFX0.DD02._BQC, IntObj) I think maybe I need to dissasemble ssdt1.dat such that I don't get disassembly errors and then is there a way to search that disassembled file for a device by a name like 'Intel(R) HD Graphics 4000' or that would at least be obvious this is the BIOS Device Name for my display adapter? Maybe dmidecode, lspci and acpidump can all be combined into a script? Any other help much appreciated. Flex

From the dmidecode man page : > the presented information [is] possibly unreliable. They also add: > More often than not, information contained in the DMI tables is inaccurate, incomplete or simply wrong. Here is an example where the DMI table data differs from using other PCI utilities. Under what circumstances is data in the DMI table inaccurate?

So, I got a new battery for my laptop, and right from the get go, I'm having problems. The battery came almost entirely discharged from the manufacturer. I plugged it into my computer and the batter would report that the charge rate is 0, and hence would never reach "fully charged" After a couple minutes and having X11 crash, I'm now at this (upower -i /org/freedesktop/UPower/devices/battery_BAT0): native-path: BAT0 vendor: Hewlett-Packard model: Primary power supply: yes updated: Fri 21 Oct 2016 08:28:33 AM CEST (106 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: charging warning-level: none energy: 17.8704 Wh energy-empty: 0 Wh energy-full: 24.192 Wh energy-full-design: 95.04 Wh energy-rate: 0.0996923 W voltage: 15.947 V percentage: 73% capacity: 25.4545% technology: lithium-ion icon-name: 'battery-full-charging-symbolic' So the battery is charging, the energy capacity is only about a quarter of what it was designed (even though the battery is only a couple days old), it sits at 73%, and the charge rate is so small, it doesn't even report how much it'd take till fully charged. Now, I know you can kinda "calibrate" a battery, by charging it for a couple hours, then letting it run flat, and then charge it up again. This doesn't seem to be the right way to do, though. I'm wondering if I can't access the smart data directly, via the SMBus . i2cdetect -l reports: i2c-0 smbus SMBus I801 adapter at 8000 SMBus adapter i2c-1 i2c NVIDIA i2c adapter 0 at 1:00.0 I2C adapter i2c-2 i2c NVIDIA i2c adapter 2 at 1:00.0 I2C adapter i2c-3 i2c NVIDIA i2c adapter 3 at 1:00.0 I2C adapter i2c-4 i2c NVIDIA i2c adapter 5 at 1:00.0 I2C adapter So, I tried probing SMBus (i2cdetect -r 0): WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0 using read byte commands. I will probe address range 0x03-0x77. Continue? [Y/n] y 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- This is quite strange to me, does that mean there's nothing connected to the bus? No matter which address I'm trying to dump, the result is always the same: i2cdump 0 0x03 (all other valid addresses produce the same output): No size specified (using byte-data access) WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0, address 0x1a, mode byte Continue? [Y/n] y 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX That's how far I got. The system gets it's battery information from *somewhere*, but I can't figure out how and from where. As for the I²C / SMBus access to the battery: no idea if I'm doing something wrong, or it's impossible like that. I'd like to know how to access smart battery data, how to set it (presumably with i2cset), and possibly how it's formatted (what data encodes which information, etc.) ------- acpi -V is even more confused: Battery 0: Unknown, 73% Battery 0: design capacity 6600 mAh, last full capacity 1680 mAh = 25% Adapter 0: on-line *(design capacity reported incorrectly, etc.)* ------- Last bit of information I can come up with, is dmidecode output: Handle 0x0010, DMI type 39, 22 bytes System Power Supply Location: OEM_Define0 Name: OEM_Define1 Manufacturer: OEM_Define2 Serial Number: OEM_Define2 Asset Tag: OEM_Define3 Model Part Number: OEM_Define4 Revision: OEM_Define5 Max Power Capacity: 75 W Status: Present, OK Type: Regulator Input Voltage Range Switching: Auto-switch Plugged: No Hot Replaceable: No You can see all these "OEM_Define2", etc. strings in there, that aren't telling much. dmidecode -t connector reports: Getting SMBIOS data from sysfs. SMBIOS 2.4 present.

I note that SMBios Type 20 would help here, but it's optional as of version 2.5 (2006-09-05) pp. 25, L796, and pp. 131 , whereas types 16, 17 and 19 are mandatory, but don't quite help. ### Physical Memory Array (Type 16) There is one of these structures for the entire system, explaining what is possible on this board. Handle 0x1000, DMI type 16, 23 bytes Physical Memory Array Location: System Board Or Motherboard Use: System Memory Error Correction Type: Multi-bit ECC Maximum Capacity: 768 GB Error Information Handle: Not Provided Number Of Devices: 24 ### Memory Device (Type 17) There is one record per each Dimm, which tells you the physical Dimms installed on the board. Handle 0x1100, DMI type 17, 34 bytes Memory Device Array Handle: 0x1000 Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: 1 Locator: DIMM_A1 Bank Locator: Not Specified Type: DDR3 Type Detail: Synchronous Registered (Buffered) Speed: 1600 MHz Manufacturer: XXXX Serial Number: XXXX Asset Tag: XXXX Part Number: XXXX Rank: 1 Configured Clock Speed: 1333 MHz ### Memory Array Mapped Address (Type 19) There can be multiple of these records, and each record lists a range of physical addresses. Here is the output with two 2GB sticks: Handle 0x1300, DMI type 19, 31 bytes Memory Array Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000CFFFFFFF Range Size: 3328 MB Physical Array Handle: 0x1000 Partition Width: 2 Handle 0x1301, DMI type 19, 31 bytes Memory Array Mapped Address Starting Address: 0x00100000000 Ending Address: 0x0012FFFFFFF Range Size: 768 MB Physical Array Handle: 0x1000 Partition Width: 2 And here is the output with 4 sticks; 2*2GB and 2*4GB: Handle 0x1300, DMI type 19, 31 bytes Memory Array Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000CFFFFFFF Range Size: 3328 MB Physical Array Handle: 0x1000 Partition Width: 2 Handle 0x1301, DMI type 19, 31 bytes Memory Array Mapped Address Starting Address: 0x00100000000 Ending Address: 0x0032FFFFFFF Range Size: 8960 MB Physical Array Handle: 0x1000 Partition Width: 2 Note that in the first sample output above, there were two 2GB DIMMs, but two ranges of 3.3GB and 0.7GB. With 4 Dimms, the system will also coalesce the memory array mapped address region into two chunks, as it is just representing the same as the e820 map, i.e. the valid memory physical address ranges. 1 to many Type 20 records are tied to exactly one type 17 memory device, meaning that the entire physical range can be known: ### Example $ sudo dmidecode -t 20 # dmidecode 2.12 SMBIOS 2.6 present. Handle 0x002F, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000FFFFFFFF Range Size: 4 GB Physical Device Handle: 0x002B Memory Array Mapped Address Handle: 0x002E Partition Row Position: 1 Handle 0x0030, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00100000000 Ending Address: 0x001FFFFFFFF Range Size: 4 GB Physical Device Handle: 0x002C Memory Array Mapped Address Handle: 0x002E Partition Row Position: 1 It seems possible to go from address to DIMM for EDAC - Error Detection & Correction purposes, but not from DIMM to entire range. Looking at the source code of mcelog , it is also using type 20 for its decoding.